Web Tracking 筆記

Browser Fingerprinting 與 Information Theory

Mon, 01 Jan 0001 00:00:00 +0000

Browser Fingerprinting 與 Information Theory #

上篇文章我們討論到 browser fingerprinting 需要使用許多 feature，每個 feature 的有用程度可能不太一樣。那，有沒有什麼方法可以衡量一個 feature 是否有用？每次 fingerprinting 時追蹤者對於使用者的認識增加程度都一樣嗎？還是有可能追蹤者拿到了 fingerprint 卻發現它沒什麼用？其背後都是在講同一件事情：browser fingerprinting 洩漏了多少「資訊」。於是我們進入了 Information Theory 的世界。

Information Theory 通常被翻譯成「資訊理論」，跟 theory of computation 計算理論不一樣，不要搞混了。Information Theory 出自 Claude Shannon 的 A Mathematical Theory of Communication，當時主要是在通訊的情境下做討論，但如今 Information Theory 已經四處可見，從最早的衡量通訊頻道可以承載多少資料、如何壓縮資料，到 Machine Learning 裡面討論每個神經元可以儲存多少資料，密碼學裡面有沒有什麼演算法可以抵擋無限計算資源與時間的攻擊者等，都是 Information Theory 的應用。

今天我們要討論的是，Information Theory 如何應用於 browser fingerprinting 的情境中。這篇文章會有一些數學，如果讀者對這些沒興趣，可以大膽地跳過這篇，對於後續文章的理解不會有太大的影響。

Information #

相信大家都知道 bit 是什麼。一個 boolean 是 1 bit，一個 ascii 會吃掉 8 bits。

FLoC，以及它為何失敗

Mon, 01 Jan 0001 00:00:00 +0000

FLoC，以及它為何失敗 #

此一系列的第一篇文章就要來看個失敗的案例：Google 的 FLoC（Federated Learning of Cohorts）。說它失敗，是因為其在 2020 年被提出後便遭遇許多攻擊與質疑，認為其可能非但沒解決問題，還加劇隱私侵害，隨著攻擊越來越強烈，最後 Google 在 2022 年 1 月宣佈放棄 FLoC，並提出取代之的 Topics。

也許讀者會趕到疑惑，為什麼要用 FLoC 這種已經被棄用的案例來開啟這個章節。其理由有二，首先是 FLoC 的設計邏輯非常有趣，至少在我眼中它所使用的演算法非常優雅；第二點是，FLoC 的設計乍看之下應該很安全，其隱私保護也有理論保證，於是為何它引發爭議、被認為侵害隱私，就成了一個有趣的問題。

FLoC 是什麼？想解決什麼問題？ #

Google FLoC 旨在取代 third-party cookie，成為下一世代的 cross-site tracking。重述過去一再提到的，third-party cookie 的功能之一是，藉由在網站埋入 tracker，追蹤者可以知道個別使用者瀏覽的網站並推測使用者興趣，但隨著 third-party cookie 將要被封鎖，追蹤者還是想要知道使用者興趣，故需要有個方法持續達成推測使用者興趣，同時又不能像以前一樣把瀏覽紀錄全部洩漏給追蹤者。

於是 FLoC 的設計者想到，如果追蹤者只是要知道使用者的興趣，為何需要這些瀏覽紀錄？或是說，對於興趣類似的使用者，追蹤者真的有需要知道個別使用者的瀏覽紀錄嗎？對廣告投遞來說，他們真正想知道的只有這群使用者興趣類似，可以投放類似的廣告。這正是 FLoC 所採取的解法。FLoC 全名是 Federated Learning of Cohorts，正如其名，它嘗試把使用者分成各種群組（cohort），於是追蹤者只要追蹤整個群組裡面的人即可，不會知道也不需要知道每個個別使用者的瀏覽紀錄。稍微更嚴謹來說，FLoC 達成了 k-anonymity，也就是每個使用者都藏在一個至少人的群組之中，他和其他個人看起來一模一樣。

Passive Fingerprinting

Mon, 01 Jan 0001 00:00:00 +0000

Passive Fingerprinting #

我們首先從 passive fingerprinting 開始談起。Passive fingerprinting 是那些只從請求內容就可以得出的特徵。此章節介紹三種：IP Address、HTTP request header、TLS。這些特徵用於 fingerprinting 時都不會使用到 JavaScript，只需要檢視請求內容即可。

IP Address #

IP address 幾乎可以說是最早用於 web tracking 的特徵，通常藉由 IP address 便可以把使用者定位在很小一個群體了。不過由於 IP address 時常變換，尤其在行動世代，使用者會一直換基地台、換 WiFi AP，偶而掛個 VPN，且大家共享 public IP address 的狀況已經是常態，IP address 已經沒什麼參考價值了。

User Agent #

User agent 是夾帶於 HTTP request header 的字串，其透漏了使用者的作業系統、瀏覽器與其版本等。舉例來說，我所使用的瀏覽器目前的 User Agent 是：

如何儲存 identifier：Cookie 以及那些意想不到的地方

Mon, 01 Jan 0001 00:00:00 +0000

如何儲存 identifier：Cookie 以及那些意想不到的地方 #

此文我們將討論 stateful 的 tracker 可以如何儲存它的 identifier。一個簡單的直覺是，不就存在 cookie 裡面嗎？是的，的確可以儲存在 cookie 內，但我們還有其他地方可以儲存，所以此文將介紹數個常見的儲存位置，以及他們的優劣。

只要可以儲存 identifier，就一定可以作到 same-site tracking，畢竟網站 A 存進去的 identifier，網站 A 當然讀得到。不過 cross-site tracking 卻不是如此，如果要做到 cross-site tracking，則追蹤者需要在不同網站維持同一個 identifier，如此才能知道兩個網站的訪客是同一個人，而在不同網站維持同個 identifier 並不是一個簡單的問題。因為cross-site tracking 的隱私危害遠大於 same-site tracking，故此文也會討論每個方法是否支援 cross-site tracking。其中 cookie 的 cross-site tracking 因為能討論的太多了，所以會放到明天的文章。

若論 stateful tracking，一個簡單的直覺是直接儲存於 cookie 中。確實，identifier 可以直接儲存於 cookie 中。事實上這也是最普遍的 web tracking 形式，更甚至可說是始祖等級的技術。因此這個章節無疑地應該以 cookie 作為開頭。

Fonts Fingerprinting

Mon, 01 Jan 0001 00:00:00 +0000

Fonts Fingerprinting #

每個人的電腦都裝有不同的字型，也可能有不同的預設字型，這所造成的影響，除了成為所有前端工程師的惡夢以外，也成為 browser fingerprinting 的 entropy 來源：既然每個人都有不同的字型，而且大家不會頻繁地安裝新的字型，那麼使用者設備所配備的字型便成為可用的特徵。我們將於此章介紹幾個可以找到瀏覽器裝有哪些字型的方法，以及 Fonts Fingerprinting 的危害。

在遠古時代，Flash 可以直接列舉出所有字型，但顯然現在沒有人在用 Flash 了。目前並沒有任何 API 可以直接枚舉出所有字型，也沒有 API 可以直接查詢一個字型是否存在，所以能做的只有，先列出所有我們想測試是否存在的字型，然後利用各種 side-channel 去依序測試哪些字型真的存在。

篩選待測字型 #

列出字型乍看之下並非難事，然而如何最有效率地找到足夠獨特的特徵，則不是個簡單的任務。核心要點是，所選的字型必須具有代表性。

一般而言，可以將網頁上的字型分為三類：

網頁字型：網頁自帶的字型。因為其不來自使用者的設備，這沒辦法用於 fonts fingerprinting。然而網頁字型的功能本身可以協助 fingerprint 其他字型。
系統字型：作業系統自帶的字型，通常使用該作業系統的裝置都會搭載該字型。雖然這可能有些用，但作業系統往往可以從其他方式做推論（例如 user agent），所以這個幫助也很有限。然而，在未來討論到一些有問題的防禦手段時，針對系統字型的 fingerprinting 可以派上用場。此外，部分作業系統會根據不同語言自動安裝不同字型，這使得特殊語言的字型可以用於 fingerprinting。
使用者自己安裝的字型：有些字型是使用者自己安裝的，無論是主動安裝，或是因為安裝一些軟體而被安裝（例如有些辦公軟體會自帶一些字型）。這些往往是最有 fingerprinting 價值，因為其通常足夠獨特。

因此，系統字型如「蘋方」（Apple 針對中文市場內建的字型）、Roboto（Android 與 Chrome OS 內建字型）等可以提供一些關於作業系統的資訊。一些使用者必須自行安裝的字型，或是隨著如 Microsoft Office、Adobe CC 等套裝軟體而一起安裝的字型，則因足夠獨特而成為 fingerprinting 的首選。像是 Arial 或 Times New Roman 等大家都有的字型，則不會有什麼幫助而可以直接忽略。

Topics API

Mon, 01 Jan 0001 00:00:00 +0000

Topics API #

Google Topics API是一個用於追蹤使用者的瀏覽紀錄，藉此投放使用者可能感興趣的廣告。與 FLoC 一樣，Topics API 透過分析使用者的瀏覽紀錄來推測使用者感興趣的「主題」（所以叫做 Topics），並將其提供給廣告業者，以便投放使用者會感興趣的廣告。Topics API 的推出旨在解決 FLoC 所引發的隱私爭議，它不讓追蹤者自己蒐集數據以追蹤使用者（群）的喜好，而是直接在瀏覽器裡面推測出使用者喜好之後，將推測結果傳給廣告業者，藉此免除這些廣告業者自己部屬追蹤器所可能造成的損傷。

Topics API 如何運作 #

首先，瀏覽器會為每個訪問過的網站分配一個主題，這個主題來自Google 預先整理出的四百多個可能主題列表1。例如，一個 cnn.com 的主題可能是「新聞」，而一個 amazon.com 的主題可能是「購物」。瀏覽器會內建一個很輕量的 ML classifier，這個模型會根據網站的域名來判斷網站的內容。例如 tennis.shop.example 可能會被歸類在「運動」類，但 shop.example/tennis 會因為 classifier 只能看到 shop.example 而被歸類在「電商」類。另外，這個分類是在客戶端完成的，所以其他人不會知道使用者造訪了哪些網站。

瀏覽器會將使用者的瀏覽紀錄轉換為一個主題的歷史紀錄。主題歷史紀錄是一個列表，其中包含了使用者瀏覽過的所有網站的主題，以及每個主題出現的次數。

接著，在每一個週期（epoch，目前定義是一週），瀏覽器會計算好五個最感興趣的主題給個別網站。每次網站呼叫 document.browsingTopics() 要求主題時，瀏覽器有 95% 的機率從五個最感興趣主題中選一個回傳，又有 5% 機率會隨機找一個主題回傳。接著在這個週期內，同個網站每次回傳的主題都會是一樣的，不同網站可能回傳不同的主題，但都是由那五個最感興趣主題中選出來的。無論是真的還是隨機的，這個主題會維持在主題列表中三週。

在下一個週期時，網站如果又請求了主題，瀏覽器會多給網站一個主題（一樣有 5% 是隨機選的），於是此時網站可以看到兩個不同主題。這個過程會一路重複到列表超過三個主題，也就是最早加入的主題已經存活達三週了，則會把最早的主題移除，以確保任何一個時間點網站能查到的主題至多只有三個。

以下表舉例（實際上主題列表並未排序，為講解方便故表中有排序）：

Web Tracking 的角色、用途與分類

Mon, 01 Jan 0001 00:00:00 +0000

Web Tracking 的角色、用途與分類 #

在開始討論具體技術之前，我還想額外討論 web tracking 常見的用途以及試圖解決的問題。畢竟 web tracking 這個領域存在各種不同技術是一回事，它們為何存在、當初發明它是想解決什麼，又是另一回事。我希望藉由這篇文章去讓大家了解到 web tracking 到底想解決什麼問題，而這個問題又為何會重要，甚至是需要被解決。

從不同使用情境，我們又可以把 web tracker 做分類，不同類型的 web tracker（追蹤器）可能有不同的特性與危害。雖然這與 web tracking 技術沒有直接相關，但可以讓我們更了解 web tracking 的生態。

Web Tracking 與廣告投放 #

若論 web tracking 的用途，基本上不外乎是用於廣告，在前面我們也有非常簡短地討論過兩者的關係。此處我們將稍微更仔細一點地討論 web tracking 與廣告投放的關係，以及這為何是個問題。

在傳統廣告的世界，廣告主只知道某個特定媒介有著特定類型的觀眾，例如百貨公司旁的公車站充滿了喜歡時尚潮流的人，閱讀親子雜誌的人多半是有小孩的人，每天晚上準時收看鄉土劇的人多半是年長者，

這些對於媒介與其客群的認識使廣告主可以粗略地投放廣告，例如親子雜誌上可能會有書籍與數位學習工具的廣告。然而，不同於傳統廣告分析其客群的普遍性質，數位廣告可以做到針對個人的分析，這項成就的一大背景來自於無所不在的行為追蹤與分析。

使用者若是安裝任何一個 adblocker，例如 uBlock origin、Ghostery等，並且瀏覽隨意一個網站。這些 adblocker 便會告訴使用者它攔截了多少 tracker，這些tracker 來自哪裡，以及對於一些更進階的 adblocker 而言：什麼資料被拿走了。舉例來說，當我造訪 Forbes 的網站時，可以看到非常多看 Forbes 應該沒什麼關聯的請求，這些請求都是由 tracker 發出的。

如何達成 Cross-site Tracking：Third Party Cookie & Cookie Syncing

Mon, 01 Jan 0001 00:00:00 +0000

在前一篇文章，我們討論了如何儲存 identifier，介紹了數個方法。其中幾個方法的介紹中，有提到這可以用來做 cross-site tracking，包含 cookie, HSTS supercookie, document cache, HTTP redirection cache 與 ETag。除了 Cookie 以外，在前文也都討論過可以如何防止了。此文將著重討論 cookie 如何作到 cross-site tracking，如何防禦。此外，我們將介紹一個與之相關的技術稱為 cookie syncing。

首先複習一下，在上一篇文章提過，cookie 以 domain 為單位區分，也就是 Same-origin Policy (SOP)，blog.example 和 news.example 的 cookie 是獨立、互不干擾也不能互相存取的；此外，cookie 會被自動夾帶於 HTTP requests，且可以用 HTTP response 設定。這兩個特性非常重要，之後會不斷用到。

Cookie 可以被分為兩種：first-party cookie 與 third-party cookie。兩者沒什麼根本性的不同，都是在瀏覽器儲存一些 key-value pairs。它們的差異如同其名稱所示， first-party cookie 是直接儲存於使用者造訪的 domain 底下，而 third-party cookie 則是儲存於其他 domain 底下。

Browser Fingerprinting 的防禦

Mon, 01 Jan 0001 00:00:00 +0000

Browser Fingerprinting 的防禦 #

在過去幾個章節中，每次介紹完 browser fingerprinting 的攻擊手段，都多少有提到一些防禦手段，所以這篇文不會著重在對於特定 fingerprinting 技術的防禦，而是對於防禦的整體策略分析，也就是防禦策略的大方向，並討論這些方向可能遭遇的問題，為何成功或失敗。如果讀者對特定 browser fingerprinting 技術的防禦有興趣，仍然應該回去檢視前面的章節。

為何 Anti-Fingerprinting 這麼難？ #

首先我們可能得先問，為什麼「有效的防禦」這麼難？或是說，anti-fingerprinting 可以如何搞砸？

試想，有個 tracker 用 screen.width 與 screen.height 做 fingerprinting，我的螢幕是 1920x1200，這個大小不算特別常見，為了避免被 browser fingerprinting，我決定改變 screen 的數值，於是我隨便選一個數值，像是 1234x5678。這下 tracker 拿不到我的真實螢幕大小了，它只會拿到我造假的資訊。這是個有效的防禦嗎？

過去我們討論過 surprisal 與 anonymity set 的概念，那時有提到一個很重要的觀念：一個 fingerprint 要有效，它必須足夠罕見，與足夠少人重複，也就是 surprisal 夠大，anonymity set 夠小。試問 1234x5678 比較獨特，還是 1920x1200 比較獨特？顯然是前者吧。Browser fingerprint 的重點不在於正確或是合理，而是足夠獨特。就算是錯的，只要錯得很獨特，一樣可以拿來做 fingerprinting。

Canvas Fingerprinting

Mon, 01 Jan 0001 00:00:00 +0000

Canvas Fingerprinting #

最早對 browser fingerprinting 都聚焦在一些明顯可見的、分布清楚的各種屬性，例如 user agent 的不同是一翻兩瞪眼的，任何人都看得出來。在 2012 年時，Mowery 與 Shacham 發現了一個 browser fingerprinting 方法： HTML5 的 Canvas API 在不同平台上 render 的結果的細微差異，利用這些細微差異，便可以提供足夠的資訊做 fingerprinting。因此，我只要讓 Canvas API 畫出一張圖，並取出繪圖結果，便可達成一個足夠獨特的特徵。這個發現徹底改變了 web tracking 的生態，也改變了大家對 browser fingerprinting 的看法。這可能是第一次有這麼高準確度又 practical 的 browser fingerprinting 方法，而且其特徵還是如此隱微的、肉眼完全不可見的差異。

前言 #

Canvas 直譯是「畫布」，顧名思義，這東西與畫圖有關。我們需要先區分 Canvas API 與 <canvas> 兩個看起來很像但其實不同的東西。Canvas API是一個可以讓 JavaScript 繪製 2D 圖形的工具，它提供了許多畫圖的 method，像是畫直線、畫矩形、填充顏色、插入文字等。<canvas> 是 HTML 的一個 tag，它如同其名，真的是個畫布，讓 Canvas API、WebGL API 等在其之上繪圖。

Unified ID 2.0

Mon, 01 Jan 0001 00:00:00 +0000

Unified ID 2.0 #

之前介紹的幾個技術都是嘗試在不需要識別出特定使用者的情況下推測使用者興趣（例如 FLoC 或 Topics API）或完成 conversion measurement（例如 PCM 與 IPA）。這些技術的目標都是想要用隱私保護的方式達成以前需要 web tracking 才能達成的功能。但此章要介紹的 Unified ID 2.0 採取了一條完全不同的路徑，他們認為傳統 third-party cookie 追蹤的問題在於這些追蹤往往並未獲得使用者同意，即便有同意，使用者也難以管理繁雜的隱私設定，因此新世代的 web tracking 該達成的是只有在使用者同意下可以進行追蹤，而且必須提供使用者足夠簡單且統一的方式管理他們的隱私設定。

Unified ID 2.0 (UID2) 是一個開源框架，可供網站、廣告商和數位廣告平台使用，以建立身分識別。隨著Google宣布計劃在2022年在 Chrome 上封鎖 third-party cookie，The Trade Desk迅速開啟了Unified ID 2.0的開發，嘗試在沒有 third-party cookie 的世界繼續達成 cross-site tracking。與傳統 third-party cookie 不同的是，Unified ID 2.0 將要求使用者在網站管理者建立 UID2 identifier 之前，需要明確地同意網站的隱私權政策（或其他條款），並提供其 email address。此外，會有一個集中化的管理單位負責 key management，而且使用者可以直接在這個單位上登記希望退出（opt-out）追蹤，已達成更友善的隱私管理。

Unified ID 2.0 如何運作？ #

UID2 的角色除了傳統廣告產業就有的那些以外，還額外有 UID2 administrator 與 UID2 operator。UID2 administrator 是一個集中化的服務，負責管理 UID2 ecosystem。他們的工作包括 key management，即產生與發布 key 給 UID2 operator 與 DSP。此外，UID2 administrator 還需要處理使用者的退出要求，並通知 UID2 operator 和 DSP。UID2 運營商則是負責生成和管理 UID2 及 UID2 token 所需基礎設施的組織。UID2 operator 從 UID2 administrator 那裡拿到 key 與 salt 。網站發布者可以可以通過 UID2 operator 的 API 請求 UID2 或 UID2 token。

殺死 Third-party Cookie，一樣可以做 Cross-site Tracking：CNAME Cloaking, Bounce Trackers, and Link Decorations

Mon, 01 Jan 0001 00:00:00 +0000

殺死 Third-party Cookie，一樣可以做 Cross-site Tracking：CNAME Cloaking, Bounce Trackers, and Link Decorations #

先前我們介紹了 third-party cookie 如何用於 web tracking，尤其 cross-site tracking。多數瀏覽器都已經封鎖或即將封鎖 third-party cookie，更何況在許久之前便已有不少人藉由 browser extension 或其他工具阻擋 third-party cookie，這使得傳統的 cross-site tracking 技術不再是穩定可用的。為此，追蹤者也開發了數種其他 cross-site tracking 的方法。在此章節，我們將介紹三種不使用 third-party cookie的 cross-site tracking 技術，分別是 CNAME cloaking、bounce trackers 以及 link decoration。

CNAME Cloaking #

CNAME Cloaking 是什麼 #

CNAME 是一種 DNS record 的型態，其所表達的意思大概是「我被稱為 tracker.example，但其實我就是 tracker-real.example」。

Browser Fingerprinting 的防禦如何失敗，以及 Privacy Paradox

Mon, 01 Jan 0001 00:00:00 +0000

Browser Fingerprinting 的防禦如何失敗，以及 Privacy Paradox #

在上一篇文章，我們介紹了 browser fingerprinting 的幾個防禦策略，並做了一個巨大的宣稱：anti-fingerprinting 超級難！在這篇文章，我們將對這個宣稱做更多討論，到底為什麼防禦這麼困難，常見的 anti-fingerprinting 策略又是如何失敗的。接著我們將討論 anti-fingerprinting 失敗如何造成為害。不同於常見的 attack & defense，如果 defense 失敗頂多就是 attack 會成功，在 browser fingerprinting 的世界，如果 anti-fingerprinting 失敗，反而會讓 browser fingnerprinting 更容易！這種「保護隱私失敗了反而會讓狀況變得更糟」有時被稱為 Privacy Paradox。

通常 anti-fingerprinting 都是在 browser extension 層級做，畢竟魔改 browser 沒那麼簡單，要大家轉而使用魔改過的 browser 也不容易，browser extension 相對簡單。然而 browser extension 的限制導致 anti-fingerprinting 很難做好。

修改數值的挑戰 #

一種常見的 anti-fingerprinting 策略是直接去修改可以作為 fingerprint 的數值。就只不過是改個數值而已，是可以有多難？寫 Javascript 的第一天不就知道可以用 = 賦值了嗎？

Private Click Measurement

Mon, 01 Jan 0001 00:00:00 +0000

Apple 的嘗試：Private Click Measurement #

這個章節我們將會討論 Apple 的 Private Click Measurement（PCM）如何作到 privacy-preserving 的 ad attribution 或 conversion measurement，並將討論 PCM 潛在的問題與挑戰。PCM 本身其實不是什麼高科技，也沒有像 FLoC 或 Topics API 有著很有趣的演算法（以及攻擊），而是一些基本甚至有些無聊的 heuristics。之所以選擇介紹它，主要在於它是少數已經被實際部屬的 privacy-preserving web tracking 技術，基本上只要是用 macOS 上的 Safari 或是 iOS，很可能都已經內建PCM，甚至被 PCM 追蹤過，因此它是個值得花時間下去了解的技術。

PCM 要解決什麼？ #

PCM 的核心目標是作到不洩漏隱私資訊的 ad attribution。Ad addtribution 指追蹤使用者點擊廣告之後的操作，例如使用者在 blog.example 點擊了廣告，被帶到 shop.example，如果他在 shop.example 做了像是註冊帳號、消費等行為，則 blog.example 會收到 shop.example 的通知。類似的需求不只在於廣告，所以有個指涉更廣泛且中性的用詞是 “conversion measurement”。

WebGL Fingerprinting

Mon, 01 Jan 0001 00:00:00 +0000

WebGL Fingerprinting #

WebGL Fingerprinting 分成兩個部份：WebGL Report Fingerprinting 與 WebGL Canvas Fingerpinting，後者基本上就是 canvas fingerprinting 的 WebGL 版本，所以才說他們是近親。WebGL Fingerprinting 利用了每台電腦在軟硬體上的不同，尤其是顯卡與顯示驅動不同，來做 fingerprinting。有趣的是，因為同一台電腦配備的顯卡一樣，所以 WebGL Fingerprinting 有可能用於跨瀏覽器的 tracking，不過這部份的討論會放到其他專文。

何謂 WebGL #

一言以蔽之，WebGL 是 OpenGL 的 Web 版本。WebGL 提供了一個介面（interface）讓開發者可以藉由 JavaScript 操作 OpenGL ES 的 API，因此得以借助此 API 在瀏覽器中實現 2D 與 3D 的繪圖，並輸出至 <canvas>，其中不需要使用瀏覽器外掛。WebGL 的程式大概包含幾個部份：JavaScript 控制主要邏輯，GLSL（OpenGL Shading Language）處理著色器的邏輯，然後 GPU 執行著色器的程式碼。

如何對付傳統追蹤技術 (I)：Content Blocking (Ad Blocking)

Mon, 01 Jan 0001 00:00:00 +0000

如何對付傳統追蹤技術 (I)：Content Blocking (Ad Blocking) #

在所有反制 web tracking 的方法中，最古早也最普遍被使用的方法是 content blocking。正如其名，content blocking 的邏輯很簡單，就是直接把 tracker 阻擋掉。假設現在 example.com/tracker.js 是個用於 web tracking 的 script，它會偷偷把使用者的瀏覽紀錄傳回 example.com，我們當然可以用各種方式（像是阻擋 third-party cookie）讓它沒辦法正確地辨識出我是誰，但有個更簡單的方式是：一開始不要讓 example.com/tracker.js 載入，不就沒問題了？這就是 content blocking 的核心精神。

Content blocking 聽起來像是一個很複雜的技術名詞，但有個與之密切相關且大家都聽過的東西叫做 “ad blocker”，現在主流的 ad blocker 幾乎都是藉由 content blocking 達到，也就是直接把取得廣告用的 Javascript 或其他資源（e.g. 圖片、影片等）的 request 阻擋掉。

在此文我不會嚴格區分 content blocker 與 ad blocker，因為兩者非常類似，很難界定。例如，幾乎所有的知名 ad blocker 同時都會阻擋 tracker，即便 tracker 並沒有在投放廣告。為了避免讀者誤以為 ad blocker 只是在阻擋可見的廣告，我將使用 content blocker 來稱呼這一系列的工具。

Interoperable Private Attribution

Mon, 01 Jan 0001 00:00:00 +0000

Mozilla 與 Meta 的嘗試：Interoperable Private Attribution #

最後一天我們要看的是 Mozilla 和 Meta 的 Interoperable Private Attribution（IPA，與啤酒沒有關係）。IPA 所要解決的問題與 PCM 非常相像，都是 conversion measurement / ad attribution，不過 IPA 的架構卻顯著地比 PCM 複雜非常多。此文我們會討論 IPA 的架構及特性，並會討論到 IPA 解決了什麼 PCM 的問題。

我猜也許不少讀者跟我一樣，看到 Mozilla + Meta 這個組合時感到很訝異，一個注重網路隱私的公司，與一個以侵害隱私而惡名昭彰的公司聯手開發一個隱私保護的 conversion measurement 機制，這肯定需要關注的。喔對，我想還是得把話說清楚。IPA 的系統架構很複雜，非常複雜，比這系列曾經介紹過的任何系統都還要更複雜。所以我們開始吧！

IPA 想解決什麼 #

IPA 與其他 privacy-preserving web tracking 一樣，試圖在一個沒有 third-party cookie 的時代做 tracking。IPA 旨在不追蹤特定使用者的情況下做 conversion measurement。如果不知道 conversion measurement 是什麼，可以參考之前介紹 FLoC 的文章。簡言之，廣告商需要知道廣告的曝光、點擊和各個事件之間的對應關係，例如使用者點擊廣告之後有做消費、有註冊帳號等。過去要達成這點，需要仰賴 third-party cookie 做追蹤，或是在 native app 會仰賴某些 identifier，但這其實會造成不必要的隱私侵害，廣告商不需要也不該知道個別使用者的操作，只需要知道最後的統計結果就好了。IPA 嘗試使用 MPC 與 differential privacy 等技術來達到這個目標。

WebRTC Fingerprinting + Media Device Fingerprinting

Mon, 01 Jan 0001 00:00:00 +0000

WebRTC Fingerprinting + Media Device Fingerprinting #

此章將介紹兩個與 WebRTC 有關的 browser fingerprinting 技術。WebRTC fingerprinting 利用 WebRTC 的設計，有可能洩漏使用者的 public 與 local IP address，甚至即便使用 VPN 亦可能洩漏真實 IP address，不過這個漏洞已經被修補。Media device fingerprinting 則是利用了 browser 可以取得攝影機、麥克風等多媒體設備的特性，枚舉出多媒體設備並以此作為 fingerprint。

WebRTC (Web Real-Time Communication) 是一個允許網頁取得影音媒體、串流影音（或任意資料）的 API。最常見的應用是線上會議軟體，網頁擷取了攝影機與麥克風的輸入，並將其串流出去。另外一個應用是在瀏覽器上做 P2P（peer-to-peer）的檔案傳輸。WebRTC 的一大特色是，這是一個 P2P 的傳輸協定，也就是資訊串流不經過伺服器，而是直接在兩個瀏覽器之間互相傳輸。

WebRTC Fingerprinting #

WebRTC 使用 P2P 通訊，為了找到兩端之間的路徑，勢必需要知道對方的位置。可是如果客戶端躲在 NAT1 裡面或防火牆後面，便拿不到 public IP address，也就無法告訴對方自己在哪邊，因而無法建立 WebRTC 連線。為了確保 WebRTC 在這種情境下仍然可以建立連線，開發者可以使用 ICE（Interactive Connectivity Establishment）。ICE 旨在尋找最佳的連線路徑。首先，ICE 嘗試使用作業系統和網卡提供的 IP address 連線，如果裝置在 NAT 後面，當然會失敗；接著 ICE 會藉助STUN（Session Traversal Utilities for NAT）伺服器取得 public IP address；如果仍然不行，ICE 會再藉由 TURN（Traversal Using Relay NAT）中繼伺服器轉送資料。STUN 伺服器的任務很簡單：檢查請求的 IP address，並將其回傳給請求者，從而使請求者可以知道自己的 public IP address 與 port。如果 ICE 可以成功得到有效的連線資訊，便能提供 WebRTC 使用，以此建立 P2P 連線。此外，為了讓內網之間的兩端在建立連線時，可以不用經過外網繞一整圈，ICE 也會掃描所有網路介面（interface）並取得對應的 local IP，以偵測有沒有不繞外網一大圈的路徑。上面的描述有著許多簡化，不過此處重點是：藉由 STUN server，WebRTC 可能可以拿到所有介面的 local 與 public IP address，並且有可能因為存取了 VPN client 以外的介面而繞過 VPN，即便躲在 VPN 後面，一樣可以拿到真實的 public IP address。

如何對付傳統追蹤技術 (II)：如何繞過基於 Filter List 的 Content Blocking

Mon, 01 Jan 0001 00:00:00 +0000

如何對付傳統追蹤技術 (II)：如何繞過基於 Filter List 的 Content Blocking #

正如任何資安領域，只要有攻擊，就會有防禦，只要有防禦，就會有繞過。既然 content blocking 會阻擋 tracking script，也就有人會嘗試繞過。如同前面所提到的，content blocker 在識別 tracking script 與廣告的手段中，最主流的是使用黑名單。因此，如何繞過黑名單自然會是最受人矚目的問題。此文將整理數個技術上可行的辦法，有些很常見，有些則是可遇不可求甚至很奇葩的。

稍微複習一下。Filter list 可以分成兩種型態：

Resource blocking：封鎖整個 domain 或特定 URL path，讓 request 無法發出
Element hiding：隱藏或刪除特定的 DOM element
因為後者主要是做 ad blocking，對於防禦 tracker 沒什麼幫助，所以本文會著重在 resource blocking 的繞過。

常見的繞過方式 #

更改 URL paths #

一個很直覺的方法是，既然 URL path 會被封鎖，那我就把 URL path 改掉，不就繞過 filter list 了？舉例來說，假設 tracker.example/tracker.js 被封鎖了，那就改成 tracker.example/tracker2.js，如果又被封鎖了，就繼續改。出乎意料的是，這方法超級有效。因為多數 filter list 是靠社群夥伴通報與維護，如果追蹤者更改 URL path，往往要等到有人發現並通報後，maintainer 才能將其加入 filter list。改檔案位置只需要花幾分鐘的時間，但 filter list maintainer 可能要好幾天甚至好幾個月後才會發現 filter list 被繞過了。

WebAudio Fingerprinting

Mon, 01 Jan 0001 00:00:00 +0000

Audio Fingerprinting #

Audio fingerprinting 是指涉利用 Web Audio API 來做 browser fingerprinting 的技術。Web Audio API 是個專門用於在 browser 處理音訊的 API。一如往常的，有人發現 Web Audio API 在不同的軟硬體設備上會產生不同的結果，而且在同一台電腦的同一個瀏覽器上，所產生的結果很穩定與持久，所以可以用來做 fingerprinting。

Web Audio API #

Web Audio API 是一個在 browser 中處理音訊的 API，其可以建立音訊、載入現存音訊、加入特效等。整個操作流程都是在 AudioContext 底下完成，以 audio nodes（音訊節點）作為音訊作業的基本單元，這些 audio nodes 可以互相連接，建構出 audio routing graphs（音訊路由圖）。Audio routing graph 起於一個或多個音訊來源（可以是動態產生的或載入現存檔案），音訊來源會將音訊取樣，切成很多個 sample。接著，音訊的 sample 會順著路由經過各種處理，例如調整音量、加入特效、混音等。當音訊已經走完所有處理程序，最後就會走到整個 audio routing graph 的終點：可能是播放出來或是儲存進一個 buffer。

如何對付傳統追蹤技術 (III)：Apple’s Intelligent Tracking Prevention (ITP)

Mon, 01 Jan 0001 00:00:00 +0000

如何對付傳統追蹤技術 (III)：Apple’s Intelligent Tracking Prevention (ITP) #

在介紹完最傳統的 content blocking 後，接下來我們來看點比較新穎的技術。傳統 content blocking 在乎的是盡可能不要載入 tracker，不過現在較為新穎的技術在乎的是，即便真的載入 tracker 了，也要把傷害降到最低。首先我認為最值得拿出來討論的是 Safari 的 Intelligent Tracking Prevention (ITP)。如果平常有在關注蘋果的發表會，應該會發現他們很喜歡強調 Safari 防止 web tracking 的機制做得多好，其中很重要的一環就是 ITP。故此文我們將介紹 ITP 的運作方式。

在開始前想提醒一下，因為 ITP 更新的速度其實蠻快的，在我撰文時 ITP 的最新版是 3.0（其實 3.0 不是官方稱呼，不過官方好像也沒給個版本號），如果有數年後回來的讀者，可能要注意一下有些東西是過時的。原本想說這篇文章可以從我前年的筆記改寫就好，結果 ITP 改的東西多到不如重寫一篇 QQ

背景介紹 #

從 2017 年起，Safari 內建了一款名為 Intelligent Tracking Prevention (ITP) 的隱私保護機制。ITP 的主要目標是解決 cross-site tracking，至於 same-site tracking，雖然也有一些防護機制，但那不是重點。因此 ITP 與之前介紹的 content blocking 的目標略有不同，content blocking 目標是所有 web tracking 機制，無論 same-site 或 cross-site。因為 ITP 內建於 Safari，而 macOS 與 iOS 又有很高的市占率，尤其 iOS 上只有 Safari 可以用（其他都是包著 Safari 皮的瀏覽器，感謝 Apple 的壟斷地位），因此 ITP 對於廣告與追蹤產業的影響力不容小覷。

Browser Extensions Fingerprinting

Mon, 01 Jan 0001 00:00:00 +0000

Browser Extensions Fingerprinting #

Browser extension（有時譯為「擴充套件」）是指像是 ad blocker、MetaMask 等附加於 browser 之上，可以改變瀏覽器與網頁呈現、行為、功能等的程式。它們通常使用 JavaScript、HTML 和 CSS 編寫，並藉由瀏覽器 API 與瀏覽器進行互動，並為瀏覽器添加新的功能或改進現有功能。然而，既然 browser extension 可以改變網頁呈現與擴充功能，如果我們可以偵測到網頁的行為或呈現方式改變了，是不是就意味著可以偵測到一個 browser extension 存在。而且，每個人安裝的 browser extension 都不太一樣，於是只要能偵測哪些 browser extension 存在，便可將使用者有安裝的 browser extension 列表作為 fingerprint。這正是 browser extension fingerprinting 的核心概念。

此外，追蹤者還可以根據使用者安裝了哪些 browser extension 做更進一步的 profiling。例如，如果偵測到有安裝一些開發工具，那使用者大概是工程師。或甚至，如果有偵測到一些防毒軟體用於提醒惡意網站的 browser extension，則可能透漏使用者啟用某款特定防毒軟體，這些資訊洩漏在做攻擊時將很有價值。

Browser Extension 簡介 #

首先，我們必須先理解 browser extension 是什麼。一開始必須先釐清 browser extension 不是 browser plugin，後者如今已經不常見了。Browser plugin 的主要功能是，它可以註冊一些它支援的 content type，當瀏覽器遇到這種 content type 時，就會呼叫 browser plugin 來處理該資料。Browser plugin 通常是直接跑在作業系統的執行檔（executable）。早期通常使用 NPAPI（Netscape Plugin API），它比 IE 還要古早，基本上已經沒人使用，取而代之的有 Chrome 的 PPAPI 和 IE 的 ActiveX，但兩者也都已經沒落。Browser plugin 常見的應用有像是 Flash Player、WebATM、自然人憑證程式之類的。

如何對付傳統追蹤技術 (IV)：Firefox’s Tracking Protection

Mon, 01 Jan 0001 00:00:00 +0000

如何對付傳統追蹤技術 (IV)：Firefox’s Tracking Protection #

看完 Safari 的隱私保護，下一個來看 Firefox 的保護機制。Mozilla 也同樣在隱私上花了許多心力，開發了許多精彩的防禦機制。Firefox 的保護機制大概分成幾個部份，我們將依序介紹之。

Enhanced Tracking Protection #

Firefox 最主要的防禦機制是 Enhanced Tracking Protection (ETP)。雖然取了一個很潮的名字，但 ETP 本質上就是 content blocking，不過 Mozilla 花了許多心思在確保網站不會因為 content blocking 而壞掉。

ETP 所使用的 filter list 來自 Disconnect，並且會去區分不同性質的 tracker（例如 social media trackers, cross-site tracking cookies, fingerprinters, cryptominers 等），此外，ETP 也有區分模式，Standard 會阻擋多數的 tracker，Strict 則會連那些躲在廣告或影片播放器裡面的 tracker 都擋掉，當然使用者也可以根據自己的需求去選擇哪些 tracker 要阻擋掉。

Ad Blocker Fingerprinting

Mon, 01 Jan 0001 00:00:00 +0000

Ad Blocker Fingerprinting #

曾經我們討論過，阻擋 tracker 的方法中，最廣泛被使用的是 filter list，也就是去列出我想要阻擋的黑名單，然後 ad blocker 會根據 filter list 去阻擋 tracker。Ad blocker 不但可以改善使用體驗，還可以藉由阻擋 tracker 來減少隱私侵害。Ad blocker 的運作方式已經在前文討論過，簡單來說，ad blocker 會阻擋 filter list 上指定的 HTTP request 以及隱藏指定的 DOM element，而這些改變是可以被有效偵測的。

另外，在 Ad blocker 的世界中，並不存在一個世界統一的 filter list，雖然會有幾個最大咖的（e.g. Easylist），但也會有眾多不那麼知名的但同樣好用的（e.g. Peter Lowe’s Ad and tracking server list）、針對特定語系的（e.g. AdGuard Japanese）、針對特定類型內容的（e.g. Online Malicious URL Blocklist）。如果全部 filter list 都啟用，可能造成效能不彰，所以使用者會根據自己需求去挑選他需要的 filter list，或是 ad blocker 可能會根據系統語言去自動地啟用相對應的 filter list。於是作為中文使用者，我會使用針對中文網站的 filter list（e.g. Easylist China），但不會去用針對德文網站的 filter list（e.g. EasyList Germany），反正我也不會瀏覽德文的網站。

CPU Fingerprinting

Mon, 01 Jan 0001 00:00:00 +0000

CPU Fingerprinting #

如果前面兩篇 browser extension 的 fingerprinting 還沒有嚇倒你的話，從這一篇開始，我們會進入一個很瘋狂的狀態，一種「天啊這樣也行喔？」的狀態。

那，首先就從 CPU fingerprinting 開始講起吧。這篇文章會用到一些計算機結構的基礎知識，都是非常簡單的東西，所以只要是我在修計算機結構時聽過的詞彙，就不會多加解釋，畢竟我金魚腦，這麼多年前修課而且現在還記得，應該就代表多數有修過計結的都會記得… 吧？

何謂 CPU Fingerprinting #

雖然說是 CPU fingerprinting，但我們不是要去 fingerprint 每個 CPU 之間的些微差異，而是要去識別一個 CPU 的重要特徵，像是幾個 core、cache 多大等，藉此作為 fingerprint 的一部分。

CPU fingerprint 除了拿來做 web tracking 以外，也有其他用途，像是情蒐之類的，例如這幾年很多基於 speculative execution 和 out-of-order execution 的各種 side channel attack，如果可以了解對象所使用的 CPU，便可以發動攻擊。

不過 CPU fingerprint 之所以說是瘋狂，就在於它很難！當代的 browser 基本上都有很嚴密的 sandbox，可以執行的指令很受限，盡可能避免 browser 上執行的任何程式可以獲得過多的資訊。基本上在 browser 上能做的也就只有 Javascript 與 WebAssembly，頂多運用 Just-in-time compiler 的特徵來做更多事情，但仍非常受限。此外，如果要在 browser 上做針對 CPU 的 timing attack 或其他 side-channel attack，會受到許多影響，畢竟 browser 自己就有非常受限的 scheduling 的機制、OS 再一層 scheduling，再加上各種 noise，許多有用的資訊都被掩埋在雜訊中了。所以，要在 browser 上執行一些程式來洩漏 CPU 資訊沒有那麼 trivial。

Battery Status Fingerprinting

Mon, 01 Jan 0001 00:00:00 +0000

Battery Status Fingerprinting #

HTML5 提供了一些使網頁開發者得以取得硬體資訊的 API，其中一個是 Battery Status API，其原本是用來讓網站監控裝置的電池狀態，以提供更好的用戶體驗。電池狀態有許多優勢，例如，開發者可以根據使用者的電量來決定要提供高效能版本或省電版本，或當然也有可能用於一些不那麼正當的用途，例如 Uber 發現使用者在手機快沒電時傾向於接受比較高的價格1。這個功能看起來非常無害，甚至標準制訂者一開始也不認為這可能有什麼安全性威脅。然而，2015 年時，Olejnik 等人發現，該 API 也可能被用來進行 browser fingerprinting。更甚至，2016 年時 Englehardt 等人發現真的有 tracker 正在積極地使用 Battery Status API 做 fingerprinting。我們將這種技術稱為 Battery Status Fingerprinting。

Battery Status API #

Battery Status API 可以提供一些關於電池的資訊，包含電量（level，0.0 ~ 1.0）、是否在充電（charging，布林值）、預期還有多久可以充滿電（chargingTime，整數秒）、預期還有多久會消耗完電池（dischargingTime，整數秒）。

navigator.getBattery().then(console.log);


Scheme Flooding
Mon, 01 Jan 0001 00:00:00 +0000

 Scheme Flooding
 #

之前我們看到可以藉由使用者安裝的 browser extension 來做 fingerprinting，於是不禁想問：電腦上裝的應用程式有沒有可能也拿來做 fingerprinting？或是更重要的，有辦法在 browser 上知道系統有哪些應用程式嗎？今天想來介紹一個很有趣的 Browser Fingerprinting 技術稱為 scheme flooding。許多應用程式有所謂的 “custom URL scheme” 或是 “custom protocol handler”，例如 skype:, spotify:, itunes: 等，當瀏覽器看到這些 protocol handler 時，便會嘗試打開相對應的應用程式。這個功能看似好用，但可能打開新的 attack vector。假如我可以窮舉所有 protocol handler，看哪些會有反應，似乎就可以知道使用者安裝了哪些應用程式，並藉由這項資訊來做 profiling 與 tracking。這就是所謂的 scheme flooding。
大家可以嘗試到這個網站看看你的瀏覽器有沒有出賣你：https://schemeflood.com/
但在開始之前，我想要先針對一些用字與定義做一些說明。在此文中我把 scheme flooding 定位成一種 browser fingerprinting 技術，但這樣的定義會有兩種問題。首先，scheme flooding 在發現者眼中是一種「可以達成 fingerprinting 的漏洞」，而不是單純的 fingerprinting 技術，在
 有些媒體上也稱之為漏洞，此處我無意開啟何謂漏洞的討論，而是只想把重點著重在：這個特性可以被用來做 fingerprinting，至於它本身是不是漏洞，並非此文討論的重點。此外，scheme flooding 是 fingerprinting 技術，但它算是 browser fingerprinting 技術嗎？這部份涉及了 browser fingerprinting 的嚴格定義，不過考慮到 scheme flooding 符合 (1) 只需要在 browser 上做運算，而沒有儲存任何內容，也就是 stateless 的，以及 (2) 其所刺探的資訊與 browser 所運行的 OS 有關（嚴格來說，OS 之中安裝了哪些程式），所以我還是想將其定義為 browser fingerprinting。如果讀者不認同我的定義，一來我很期待能聽到不同意見，二來即便此文在讀者眼中可能用字不精確，但我相信還是會有些幫助的。


Fingerprinting via CSS
Mon, 01 Jan 0001 00:00:00 +0000

 Fingerprinting via CSS (JS-less Fingerprinting)
 #

過去我們討論 browser fingerprinting 時，總是離不開 JavaScript，無論是蒐集 JavaScript 本身的性質或是利用 JavaScript 去蒐集瀏覽器其他的性質，都建立在我們可以使用 JavaScript，事實上多數 browser fingerprinting 都需要 JavaScript 才可以執行。但如果沒有 JavaScript，還有可能做 browser fingerprinting 嗎？這篇文章將會討論，如果沒有 JavaScript，如何單純使用 CSS 達到 browser fingerprinting。
不過可能要先澄清一下，「停用 JavaScript 可以避免 browser fingerprinting」這樣的建議沒有錯，有鑑於幾乎所有 tracker 都還是仰賴 JavaScript，這是個完全合理且有效的策略。我只是要展示如何作到沒有 JavaScript 的 browser fingerprinting，沒有要反駁這個建議。甚至我認為本章節所介紹的各種 Javascript-less Fingerprinting 技術主要還是有趣而已，實用價值遠不如前面提過的其他 browser fingerprinting 方法。
Browser fingerprint 的過程可以分為三大步驟：1) 讀取各個 feature 的值；2)聚集起來製成 fingerprint；3) 回傳給 server。第一步是否需要 JavaScript 取決於是什麼特徵。至於第二步，乍看之下，似乎需要 JavaScript 才能作到這樣的複雜運算，只有 CSS 大概是做不太到，但是如果把聚合成 fingerprint 的環節移動到 server-side，客戶端只負責蒐集好資訊並回傳給伺服器，則似乎就可以不用到 JavaScript 了。至於第三步，雖然除了 JavaScript 以外還有許多方式發請求，但如果沒有 JavaScript 在中間幫忙傳遞數值，可以使用的方法也會相對受限。在以下討論中，我們並不會特別區分三個步驟，但讀者可以尤其注意每個部分分別對應到上面三個步驟的哪一步。

Web Tracking 筆記

Browser Fingerprinting 與 Information Theory

Browser Fingerprinting 與 Information Theory #

Information #

FLoC，以及它為何失敗

FLoC，以及它為何失敗 #

FLoC 是什麼？想解決什麼問題？ #

Passive Fingerprinting

Passive Fingerprinting #

IP Address #

User Agent #

如何儲存 identifier：Cookie 以及那些意想不到的地方

如何儲存 identifier：Cookie 以及那些意想不到的地方 #

Cookie #

Fonts Fingerprinting

Fonts Fingerprinting #

篩選待測字型 #

Topics API

Topics API #

Topics API 如何運作 #

Web Tracking 的角色、用途與分類

Web Tracking 的角色、用途與分類 #

Web Tracking 與廣告投放 #

如何達成 Cross-site Tracking：Third Party Cookie & Cookie Syncing

如何達成 Cross-site Tracking：Third Party Cookie & Cookie Syncing #

First-party & Third-party Cookie #

Browser Fingerprinting 的防禦

Browser Fingerprinting 的防禦 #

為何 Anti-Fingerprinting 這麼難？ #

Canvas Fingerprinting

Canvas Fingerprinting #

前言 #

Unified ID 2.0

Unified ID 2.0 #

Unified ID 2.0 如何運作？ #

殺死 Third-party Cookie，一樣可以做 Cross-site Tracking：CNAME Cloaking, Bounce Trackers, and Link Decorations

殺死 Third-party Cookie，一樣可以做 Cross-site Tracking：CNAME Cloaking, Bounce Trackers, and Link Decorations #

CNAME Cloaking #

CNAME Cloaking 是什麼 #

Browser Fingerprinting 的防禦如何失敗，以及 Privacy Paradox

Browser Fingerprinting 的防禦如何失敗，以及 Privacy Paradox #

修改數值的挑戰 #

Private Click Measurement

Apple 的嘗試：Private Click Measurement #

PCM 要解決什麼？ #

WebGL Fingerprinting

WebGL Fingerprinting #

何謂 WebGL #

如何對付傳統追蹤技術 (I)：Content Blocking (Ad Blocking)

如何對付傳統追蹤技術 (I)：Content Blocking (Ad Blocking) #

Interoperable Private Attribution

Mozilla 與 Meta 的嘗試：Interoperable Private Attribution #

IPA 想解決什麼 #

WebRTC Fingerprinting + Media Device Fingerprinting

WebRTC Fingerprinting + Media Device Fingerprinting #

WebRTC Fingerprinting #

如何對付傳統追蹤技術 (II)：如何繞過基於 Filter List 的 Content Blocking

如何對付傳統追蹤技術 (II)：如何繞過基於 Filter List 的 Content Blocking #

常見的繞過方式 #

更改 URL paths #

WebAudio Fingerprinting

Audio Fingerprinting #

Web Audio API #

如何對付傳統追蹤技術 (III)：Apple’s Intelligent Tracking Prevention (ITP)

如何對付傳統追蹤技術 (III)：Apple’s Intelligent Tracking Prevention (ITP) #

背景介紹 #

Browser Extensions Fingerprinting

Browser Extensions Fingerprinting #

Browser Extension 簡介 #

如何對付傳統追蹤技術 (IV)：Firefox’s Tracking Protection

如何對付傳統追蹤技術 (IV)：Firefox’s Tracking Protection #

Enhanced Tracking Protection #

Ad Blocker Fingerprinting

Ad Blocker Fingerprinting #

CPU Fingerprinting

CPU Fingerprinting #

何謂 CPU Fingerprinting #

Battery Status Fingerprinting

Battery Status Fingerprinting #

Battery Status API #