Google Chrome 的 Canary 版本 (通路) 移除 Manifest V2

在「Manifest v2 is now removed from Chrome canary (chrome.com)」這邊看到的,Google ChromeCanary 版本已經移除 Manifest V2:「Manifest V2 support timeline」。

接下來應該要進入各家瀏覽器自己維護 fork 的時代了,尤其是對 chrome.webRequest 的支援,來看接下來各家 fork 的發展。

Chrome 停止信任 Entrust 憑證的計畫

Hacker News 上看到「Entrust Certificate Distrust (googleblog.com)」這個討論,Google 決定要停止信任 Entrust 頒發的憑證:「Sustaining Digital Certificate Security - Entrust Certificate Distrust」。

快速翻了一下 Google 列出來在 Mozilla Bug List 上面的記錄 (在這裡),應該是出太多包,而且有些包給的解釋又不能說明出包的理由?

我拉了一下 Let's Encrypt 的情況,可以看到是兩種不同的情境:「這邊」,或是 GlobalSign:「這邊」。

目前的計畫是在下個 stable 版開始設限 (現在 stable 是 126,目前公告 127 開始擋),但給了四個月的期限,仍然會認 Entrust 在 2024/10/31 前發的憑證:

TLS server authentication certificates validating to the following Entrust roots whose earliest Signed Certificate Timestamp (SCT) is dated after October 31, 2024, will no longer be trusted by default.

因為有 Certificate Transparency (CT) 的關係,所有的簽署資料都會是公開可以查的,所以 Hacker News 上面有人整理出來有受到影響的網站... 看起來是把抓回來的資料丟到 ClickHouse 上分析:「SELECT rank, domain, certificate_issuer FROM minicrawl_processed WHERE startsWith(certificate_issuer, 'Entrust') AND date = today() ORDER BY rank::UInt32」。

裡面可以看到許多知名的網站 (畢竟還是 Entrust),這點從「Market share trends for SSL certificate authorities」這邊可以看得出來,雖然跟前面幾家比起來算小,但至少還是在榜上。

來等看看 MozillaApple 的動作,會不會有更嚴格的 distrust 的行為 (提前?),畢竟讓他再做四個月的生意也是很危險?

Chrome 124 啟用了 X25519Kyber768

在「Google Chrome's new post-quantum cryptography may break TLS connections」這邊看到的,出自「Q1 2024 Summary from Chrome Security」這邊的公告。

Chrome 124 預設啟用 X25519Kyber768 了:

After several months of experimentation for compatibility and performance impacts, we’re launching a hybrid postquantum TLS key exchange to desktop platforms in Chrome 124. This protects users’ traffic from so-called “store now decrypt later” attacks, in which a future quantum computer could decrypt encrypted traffic recorded today.

如果遇到問題的話可以在 chrome://flags 裡面的 #enable-tls13-kyber 關閉後重開瀏覽器... 不過應該是還好,大多數的 HTTPS server 應該都沒有實作 X25519Kyber768,就算是 Cloudflare 應該預設也是關的。

用 Brave 的 brave://flags 設定

因為 Brave 會繼續支援 webRequest 的完整功能,所以早早就已經跳槽過來,不過 Brave 的垃圾功能太多 (一堆 cryptocurrency 相關的功能),有需要全部關掉,所以裝好後第一件事情就是到 brave://flags 裡面把所有 Brave 自家功能的設定關光光,只留下 Brave Sync V2 的功能。

先前都是用滑鼠一個一個關,剛剛覺得太累了,研究一下 js 直接在 dev console 裡面關:

document.querySelector('flags-app').shadowRoot.querySelectorAll('flags-experiment[id^=brave]').forEach(flag => {
  flag.shadowRoot.querySelectorAll('option').forEach(o => {
    if (o.innerText === 'Disabled') {
      o.selected = 'selected';
      o.parentElement.dispatchEvent(new Event('change'));
    }
  });
});

這樣會全部把 brave 開頭的 feature flag 都關掉;最後再手動把 Sync V2 開回來就可以重開 Brave 了。

後續就是 GUI 上面的選單再調整成自己要的。

這邊搞 javascript 的部分有遇到四個地方要處理... 第一個是現在 dev console 預設不讓你貼東西進去,貼了以後會顯示要輸入 allow pasting 後才行,這個字串以及方法之後不知道會不會改。

第二個是遇到 querySelectorAll 穿不過 shadow DOM,所以可以看到程式碼裡面需要先選出 shadow DOM 元素,用 shadowRoot 鑽進去再 querySelectorAll 一次。

第三個是 css selector 沒辦法針對 innerHTML 或是 innerText 的內容判斷,所以得自己拉出 option 後對 innerText 判斷。

最後一個是改變 select 的值後,得自己觸發 change event,這樣才會讓 Brave 偵測到並且儲存。

Keyboard Event:在網頁上自定義快速鍵

先前寫了一堆 userscript 針對不同的網站加上快速鍵 (像是翻下一頁或是上一頁):

然後發現太多重複的事情了,就寫成 Chrome 的 extension 了:「Keyboard Event」,程式碼在 GitHub 上有放:「gslin/keyboard-event」,不信任一致性的話也可以用 Chrome extension source viewer 直接看 chrome web store 上面放的版本。

這個 extension 的想法是設定 hostname、path 以及按鍵,接著設定按鍵按下後會觸發的 DOM element (用 CSS selector 選) 與 DOM event (像是 mouseover 這樣的 event 字串)。

而其中 click event 常常不會動 (對應實際的呼叫是 element.dispatchEvent(new Event('click'))),在 debug 時發現需要用 click() (對應實際的呼叫是 element.click()),所以有特別接受 click() 這個字串。

這個舉個例子,我有一組設定是:

www.instagram.com
.*
<
div[role="dialog"] button[aria-label="Go back"]
click()

www.instagram.com
.*
>
div[role="dialog"] button[aria-label="Next"]
click()

在瀏覽器上面看 Instagram 的照片時可以用 <> 快速切換照片。

另外設定的部分支援 chrome.storage 的 browser sync,對於有多瀏覽器時會自動同步設定檔,不用每一台都設定一次...

這算是第一次寫 Manifest V3 的 extension (先前都是 V2),本來想用 Vue.js 處理設定頁 options.html,但遇到了 CSP 的問題,在 Manifest V3 上面無法設定 unsafe-eval,於是 Vue.js 只能用 runtime 版本,喪失了 template 好用的地方...

後來決定回頭用 jQuery + jQuery UI (用 sortable),然後自己處理一堆 data 更新時頁面的變化,一整個 2010 年老人味都出來了...

但這樣至少會動,先跑一陣子看看...

各家瀏覽器與工具對於 blur 效果的實際呈現比較

Hacker News 上看到「Blur Radius Comparison (bjango.com)」,原文在「Blur radius comparison」。

重點在這張:

前面九個分成三種效果在三個不同的瀏覽器呈現的結果,然後是 FigmaIllustratorPhotoshopSketch 的效果。

可以看出來在瀏覽器上的部分,大家的 rendering 沒有差太多。

而 Figma 所有 blur 類的效果,在瀏覽器上比較接近的只有 box-shadow,其他三套則是有不同的變化...

Firefox 與 Chrome 處理 Intermediate CA 的不同方式

Fediverse 上看到「The recording of my "Browsers biggest TLS Mistake" lightning talk at #37C3」這個,這是出自 37C3 的 lightning talk,影片不長,只有五分鐘,可以在「Browsers biggest TLS mistake」這邊看到。

正常的 HTTPS server 會送出 Intermediate CA certificate 與自己的 TLS certificate:

當伺服器端沒有設定好,通常是只送出自己的 TLS certificate:

這種情況在 Firefox 裡有處理,軟體本身會預載所有的 Intermediate CA 避免這種問題 (當然會需要跟著軟體更新),這點在三年前有提到過:「Firefox 試著透過預載 Intermediate CA 降低連線錯誤發生的機率?」,也就是這張投影片提到的情況:

Chrome 則是去看目前的 cache 資料,找看看是不是在其他地方有看到適合的 Intermediate CA 可以接起來:

這好像可以解釋為什麼之前遇到類似的問題的時候,在 Chrome 上面會需要進 chrome:// 裡面清東西才能重製...

Google Chrome 將在 115 版之後預設使用 HTTPS 連線

Google Chrome (Chromium) 宣布 115 版後將預設使用 HTTPS 連線:「Towards HTTPS by default」。

查了一下 115.0.5790.98 是 2023/07/18 就出的版本,現在才冒出這篇文章有點晚,但大概就是講一下幹了什麼事情?

We're currently experimenting with this change in Chrome version 115, working to standardize the behavior across the web, and plan to roll out the feature to everyone soon.

主要的差異是在於,即使你輸入或是點擊的連結是 http://,他還是會優先嘗試 HTTPS:

Chrome will automatically upgrade all http:// navigations to https://, even when you click on a link that explicitly declares http://.

只有在 http:// 連結遇到 upgrade 到 HTTPS 失敗時才會回頭用 HTTP:

This works very similarly to HSTS upgrading, but Chrome will detect when these upgrades fail (e.g. due to a site providing an invalid certificate or returning a HTTP 404), and will automatically fallback to http://.

而本來就用 https:// 的連線就完全不會碰 HTTP 了。

講到推動 HTTPS 這點,前陣子剛好也是 Snowden 揭露美國 PRISM (菱鏡計畫) 十年的日子,當年在揭露後也因此加速了各種加密技術的基礎建設,像是 Let's Encrypt,而這也使得 HTTPS 更加普及,也讓 Google Chrome 現在可以預設切 HTTPS。

用 Little Rat 看哪些 extension 在後面亂連線

還在日本的時候在 Hacker News 上看到「Show HN: Little Rat – Chrome extension monitors network calls of all extensions (github.com/dnakov)」這篇,在介紹「little-rat」這個專案,可以看 extension 做了那些連線。

放上 Chrome Web Store 的版本比較陽春,只能擋而不能看,因為 declarativeNetRequest.onRuleMatchedDebug 不能上:

The reason is that the extension uses the declarativeNetRequest.onRuleMatchedDebug API which is not available for publishing in the Chrome Web Store.

比較完整的功能還是需要自己 git clone 下來後裝,缺點就是要每一台自己裝,另外也要自己更新重跑起來。

裝好後跑一陣子讓他記錄,可以看到有些連線是預料中的,像是 uBlock Origin 會需要定時更新 rule,但也意外的看到一些有問題的 extension 了...

透過 WebGPU 跑的 Web LLM

Simon Willison 這邊看到的玩法,透過 WebGPU 在瀏覽器上面直接跑 LLM 的 demo:「Web LLM runs the vicuna-7b Large Language Model entirely in your browser, and it’s very impressive」,專案在「Web LLM」這邊,可以直接玩。

不過要注意一下瀏覽器的支援度,如果是 Chrome 的話需要 113+,但目前 stable 還是 112;而 Firefox 的話我試過在 about:config 裡面用 dom.webgpu.enabled 打開 WebGPU 支援,但重開瀏覽器後還是跑不動?(也有可能是 Linux 環境的關係)

Update:應該是 Linux 環境的關係,我在 Linux 下用 dev channel (114) 也不行。

話說有 WebGPU 後是不是開始要擋 GPU 挖礦了...