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」。

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

美國正在立法禁用大疆的產品

在「DJI ban passes the House and moves on to the Senate (dronedj.com)」這邊看到的,原文在「DJI ban passes the House and moves on to the Senate」這邊。

目前眾議院已經過過了,裡面提到 H.R.2864 (Countering CCP Drones Act):

One of these sections, H.R. 2864, or the Countering CCP Drones Act, was added to the bill and can be found under Section 1722. For those who are just hearing about this for the first time, it would remove DJI’s ability to get approval from the FCC, banning any future drones from being imported and possibly grounding current drones.

在官方的官面上則是直接列出大疆 (DJI):

Countering CCP Drones Act

This bill requires the inclusion of telecommunications and video surveillance equipment or services produced or provided by Shenzhen Da-Jiang Innovations Sciences and Technologies Company Limited (a Chinese drone maker commonly known as DJI Technologies) on a list of communications equipment or services determined by the Federal Communications Commission (FCC) to pose an unacceptable risk to U.S. national security. Current law prohibits the use of federal funding available through specified FCC programs for purchasing or maintaining listed equipment or services.

現在是在聯邦禁用,看起來打算提升警戒列為國安等級,打算全國禁用?

Slack 要拿使用者資料訓練 AI

在「Slack AI Training with Customer Data (slack.com)」這邊看到的,原公告在「Privacy Principles: Search, Learning and Artificial Intelligence」這邊。

預設會被丟進去訓練,Opt-out 無法直接設定,需要透過 e-mail 寫信找 feedback@slack.com (yeah,dark pattern):

Contact us to opt out. If you want to exclude your Customer Data from Slack global models, you can opt out. To opt out, please have your Org or Workspace Owners or Primary Owner contact our Customer Experience team at feedback@slack.com with your Workspace/Org URL and the subject line “Slack Global model opt-out request.” We will process your request and respond once the opt out has been completed.

拿企業資料來搞事嗎... 這應該已經不只是 privacy 議題而是 security 層面了,PR 層面鐵定很難看,來看後面會不會轉彎?

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

LLL lattice basis reduction algorithm

短短幾天內看到兩個不同的地方用到了 1982 年發現的「Lenstra–Lenstra–Lovász lattice basis reduction algorithm」。

第一個是「Randar: A Minecraft exploit that uses LLL lattice reduction to crack server RNG (github.com/spawnmason)」這篇,作者群利用 LLL 去分析 java.util.Random 的內部狀態,進而得到其他玩家的地點資訊:

Every time a block is broken in Minecraft versions Beta 1.8 through 1.12.2, the precise coordinates of the dropped item can reveal another player's location.

"Randar" is an exploit for Minecraft which uses LLL lattice reduction to crack the internal state of an incorrectly reused java.util.Random in the Minecraft server, then works backwards from that to locate other players currently loaded into the world.

另外一個是在 Hacker News 上面的 id=40080651 提到,前幾天 PuTTY 的 p521 問題在底層也用到了 LLL:

LLL lattice reduction is the same algorithm that can be used for cracking PuTTY keys from biased nonces from the CVE a few days ago. 'tptacek explained a bit about the attack (and links to a cryptopals problem for it, which I can almost pretend to understand if I squint) https://news.ycombinator.com/item?id=40045377

從維基百科的內容也可以看出來 application 非常多,不光是密碼學的領域用到,看起來值得花點力氣來了解...

Let's Encrypt 簽發新的 Intermediate CA

Let's Encrypt 宣佈簽發新的 Intermediate CA:「New Intermediate Certificates」。

這次用 ISRG Root X1 簽了很多東西出來:

On Wednesday, March 13, 2024, Let’s Encrypt generated 10 new Intermediate CA Key Pairs, and issued 15 new Intermediate CA Certificates containing the new public keys.

ISRG Root X1 簽了五組 2048-bit RSA 的 intermediate CA,被叫做 R10~R14:

We created 5 new 2048-bit RSA intermediate certificates named in sequence from R10 through R14. These are issued by ISRG Root X1. You can think of them as direct replacements for our existing R3 and R4 intermediates.

另外 ISRG Root X1 也簽出五組 P-384 ECDSA 的 intermediate CA,被叫做 E5~E9;另外 ISRG Root X2 也簽了 E5~E9:

We also created 5 new P-384 ECDSA intermediate certificates named in sequence from E5 through E9. Each of these is represented by two certificates: one issued by ISRG Root X2 (exactly like our existing E1 and E2), and one issued (or cross-signed) by ISRG Root X1.

所以總共是產生了 10 組 intermediate certificate,然後簽了 15 組 intermediate CA 出來。

另外這邊有個比較特別的是 ISRG Root X1 (RSA 4096) 也簽了 ISRG Root X2 (ECDSA P-384),理論上 ISRG Root X2 這組後續應該也會開始放到各家的 root store 裡面...

用官方的圖可以說明這些關係:

目前還沒上線,先簽出來並且公告,後續才會切換過去。

另外在紋章裡面提到了 app 應該避免對 intermediate certificate 鎖定 (key pinning):

We are very hopeful that these steps will prevent intermediate key pinning altogether, and help the WebPKI remain agile moving forward.

Intermediate CA 在安全理由上是需要定時更換的,真的要做的話,應該是對 Root CA 做比較好。

回顧 Let's Encrypt 將在六月停止 cross-signed chain 的消息

因為收到 Cloudflare 的信,關於 Let's Encrypt 的 cross-signed chain 將在今年九月底過期的計畫,Cloudflare 這邊也有一些配合的措施會進行:

Let’s Encrypt announced that the cross-signed chain is set to expire on September 30th, 2024. As a result, Cloudflare will stop issuing certificates from the cross-signed CA chain on May 15th, 2024.

去年七月的時候 Let's Encrypt 拿的是去年五月底的資料說明 (2023/05/31),這邊會看 Android 7.1+ 的佔比,當時到了 93.9%。

會看 Android 7.1 是因為從這個版本開始預設就有內建 ISRG Root X1,而不需要 IdenTrust 的 cross-sign chain 了:

剛剛開了 Android Studio 來看,最近一次更新 Android 市占率的資料是去年十月初 (2023/10/01),到 95.0% 了:

也許到九月底的時候有 97%+ 甚至 98%+ coverage,但 Android 的基數還是太大,就算到 98%+ coverage,預期到時候的影響應該還是不小,會不會再簽一年...?

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

停止使用 Spamhaus DNSBL

剛剛看到「If you query Spamhaus Projects’ legacy DNSBLs via DigitalOcean move to the free Data Query Service」這篇,覺得愈來愈詭異了,研究了目前的情況後決定停用 Spamhaus

現在已經愈來愈少自己架設 mail server 了,不過我自己還是留了幾個 domain 跑在自己架設的 Postfix 上面,最主要是 command line 下面用 Mutt 讀信還是蠻方便的,另外一方面是確保一個信箱是不受到大企業的管制。

如果不是拿套裝軟體直接架設的話,自己架設 mail server 會有不少東西要設定:在 MTA 這端通常會使用 DNSBL 擋掉已知會發 spam 的 IP address。

DNSBL 的原理不難,就是拿 IPv4 address 組合一個 hostname,透過 DNS 查詢就會知道這個 IPv4 address 是否在清單;換句話說,就是拿 DNS protocol 當作 API,當作資料庫查詢。

舉個例子來說,假設我要查 188.235.18.134 這個位置的情況 (從「Worst /24 blocks based on total spam count」這邊翻出來的),這邊使用 SpamCop 的清單,我先把 IPv4 address 反過來變成 134.18.235.188,然後再加上 SpamCop 所指定的 bl.spamcop.net,變成 134.18.235.188.bl.spamcop.net,接下來查詢就可以查到:

134.18.235.188.bl.spamcop.net has address 127.0.0.2

如果是 168.95.1.1 的話,同樣方法組合成 1.1.95.168.bl.spamcop.net 可以看到沒有在 SpamCop 清單內:

Host 1.1.95.168.bl.spamcop.net not found: 3(NXDOMAIN)

這邊選擇用 DNS 的好處包括了 DNS resolver 及 DNS library 自然的 cache,不需要 Postfix 這類 MTA 再自己實作 cache 層,對於有大量信件 (無論是正常的或是 spam) 進來的時候也不會造成提供清單的服務大量的負載。

回頭來說 Spamhaus 的情況,他們公告要擋 DigitalOcean 的理由很奇怪,因為 DigitalOcean 架設了自己的 mirror 所以他們不知道使用的量,要使用者去 Spamhaus 上註冊申請後拿到一個自己的 your_DQS_key.zen.dq.spamhaus.net 使用。

有了 unique key 在 query,這樣就給了 Spamhaus 很清晰追蹤資料,加上 Privacy Policy 裡面的資訊:

We may have to share your personal data with the parties set out below for the purposes set out in the table in paragraph 4.
[...]
– Third parties to whom we may choose to sell, transfer, or merge parts of our business or our assets. Alternatively, we may seek to acquire other businesses or merge with them. If a change happens to our business, then the new owners may use your personal data in the same way as set out in this privacy notice.

這樣就知道他們想要做什麼了...

另外一方面,查資料的時候發現他們已經擋掉 Google Public DNS 以及 Cloudflare DNS

這是我自己架設 Unbound 的查詢:

gslin@home [~] [05:09/W4] host 2.0.0.127.zen.spamhaus.org
2.0.0.127.zen.spamhaus.org has address 127.0.0.10
2.0.0.127.zen.spamhaus.org has address 127.0.0.4
2.0.0.127.zen.spamhaus.org has address 127.0.0.2

這是 Google Public DNS (8.8.8.8):

gslin@home [~] [05:09/W4] host 2.0.0.127.zen.spamhaus.org 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

Host 2.0.0.127.zen.spamhaus.org not found: 3(NXDOMAIN)

這是 Cloudflare DNS (1.1.1.1):

gslin@home [~] [05:09/W4] host 2.0.0.127.zen.spamhaus.org 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases: 

2.0.0.127.zen.spamhaus.org has address 127.255.255.254

在 Spamhaus 的「Frequently Asked Questions (FAQ)」這篇裡面有提到 127.255.255.254 的回應是「Query via public/open resolver」:

127.255.255.252	Any	Typing error in DNSBL name
127.255.255.254	Any	Query via public/open resolver
127.255.255.255	Any	Excessive number of queries

所以還蠻清楚這家的東西已經不能碰了...