用 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 偵測到並且儲存。

各家瀏覽器與工具對於 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。

透過 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 挖礦了...

因應 Manifest V3 而推出的 uBlock Minus (MV3)

前幾天在 Hacker News 上看到「“UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3 (github.com/gorhill)」這個,裡面是 uBlock Origin 的作者 Raymond Hill 針對 Manifest V3 的半殘版,取名為 uBO Minus (MV3):「Add experimental mv3 version」。

在這個版本裡會有不少的功能失效,尤其是用的很多的 cosmetic filtering:

- No cosmetic filtering (##)
- No scriptlet injection (##+js)
- No redirect= filters
- No csp= filters
- No removeparam= filters

這個版本應該是打算要提供給 Manifest V2 被 Google 廢掉後還在用 Google 控制的瀏覽器的人,依照「Manifest V2 support timeline」這邊看起來是明年一月:

在 Ubuntu 20.04/22.04 下使用 18.04 的 chromium-browser

Ubuntu 20.04 之後包的 chromium 都是基於 snap 的方案,是個除了 Canonical 的人以外沒人愛的東西,所以大家都在找方法改回 .deb 的版本。

剛剛因為需要測試東西所以才需要找這個方案,發現有個還蠻有趣的解法,是拿 18.04 的 chromium-browser 的套件來裝,因為官方至少會支援到 2023/04:「Is it still possible to install Chromium as a deb-package on 20.04 LTS using some third-party repository?」。

一個 /etc/apt/sources.list.d/bionic-update.list

deb http://archive.ubuntu.com/ubuntu/ bionic-updates universe

另外一個 /etc/apt/preferences.d/chromium-deb-bionic-updates

Package: chromium-browser chromium-browser-l10n chromium-codecs-ffmpeg-extra chromium-codecs-ffmpeg 
Pin: release a=bionic-updates
Pin-Priority: 900

完全還是使用官方套件的解法,唯一的缺點大概就是到明年四月而已,但對要測試來說夠用了...

XFCE 配上 Chromium 系列瀏覽器 (Chrome/Brave/...),視窗最大化時的問題

今天發現 Brave 在視窗最大化時會超出預期的邊界,而非放大到螢幕的邊緣,找了一下發現有人已經在 Brave 的 GitHub 上開了「Incorrect scale if browser is full screen #18964」這張票,後來看到有人說在 Chromium 的 bug system 上已經有人提出來了:「Issue 1257119: Goes under the taskbar when maximized」、「Issue 1260821: maximise gets screen dimension wron」與「Issue 1261797: [User Feedback - Stable] Reports that when Chrome is maximized after being minimized, it launches to beyond the window frame on Linux」。

這次遇到的 bug 看起來是只有用 XFCE 的使用者才會中獎,目前先摸索出一套 workaround 是透過 wmctrl 操作修改瀏覽器的位置與視窗大小。

方法是先用 wmctrl -l -G 列出所有視窗的資訊,包括 geometry 的資料,接著再用 wmctrl -i -r 0x12345678 -e 0,3760,15,1232,1935 這樣的指令去指定瀏覽器的位置與視窗大小。

不知道要撐多久就是了...

Chromium 系列瀏覽器對 Google Search Engine 的不公平最佳化

在 tab 上放了一陣子的連結,忘記是哪邊看到的,在講 Chromium 系列瀏覽器會針對 Google Search Engine 最佳化:「Google’s unfair performance advantage in Chrome」。

作者發現 Chromium 瀏覽器會預先開 HTTPS 連線連到搜尋引擎,這樣可以大幅降低建立 HTTPS 連線時所需要的時間,包括了 DNS 查詢、TCP handshake 與 TLS handshake:

I was looking for something else when I stumbled upon a feature called PreconnectToSearch. When enabled, the feature preemptively opens and maintains a connection to the default search engine.

問題在於這個功能只開給 Google Search 使用:

There’s just one small catch: Chromium checks the default search engine setting, and only enables the feature when it’s set to Google Search.

search_engine_preconnector.cc (HEAD 版本) 這邊可以看到這段程式碼:

// Feature to limit experimentation to Google search only.
const base::Feature kPreconnectToSearchNonGoogle{
    "PreconnectToSearchNonGoogle", base::FEATURE_DISABLED_BY_DEFAULT};
}  // namespace features

作者有提到,的確這個功能會對 search engine 有不小的衝擊,但可以透過擴充 OpenSearch Descriptions 或是 Well-Known URI 的方式提供,現在這樣寫死在程式碼裡面完全就是不公平競爭。