德國法院認為 DNT header 具有法律的告知效力

HN 上面看到「German court declares Do Not Track to be legally binding (vzbv.de)」這個消息,原文是德文:「Gericht untersagt Datenschutzverstöße von LinkedIn」,Google Translation 翻譯的結果:「Court bans LinkedIn data protection violations」。

LinkedIn 告知使用者他們不會理會 DNT,德國法院則是認為 DNT header 是已經告知對方不願意被追蹤了:

„Wenn Verbraucher:innen die ,Do-Not-Track‘-Funktion ihres Browsers aktivieren, ist das eine klare Botschaft: Sie wollen nicht, dass ihr Surfverhalten für Werbe- und andere Zwecke ausgespäht wird“, sagt Rosemarie Rodden, Rechtsreferenin beim vzbv. „Webseitenbetreiber müssen dieses Signal respektieren.“

“When consumers activate the 'Do Not Track' function of their browser, it sends a clear message: They do not want their surfing behavior to be spied on for advertising and other purposes,” says Rosemarie Rodden, legal officer at vzbv. “Website operators must respect this signal.”

這好像是第一次看到 DNT 相關的法律判決?可以看看後續有沒有新的消息 (上訴之類的),來看看最終的判決會是怎麼樣。

擋 YouTube 短影音的設定

短影音類的影片因為沒有知識量 (沒有 reference 可以確認正確性),我完全不會看... 但 YouTube 上一般的影音我會翻,所以就會冒出這個需求了。

YouTube 的短影音有幾個地方會出現 (補充一下,我這邊是用英文版介面):

  • 首頁的左邊,會有一個 Shorts 的連結可以點進 Shorts 看。
  • 首頁的推薦裡面也會有 Shorts 的 section。

這兩個情況用這兩條擋:

www.youtube.com##a[title="Shorts"]
www.youtube.com##ytd-rich-section-renderer

這邊要注意的是,後者除了擋掉 Shorts 以外,還會擋掉各種 YouTube 的推銷 (像是電影之類的),這個也是我要擋的,所以我這邊直接用了 ytd-rich-section-renderer 這個元素來擋。

再來是各種穿插在頁面裡面的 Shorts 內容,像是首頁、訂閱頁與搜尋結果頁,這些就要找出對應的元素來擋:

www.youtube.com##ytd-reel-shelf-renderer
www.youtube.com##ytd-video-renderer:has(a[href*="/shorts/"])

另外一個跟短影音無關,但還是很影響專注度的是,YouTube 的搜尋結果會給你一堆很干擾結果的推薦,像是「People also watched」、「For you」、「Previously watched」以及「From related searches」,也可以設定擋掉:

www.youtube.com##:matches-path(/results) ytd-shelf-renderer[thumbnail-style]

目前用的差不多是這些...

Firefox 的 :has() 支援度問題

Can I Use... 上面的「:has() CSS relational pseudo-class」裡面可以看到 Firefox 一直都還沒支援,只有在 nightly 版本上面預設有開,這也代表還沒辦法很穩定的用這個 selector... (除非你直接忽略掉 Firefox)。

看到「Prodding Firefox to Update :has() Selection」這篇,Eric Meyer 在抱怨 Firefox 的這個問題,就算是 nightly 的版本也還是有奇怪的 bug,會抓不到 :has() 條件,需要用 contenteditable 的 workaround 觸發 Firefox 的計算。

MozillaBugzilla 上可以看到票還開著:「Implement the :has() pseudo class」,看起來這陣子是一直有在更新,應該是有資源在上面追進度。

等到真的支援,就可以在 querySelectorAll() 裡面直接用 :has() 了,現在 Firefox 的情況讓 Userscript 寫起來有點卡...

ISP 偽造出合法的 SSL certificate,對放在德國的 xmpp.ru 進行 MITM 監聽

標題有點複雜,先講一下 http-01 認證,這是目前 Let's Encrypt 上最常被使用的認證方式,是透過 HTTP 協定完成認證,你只要能回答 http://www.example.com/.well-known/acme-challenge/XXX 的內容就能過。

一般來說,這個 HTTP 位置只有這台伺服器的 owner 才有辦法提供,也就能確保不是任何人都可以申請。

但因為這邊走的是 HTTP,對於 ISP 這種比較特別的身分來說,他可以從中架設 HTTP 的 MITM Proxy 做到這件事情。

而有了合法的 SSL certificate 之後,中間的 MITM Proxy 就不只能聽 HTTP 了,還可以聽 HTTPS 的內容 (甚至修改內容)。

這次發生的事情就是在德國的 LinodeHetzner 機房內的服務,俄羅斯最大的 XMPP 服務 xmpp.ru 被搞出這件事情 (XMPP 是一個開放協定,不熟的話可以想像成類似 Line 或是 Telegram 的服務,但 XMPP 是開放協定,可以用自己喜歡的軟體連上):「Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service」。

他們在 Hetzner 的伺服器上有發現 network offline 的訊號:

[Tue Jul 18 12:58:29 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Down
[Tue Jul 18 12:58:48 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

而在這個 network offline 的時間不久後 Let's Encrypt 發出了 xmpp.ru 與 jabber.ru 的 SSL certificate (crt.sh 上可以查到,在 99976947049997621208):

18 July 2023 issuing time is about the same when Hetzner server has lost network link for several seconds.

這些徵兆符合改接到 MITM Proxy 上的行為。

這次的事情很大條,因為這些伺服器是在德國,不是在俄羅斯... 事情才剛開始被報導出來,後續得繼續追蹤,而且應該也會促成新的機制被引入?

查詢 Debian 與 Ubuntu 官方的 apt repository 的版本資訊

因為在寫「Python 3 的支援週期」這篇時需要查不同作業系統版本下的 python3-minimal 版本資訊,一開始是到 packages.ubuntu.com 上查,但上面只列出了目前還有支援的作業系統的套件。

所以就到 Ask Ubuntu 上面問:「How to search package information on unsupported Ubuntu distribution」。

看起來有兩個方法可以拉到歷史資料,一個是 devscripts 裡面的 rmadison,直接帶入要查的套件名稱就可以了:

$ rmadison python3-minimal

另外一個是到 https://ubuntu-archive-team.ubuntu.com/madison.cgi 這邊查,這個位置也是 rmadison 預設的 backend,資料應該是一樣的。

而加上 -u debian 可以改查 Debian 這邊的資訊,用 -h 可以看到還有那些 alias 可以用。

目前 Ubuntu 這邊可以查到最舊的版本是 trusty (14.04),如果要更舊的版本資訊,需要去 launchpad.net 上面翻,像是 https://launchpad.net/ubuntu/precise/+package/python3-minimal 這個。

WordPress.com 支援 ActivityPub

Hacker News 上看到「WordPress.com Now Supports ActivityPub (wordpress.com)」這則,在講 WordPress.com 宣佈支援 ActivityPub:「Engage a Wider Audience With ActivityPub on WordPress.com」。

Hacker News 上的 id=37849725 這篇的說明其實更清楚,其實是 plugin 被 Automattic 買走後包裝起來的行動:

It is more accurate to say that the ActivityPub plugin[1] which was acquired by Automattic has hit 1.0 and is available to be used on WordPress.com. Yes, Mastodon implements (most of) ActivityPub but it's hardly the only platform on the web that does.

[1] https://wordpress.org/plugins/activitypub/advanced/

Anyway 這是個不錯的發展... 之後 Mastodon 上可以直接訂這些 blog 了?

Cloudflare 正式推出 ECH (Encrypted Client Hello)

Cloudflare 宣佈所有的 Plan 都支援 ECH 了:「Encrypted Client Hello - the last puzzle piece to privacy」。

要講 ECH 之前,會先提到 Domain fronting 這個避開網路審查 (censorship) 的技巧,這是利用 CDN 服務裡對 SNI 的處理與對 HTTP header 的處理分開的特性,算是一種 side effect 的搞法,不保證會動,但蠻多 CDN 的服務都會動。

實際上的作法就是在 SNI 層的 hostname 填寫一個沒有被審查的 Hostname (像是 www.akamai.com),然後連到 www.akamai.com:443 上,也都使用 www.akamai.com 的 SSL certificate 交換。

但在 HTTP header 上面則是送出不一樣的 hostname (但也必須是在這家 CDN 的機器上有提供服務的網域),通常是被管制的網域名稱,像是 Host: www.cnbc.com 這樣的 HTTP header;而因為這部份被 TLS 保護,無法從外部看到內容而可以穿過網路審查。

理論上 CDN 服務是可以 reject 這樣的連線的,但大多數的 CDN 廠商並沒有阻擋這麼嚴格,於是算是一種堪用的方式。而這次 ECH 算是把這個行為標準化了,就不需要再用 side effect 的方式了。

Cloudflare 本身就很大,可以來看看後續的效應...

X/Twitter 又繼續在搞競爭對手的外部連結了...

八月的時候提過「X/Twitter 在惡搞外部連結結果被抓包玩陰的」這個,X (Twitter) 故意對某些網站 delay 個幾秒鐘再重導,當時爆料出來後就馬上拿掉了,結果這幾天又被抓到故技重施:「Twitter is Still Throttling Competitors’ Links—Check for Yourself」。

依照測試,Meta 家的 FacebookInstagram 以及 Threads 都中獎,另外沒什麼意外的,Twitter 前頭頭跳出來開的 Bluesky 也都有被搞...

而且這次爆料出來後也沒有「迅速修正」了,到目前也都還是如此... 來看看後續?

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。

X/Twitter 在惡搞外部連結結果被抓包玩陰的

這算一個歷史記錄,現在已經改回來了...

Hacker News 上看到 X (前 Twitter) 惡搞他們不喜歡的外部連結,然後被抓包,以及恢復的故事:「Tell HN: t.co is adding a five-second delay to some domains」。

有人發現 t.co 指到 nytimes.com 或是 threads.net 的連結會有很固定的五秒 delay:

Go to Twitter and click on a link going to any url on "NYTimes.com" or "threads.net" and you'll see about a ~5 second delay before t.co forwards you to the right address.

Twitter won't ban domains they don't like but will waste your time if you visit them.

I've been tracking the NYT delay ever since it was added (8/4, roughly noon Pacific time), and the delay is so consistent it's obviously deliberate.

然後就被 Washington Post 報導出來了:「Elon Musk’s X is throttling traffic to websites he dislikes」,在報導後沒多久,這個機制就被取消掉了。

居然玩陰的 XDDD