跨瀏覽器追蹤的方式

看到「Exploiting custom protocol handlers for cross-browser tracking in Tor, Safari, Chrome and Firefox」這個方式,跨瀏覽器收集 fingerprint 追蹤。

這次用的方式是透過 handler 追:

The scheme flooding vulnerability allows an attacker to determine which applications you have installed. In order to generate a 32-bit cross-browser device identifier, a website can test a list of 32 popular applications and check if each is installed or not. On average, the identification process takes a few seconds and works across desktop Windows, Mac and Linux operating systems.

最近大家比較常使用到的應該就是 Zoom 從網頁把應用程式帶起來的方式:

而要怎麼偵測的部份,用到了不同瀏覽器的 side channel。

Chromium 系列的部份對應的 ticket 在「Issue 1096610: External Protocol handler anti-flood protection is ineffective and flaky」這邊有被提出來。主要用到的方法是,在遇到有 handler 時,連打兩次時會被擋下:

被擋下後再打都會失敗,所以需要一個方式重設 flag,而內建的 Chrome PDF Viewer 剛好可以重設 flag:

The built-in Chrome PDF Viewer is an extension, so every time your browser opens a PDF file it resets the scheme flood protection flag. Opening a PDF file before opening a custom URL makes the exploit functional.

Firefox 的 side channel 則是可以透過 same-origin policy 測試當作 side channel,對應的 ticket 在「Scheme flooding technique for reliable cross-browser fingerprinting」這邊:

Every time you navigate to an unknown URL scheme, Firefox will show you an internal page with an error. This internal page has a different origin than any other website, so it is impossible to access it because of the Same-origin policy limitation. On the other hand, a known custom URL scheme will be opened as about:blank, whose origin will be accessible from the current website.

Safari 上的問題與 Firefox 一樣,不過沒登入看不到 ticket (也懶的註冊了):

You are not authorized to access bug #225769. To see this bug, you must first log in to an account with the appropriate permissions.

另外,雖然 Tor Browser 底層是 Firefox,但因為有改變預設值,所以攻擊者也得換方法:

Tor Browser is based on the Firefox source code, so the Same-origin policy trick was used here as well. But because Tor Browser does not show pop-ups, we used the same-origin policy trick with iframe elements instead.

這個方法還蠻暴力的...

用 uBlock Origin 過濾 URL 裡面的 tracking parameter

在「ClearURLs – automatically remove tracking elements from URLs (github.com/clearurls)」這邊的討論裡面看到 gorhill (uBlock Origin 的作者) 的回文,裡面提到了 uBlock Origin 目前也有支援 removeparam 了,而且有對應的 filter list 在維護這個表格:

不過他也有提到 CleanURLs 可以清更多東西:

Addendum: to be clear, this is not a replacement for ClearURLs. ClearURLs has more capabilities then just removing query parameters from the URLs of outgoing network requests.

但這樣起來也不錯了 (尤其是對於只裝 uBlock Origin 的情況下),可以訂起來...

Firefox 87 推出 SmartBlock 阻擋 3rd-party tracking

Firefox 87 推出了 SmartBlock,試著阻擋各種追蹤器:「Firefox 87 introduces SmartBlock for Private Browsing」,不過這不是一般的預設值,而是只有 Strict 模式與無痕模式會用到。

對於追蹤的問題,最早的作法是直接擋掉 3rd-party tracking javascript 的載入,但有很多網站會因為對應的變數沒有初始化而造成 javascript error。

這次的 SmartBlock 其實就是在各家阻擋套件實做很久的方式,插入一小段客製化的 javascript 讓網站裡的 javascript 可以呼叫,但實際上不會送任何資料出去,像是 uBlock Origin 的「unbreak.txt」。

不過 Firefox 重複搞這麼多東西,要不要考慮直接把 uBlock Origin 內建進來啊...

Firefox 在 Strict Tracking Protection 模式下閹割 Google Analytics

Twitter 上看到 Firefox 在 Strict Tracking Protection 模式下會閹割掉 Google Analytics

剛好可以跟另外一篇「Google Analytics: Stop feeding the beast」一起看,這篇主要是對網站管理端的說明,你可以使用其他對隱私保護比較好的服務,或是考慮自己架設。

回到使用者端的部份,在 Firefox 裡面 Browser Privacy 預設是 Standard,換成 Strict 後就會觸發這個行為:

不是直接擋掉到 google-analytics.comgoogletagmanager.com 的連線,而是把 javascript 抽換掉,讓呼叫的程式碼完全不會做事。

在 Strict 模式下,除了會閹割 Google Analytics 外,也有其他的 js 會被閹割 (像是 Facebook 的),可以在 GitHub 上的「gecko-dev/browser/extensions/webcompat/shims/」這邊翻到。

這個功能很明顯在 Google Chrome 上不會內建,但很久前就有套件可以用了。目前比較常見的作法是透過 uBlock Origin 做,而且是在內建的「uBlock filters – Privacy」這組定義裡面就有實做,對應到 GitHub 上的 privacy.txt 這邊可以看到:

! Redirect to neutered Google Analytics 
||google-analytics.com/analytics.js$script,redirect=google-analytics.com/analytics.js

! Redirect to neutered Google Analytics Experiments
||google-analytics.com/cx/api.js$script,redirect=google-analytics.com/cx/api.js

不過 Firefox 上的 uBlock Origin 與其他套件也有類似的功能,真的在意的人應該早就使用了...

原來 Disqus 已經被網路廣告公司買走了...

在「Disqus, the dark commenting system」這邊才看到 Disqus 被網路廣告公司買的消息:

Disqus was acquired by an advertising company called Zeta Global in 2017. Obviously, advertising companies do everything to increase their revenue (Ex: the Big G).

引用的報導則是在「Zeta Global acquires commenting service Disqus」這邊可以看到,大約在三年前發生的事情...

基本上已經變成廣告追蹤平台了:

I analyzed the network requests log. Disqus makes HTTP requests to 11 different third-party domains through the browser. All of these websites are trackers/pixels (Even some were detected as malware by my security guard).

而且就算是付費會員也一樣,還是會追蹤:

When you provide a free product, money should come from somewhere. Disqus uses advertising for that. Now, I subscribed to a paid plan trial of Disqus to see if things change or not. No! Even in the paid plans, the same pixels are loaded on the client-side. Looks like there's no way to opt-out from tracking.

後面的推薦可以看看就好,自己架應該還是比較好的選擇... 用「open source comment system」搜有些東西可以參考。

Trac 開發版 1.5.1 對 Python 3 的說明

Trac 開發版 1.5.1 的 Change Log 裡可以看到說明:

This will be the only release in the 1.5.x release line that supports Python 2.7. Future releases will support Python 3.5+.

先前在 mailing list 上有看到 Python 3 的計畫,不過好像是第一次在 changelog 裡面看到說明了...

把自己的 Trac 換到 1.4

八月底的時候就已經出 Trac 1.4 了 (參考當時寫的「Trac 1.4」),不過當時升級一直失敗:

$ trac-admin ./ upgrade
Error: Unable to check for upgrade of trac.db.api.DatabaseManager: TracError: Unsupported database type "mysql"

後來在「TracError: Unsupported database type “mysql”」這邊找到解法,下面有人提到解法是裝系統的 python-pymysql,那麼對應到 pip 的套件安裝時,裝 PyMySQL 就可以了。

另外一個比較麻煩的就是 Trac 的 XmlRpcPlugin 套件,這個套件其實一直都很 hack,常常是自己硬幹底層的東西跳過現有機制 (於是像是透過他開 ticket 時,就不會發通知信之類的問題),但目前暫時又不能不用他...

Anyway,這東西在升級後也爛掉了:「Plugin fails on Trac 1.4」,然後下面看到 Gasol 修了一版出來:「Gasol/trac-xmlrpcplugin」。

另外是我自己有掛 custom theme 的套件 ThemeEnginePlugin 也爛掉了,不過這個暫時移除就好,之後再排進去修...

最後就是把本來的 css/js 都依照「Customizing the Trac Interface」的說明,porting 到 Jinja2 下。

主要就是把本來的 site.html 裡面的片段搬到 site_head.htmlsite_footer.html 裡,然後 CSS 的部份照著建議拆到 style.css 裡 (因為 css selector 的 id selector # 在一行開頭的位置會被 Jinja2 當作命令處理)。

後續繼續看看還有什麼要修正的,另外 wiki 也得等摸索差不多後更新...

Webkit 的「反追蹤反追蹤」功能...

第一次看到標題的時候的確是 WTF 的感覺,愈來愈感覺到大戰的開始:「Preventing Tracking Prevention Tracking」。

在蘋果的平台上有 Intelligent Tracking Prevention (ITP) 功能,但先前這個功能比較簡單,所以還是有很多地方可以被當作 browser fingerprint 的一部份分析,所以蘋果決定改善,然後在新版的軟體裡引入:

This blog post covers enhancements to Intelligent Tracking Prevention (ITP) included in Safari on iOS and iPadOS 13.3, Safari 13.0.4 on macOS Catalina, Mojave, and High Sierra.

包括了跨站台時 Referer 的省略:

ITP now downgrades all cross-site request referrer headers to just the page’s origin. Previously, this was only done for cross-site requests to classified domains.

然後後面三個改善都跟 3rd-party cookie 有關,其中預設擋掉帶 cookie 的 3rd-party requests 應該會讓一些網站掛掉:

ITP will now block all third-party requests from seeing their cookies, regardless of the classification status of the third-party domain, unless the first-party website has already received user interaction.

早期自己做自家 SSO 的奇技淫巧中,會設計出透過 ajax 打多個不同的網域自動登入,看起來應該會需要檢查了...

Trac 1.4

剛剛看到 Trac 出了 1.4 的消息,雖然還是在用 Python 2:「Release Notes for Trac 1.4 Jinja Release」。

其中一個比較大的改變是 template engine 換掉了,從 Edgewall 自家的 Genshi 換到 Jinja2 上,目前看起來兩者都可以用,但可以預期現有的 template 要找時間換過去:「5 times speed-up when rendering query results, thanks to the migration from Genshi to Jinja2.」。

其他的改變應該還好,找個週末來把自己的 Trac 備份起來測試好了...

Apple 對 Tracking 機制的宣言 (宣戰)

Apple 透過 WebKit 的 blog 公佈了對 tracking 技術的宣言 (或者說「宣戰」):「Announcing the WebKit Tracking Prevention Policy」,完整的文件在「WebKit Tracking Prevention Policy」可以看到。

相關的報導可以參考「Apple will soon treat online web tracking the same as a security vulnerability」。這篇會這樣下標題主要是這點:

We treat circumvention of shipping anti-tracking measures with the same seriousness as exploitation of security vulnerabilities.

不過技術上還是很困難,現在在瀏覽氣上有太多方式可以被拿來追蹤分析。

另外也不用認為蘋果是什麼善類,他只是不太靠廣告賺錢,所以會決定站出來把隱私保護當產品在推銷,哪天有什麼奇怪的特例跑出來的時候也不用太意外...