Privacy-preserving Web Tracking on Web Tracking 筆記

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，也就是每個使用者都藏在一個至少人的群組之中，他和其他個人看起來一模一樣。

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% 是隨機選的），於是此時網站可以看到兩個不同主題。這個過程會一路重複到列表超過三個主題，也就是最早加入的主題已經存活達三週了，則會把最早的主題移除，以確保任何一個時間點網站能查到的主題至多只有三個。

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

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。

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

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 等技術來達到這個目標。