Firefox 128 實作廣告投放蒐集功能 (Ad measurement)

六月底的時候就有一些消息,然後這幾天熱起來了,先是 Hacker News 上這兩篇,在講 Firefox 128 (現在的 stable 版) 預設開啟了廣告蒐集行為:「Firefox 128 enables "privacy-preserving" ad measurements by default (mstdn.social)」、「"Firefox added [ad tracking] and has already turned it on without asking you" (mastodon.social)」。

這個消息剛好可以跟六月底的時候「併購」了 Anonym 這家廣告公司一起看:「Mozilla acquires ad analytics company, for some reason」。

愈來愈像廣告公司了...

Lazybird 瀏覽器計畫在 2026 夏天推出 Alpha 版

在「Welcome to Ladybird, a truly independent web browser (ladybird.org)」這邊看到的,指到官網 Ladybird 上。

最主要的資訊應該是這個日期,目前計畫是 2026 夏天在 LinuxmacOS 上推出 alpha 版:

We are targeting Summer 2026 for a first Alpha version on Linux and macOS. This will be aimed at developers and early adopters.

也就是大約再兩年,看起來得花不少時間開發... 畢竟是要完全獨立開發不使用現有瀏覽器的 code。

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 的行為 (提前?),畢竟讓他再做四個月的生意也是很危險?

Popover API

看到「Popover API (developer.mozilla.org)」這個討論,引用的資料是 MDN 上面的「Popover API」,從名字也可以看出來與 pop over 有關 (話說查單字發現 popover 這個詞在字典裡居然是泡芙,英文維基百科上的 Popover 也可以看到...)。

Anyway,馬上有想到的是 modal 類的操作,在 MDN 上面的文件裡面有範例,可以用純 HTML 的方式操作:

<button popovertarget="mypopover">Toggle the popover</button>
<div id="mypopover" popover>Popover content</div>

效果就是在畫面正中央出現,預設有 border。

另外也可以透過 JavaScript 的方式操作:

HTMLElement.togglePopover()

MDN 文件把這個功能標成 Baseline 2024:

Since April 2024, this feature works across the latest devices and browser versions. This feature might not work in older devices or browsers.

因為是很新的東西 (就支援度來說),要注意如果使用者是舊版瀏覽器的 fallback 行為。

翻文件底部的支援情況,可以看到最後支援的主流瀏覽器是 Firefox 125 (2024/04/16),而 Firefox 還是有人會用 ESR 版本,目前還是 115,但照著 Firefox ESR 的節奏,應該是暑假會出下一版,但如果是現在要用的話,應該得考慮用 polyfill 去支援不原生支援的瀏覽器。

Dillo 瀏覽器重新啟動

前幾天看到「Show HN: Dillo 3.1.0 released after 9 years (dillo-browser.github.io)」這個消息,Dillo 瀏覽器的重啟,將過去九年的 patch 整理起來出了 3.1.0:「Dillo release 3.1.0」。

從記憶裡面勉強挖出對 Dillo 的印象,翻了維基百科確認了不支援 js 的部分:

Dillo does not support JavaScript, Java, Flash, right-to-left text, or complex text layout.

目標是只用極少的資源 (以維基百科的說法是 i486 這樣的電腦),所以 Dillo 只能顯示基本的網頁。剛剛抓 3.1.0 下來自己編,測了一下連 Acid1 都不會過。不過可以看看後續會發展到什麼程度...

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 應該預設也是關的。

Firefox 的 UI 修正方案

在「Firefox Proton UI userChrome.css fixes. (2021) (github.com/black7375)」這邊看到的,GitHub 上的專案頁面在「Lepton (old name: Proton Fix)」這邊。

作者先前有寫過,我在「Firefox 的 UI/UX 歷史」這篇,同一個 repository 裡面就包含了「修正方案」,補上了一些 icon,並且改了 css 效果。

不過我已經沒什麼在用 Firefox 了,而且目前看起來也不會回去了,看起來只有在交叉找問題的時候會用到...

UI Event 的順序

othree 寫了一篇「UI Event Order」在講滑鼠 (或是更廣廣義的 pointer 類) 以及鍵盤 (包括輸入法) 在瀏覽器上會產生的 event。

裡面有些是歷史 (提到 IE 上的實作方式),現在都不太會碰到了,可以直接看目前的幾份標準就好,然後蠻多標準都還是在 draft 階段,各家瀏覽器更新的速度不一樣,所以會有不同的行為冒出來。

我決定先把文章保留起來,等遇到的時候再回來看 XD

Web Audio API 當做 fingerprint 的方式

三年前的文章「How the Web Audio API is used for audio fingerprinting」講解了 AudioContext 是怎麼被拿來 fingerprint 的,最近在「How We Bypassed Safari 17's Advanced Audio Fingerprinting Protection」這篇看到的。

AudioContext 可以完全跟錄音設備無關,單純計算,然後因為不同瀏覽器實作上面有差異,就被拿來當作 fingerprint 了。

文章裡介紹的方法是透過 Oscillator 產生 440Hz 的正弦波,然後過 Compressor 降低音量 (運算):

The Web Audio API provides a DynamicsCompressorNode, which lowers the volume of the loudest parts of the signal and helps prevent distortion or clipping.

降低音量的運算再這塊各家的實作不同,就能夠區分不同的瀏覽器 (甚至是版本):

Historically, all major browser engines (Blink, WebKit, and Gecko) based their Web Audio API implementations on code originally developed by Google in 2011 and 2012 for the WebKit project.

Since then browser developers have made a lot of small changes. These changes, compounded by the large number of mathematical operations involved, lead to fingerprinting differences. Audio signal processing uses floating point arithmetic, which also contributes to discrepancies in calculations.

Additionally, browsers use different implementations for different CPU architectures and OSes to leverage features like SIMD. For example, Chrome uses a separate fast Fourier transform implementation on macOS (producing a different oscillator signal) and other vector operation implementations on different CPU architectures (used in the DynamicsCompressor implementation). These platform-specific changes also contribute to differences in the final audio fingerprint.

而這東西平常也不會用到,所以對 Tor Browser 這種特別重視 privacy 的瀏覽器就直接關掉他了:

Tor

In the case of the Tor browser, everything is simple. But unfortunately, web Audio API is disabled there, so audio fingerprinting is impossible.

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