抽象

????????網絡跟蹤是一種普遍且不透明的做法，可實現個性化廣告、重新定位和轉化跟蹤。 隨著時間的推移，它已經演變成一個復雜的侵入性生態系統，采用越來越復雜的技術來監控和分析整個 Web 上的用戶。

????????研究社區在分析新的 Web 跟蹤技術、設計和評估對策的有效性以及評估隱私法規的合規性方面有著悠久的記錄。 盡管在網絡跟蹤方面進行了大量工作，但文獻仍然分散在范圍不同的研究中，因此很難確定總體趨勢、連接新的相關技術以及確定該領域的研究差距。

???????? 如今，Web 跟蹤正在經歷一場千載難逢的變革，這是由廣告行業的根本轉變、瀏覽器采用反跟蹤對策以及新興隱私法規的日益執行所推動的。 這種知識系統化 （SoK） 旨在整合和綜合這些廣泛的研究，全面概述塑造現代和快速發展的 Web 跟蹤領域的技術機制、對策和法規。 該 SoK 還強調了開放的挑戰并概述了未來研究的方向，旨在為研究人員、從業者和政策制定者提供統一的參考和介紹材料。

????????在線用戶訪問 Web 上的各種免費內容和服務，這些內容和服務主要通過在線廣告獲得資金。 反過來，廣告嚴重依賴出于各種目的監控用戶的在線活動 例如 Analytics、個性化（重新）定位和轉化跟蹤。 為了實現這些目標，用戶跟蹤已成為 Web 的普遍組成部分。 到 2025 年，僅美國的在線廣告就將超過 4000 億美元[1].

????????自 1990 年代中期在 Web 上引入 cookie 以來，Web 跟蹤已演變成一種更加普遍和復雜的做法。 第三方跟蹤器的普及率有所增加，目前約有 92% 的網頁嵌入了至少一個跟蹤器. 此外，用戶跟蹤和分析通常涉及收集用戶的個人詳細信息（例如姓名、電子郵件和位置）、設備特征（例如設備型號和作系統）、瀏覽歷史記錄和行為信號（例如在頁面上花費的時間和執行的交互）。 因此，網絡跟蹤已成為在線隱私研究的一個活躍領域。

????????研究人員進行了大量研究，以檢查 Web 跟蹤機制、瀏覽器開發和法規遵從性的演變。 然而，盡管有如此大量的工作，主要發現仍然分散在許多不同的研究中。 此外，隨著瀏覽器中隱私防御的改進，跟蹤器不斷適應新的規避技術. 結果是跟蹤技術的技術格局不斷變化。 跟蹤做法通常由法規管理，并確保瀏覽器提供必要的保護以保護用戶隱私。 盡管這些監管變化的影響比基于瀏覽器的技術干預更為緩慢，但它們共同繼續重塑生態系統。 如今，由于在主要 Web 瀏覽器中引入了隱私增強保護措施和不斷發展的監管框架，Web 跟蹤正在發生變革性變化。 在線廣告的最新進展包括引入隱私保護范式[5]以及在 Web 上采用生成式 AI. 鑒于這些變化，全面、系統地研究不斷發展的跟蹤環境中的新興趨勢以確定關鍵的研究差距是重要且及時的。 因此，研究界顯然可以從整合和系統化知識狀態的統一資源中受益，幫助研究人員為該領域做出有意義的貢獻，并確保采用結構化的方法來解決新的隱私問題。

????????為此，在本 SoK 中，我們綜合了 Web 跟蹤的不同研究和實踐——跨越技術機制、瀏覽器緩解以及監管變化——以系統地提供 Web 跟蹤當前狀態的概述。 我們將這項工作的范圍限定為如何收集有關用戶的數據，而不是如何使用這些數據。?這種統一的視角使我們能夠批判性地反思社區已經走了多遠，以及它在研究方向方面下一步應該走向何方。 我們的貢獻如下：

• ?

  我們系統地組織了關于網絡跟蹤的廣泛研究，提供了該領域進展的綜合知識庫，突出不斷發展的趨勢，橋接新興但相關的跟蹤機制，并確定該領域的差距。

• ?

  我們概述了歐盟和美國基于瀏覽器的主要反跟蹤干預措施和相關監管框架，以評估它們多年來如何改變生態系統。

• ?

  我們確定了網絡跟蹤領域的關鍵開放挑戰和有希望的未來方向，供社區在未來幾年內解決。

????????在線跟蹤擁有大量文獻，包括過去幾十年發表的大量研究。 因此，我們首先進行了一項文獻調查，以確定過去 20 年（2005 年以后）在七個頂級網絡安全和隱私場所（IEEE S&P、USENIX Security、ACM CCS、NDSS、ACM IMC、PETS 和 WWW）中的任何一個發表的所有與 Web 跟蹤相關的論文。 共確定了 200+ 篇研究論文。

????????根據論文摘要，為每篇論文分配了一個或多個與 Web 跟蹤相關的主題。 主題分配由兩位研究人員在 Clarke 和 Braun 之后共同進行[10]主題分析方法。 共確定了 84 個主題，其中排名前 15 位（按論文數量計算）是跟蹤測量、第三方跟蹤、瀏覽器指紋識別、cookie 同意、cookie、分析、跟蹤中的用戶研究、移動跟蹤、廣告攔截、法規遵從性、JavaScript 跟蹤、瀏覽器擴展指紋識別、廣告和跟蹤檢測以及隱私。 我們將在論文被接受時公開論文的主題組織。 我們利用我們的領域專業知識圍繞這些突出的主題構建了 SoK，如本文其余部分所述。

????????Web 由基于 HTTP（S） 協議構建的客戶端-服務器架構組成，其中瀏覽器（客戶端）向服務器發送 HTTP 請求（由指定方案（協議）、主機（域名）和資源路徑的 URL 標識），將請求的資源共享為 HTTP 響應。

網站結構：典型的網站由嵌入了大量資源的主要 HTML 文檔組成。

????????這些資源要么托管在用戶直接訪問的網站的 Web 服務器上（即第一方），要么托管在其他 Web 服務器（即第三方）上。 HTML 文檔定義了網頁結構，并由瀏覽器解析以構建文檔對象的邏輯表示，即?DOM 或文檔對象模型。 概括地說，資源以兩種方式包含在網頁中：（1） 作為內聯內容，直接包含在 HTML 標簽中（例如，<style>、<script>?或?<img>?標簽）或 （2） 作為獲取內容的外部引用（例如，<script src=“...”>、<img src=“...”>?和?<iframe src=“...”>). 當瀏覽器處理 HTML 以構建 DOM 時，它會立即呈現內聯內容（如文本和圖像）或執行腳本，并且對于每個外部包含，它會發出額外的 HTTP 請求來檢索這些資源。 值得注意的是，不同的資源類型在包含在網頁中時具有不同的行為。 圖像或視頻被視為被動內容，無法執行代碼，但會觸發對主機 Web 服務器的加載請求。 而從外部 URL 獲取的腳本在加載后可以在包含頁面的上下文中執行。?<iframe>?是一種特殊情況，它將完全獨立的 HTML 文檔嵌入到父頁面中。 因此，單個網頁的上下文中可以存在多個參與方。

瀏覽器的 Origin 模型：Web 瀏覽器使用稱為 “origin” 的嚴格邊界，它被定義為方案（協議）、主機（域或 IP 地址）和端口的三元組。

????????只有當所有三個組件都完全匹配時，兩個 URL 才具有相同的來源。 瀏覽器還根據有效的頂級域加 1 （eTLD+1） 將相關源站分組為更廣泛的“站點”概念[11]使用公共后綴列表[12]. 此源邊界是 Web 安全的基礎：通過標記和隔離每個源的內容，瀏覽器可確保來自不同源（或站點分組）的代碼和數據無法讀取、修改或惡意干擾彼此的狀態。 這種強制措施稱為同源策略 （SOP）[13].

瀏覽器的上下文模型：瀏覽上下文是包含文檔和腳本環境的環境（例如，HTML 中的全局窗口對象）。

????????實際上，它對應于瀏覽器選項卡、窗口、包含加載的網頁或其任何 iframe 的大型機[14]. 當網頁加載時，瀏覽器會創建一個新上下文（或使用現有上下文進行導航）并將其與頁面的源相關聯。 第三方 iframe 在嵌套瀏覽上下文中運行，其中包含一個單獨的文檔，該文檔使用其自己的來源進行標記。 每個上下文在 DOM 和 JavaScript 運行時方面都是隔離的，默認情況下，一個上下文中的代碼不能任意干擾另一個上下文中的文檔，尤其是在它們的來源不同時。 瀏覽器通過使用活動文檔的來源標記每個上下文并在上下文之間強制執行邊界來維護這種隔離。

瀏覽器的安全模型：上下文-源邊界：瀏覽上下文模型表示每個文檔都在一個容器（框架或窗口）中運行，該容器將其狀態（例如其 DOM、變量和腳本）與其他文檔分開，而瀏覽器的源模型將文檔與確定代碼權限的源相關聯。

???????? 因此，瀏覽器在實施策略時同時使用源和上下文 - 它將不同的上下文彼此隔離，當嘗試交互時，它會檢查所涉及的源。 如果兩個瀏覽上下文共享同一源，則允許它們作為同一信任域的一部分自由交互，否則它們不能在 SOP 下進行交互。

瀏覽器強制實施的腳本執行策略：腳本的執行權限與其上下文的來源相關聯，這意味著它始終“充當”其文檔所具有的任何來源。

????????因此，當外部腳本包含在文檔中的源與包含文檔的源不同的源時，瀏覽器不會強制實施任何基于源的限制。 該腳本以包含它的上下文的完全權限執行 — 它可以訪問包含頁面的 DOM，以該頁面的身份發出網絡請求，讀取和設置該頁面的存儲，并且通常執行該頁面自己的腳本可以執行的任何作。 包含行為表示網頁的隱式信任聲明，就好像它信任具有自己來源權限的代碼一樣[11].

瀏覽器強制實施的瀏覽器存儲策略：瀏覽器提供的客戶端存儲機制（例如?localStorage、sessionStorage?和?IndexedDB）按源分區。

????????因此，來自一個源的腳本無法讀取或寫入另一個源的存儲。 但是，瀏覽器處理 Cookie 的方式有一個值得注意的例外 — Cookie 的范圍是按域（和路徑）確定的，而不僅僅是完整的來源。 Cookie 可以是 JavaScript Cookie 或 HTTP Cookie。 從功能上講，它們都將數據存儲在用戶的瀏覽器中，但是，它們的訪問方式和范圍不同。 HTTP Cookie 會自動讀取并包含在網絡請求中，或者由瀏覽器根據指定 Cookie 的域和路徑信息使用相應的標頭從響應中設置。 而 JavaScript Cookie（即使用 JavaScript 或未標記為 HTTPOnly 的 HTTP Cookie 設置的 Cookie）由瀏覽器中運行的客戶端腳本設置和/或訪問。 JavaScript Cookie 可由在同一執行上下文中運行的任何腳本訪問（例如，使用?document.cookie?或 CookieStore API），無論其來源如何。 這意味著主執行上下文中包含的第三方腳本可以讀/寫第一方 Cookie。 JavaScript Cookie 在查詢字符串或請求負載中與遠程服務器共享。

????????我們的 Web 跟蹤威脅模型考慮了四個主要實體：用戶、瀏覽器、第一方網站和網站中包含的第三方。 用戶是通過瀏覽器（也稱為用戶代理）訪問 Internet 上的網站的個人），尋求對他們的在線行為保密，因此被視為受害者。 瀏覽器協調用戶與 Web 內容之間的所有交互，執行第 3 節中描述的不同策略。 第一方網站是用戶直接訪問以瀏覽內容的網頁。 它通常包括來自第三方的資源，這些資源不會被用戶直接訪問，并且通常托管在與第一方網站不同的域上. 跟蹤器是指其目標是收集有關用戶活動的數據以監控或識別用戶在網絡上的行為的任何一方。 我們將第一方和第三方跟蹤器視為對手，其目標是收集有關用戶的最大信息。

圖 1?提供了我們模型的概念性概述，其中?news.com?和?sports.com?是用戶從其個人設備訪問的第一方網站。

tracker1.com?和?tracker2.com?是嵌入在第一方網站中的第三方。

對手的目標。用戶數據可分為兩類：

（1） 標識符（如電子郵件）或識別信息（如網絡、軟件或硬件配置）。

（2） 瀏覽活動，包括用戶訪問的網頁和執行的網站交互。

跟蹤鏈接的目標可以分為不同的范圍：

同一站點。該跟蹤鏈接旨在監控或識別同一第一方網站上的多次訪問或頁面加載的回訪用戶。

跨站點。嵌入在多個不相關的第一方網站上的跟蹤鏈接通常旨在唯一地識別和跟蹤這些網站上的用戶，以便將不同的網站活動鏈接到同一用戶。

跨設備。跟蹤鏈接還可能旨在識別使用不同設備或瀏覽器瀏覽互聯網的同一用戶。 總之，攻擊者的主要目標是持久且唯一地標記用戶或用戶的瀏覽器/設備，并隨著時間的推移跨導航、站點和時間收集與該標簽相關的用戶數據，用于分析、分析或廣告定位等目的。

此外，跟蹤器的第二個目標可能是避免檢測或預防，即跟蹤器盡管采取了反跟蹤措施，但仍旨在實現其目標。

對手的能力。為了實現其目標，可以在包含、收集、存儲和共享用戶數據的上下文中解釋對手的能力，但要遵守第 3 節中討論的瀏覽器的上下文來源限制。 攻擊者被認為有足夠的能力在存在這些瀏覽器強制執行的策略限制或繞過這些限制的情況下跟蹤用戶。

包容性。假定第一方跟蹤鏈接直接監控大型機上下文中的用戶活動。 第三方跟蹤鏈接可以作為內聯資源（例如，圖像/腳本標簽）嵌入到大型機上下文中，由第一方假設信任委派，在其源下具有單獨上下文的 iframe（即，具有自己的 DOM、狀態和資源），或者作為第三方 iframe 中的資源，與大型機上下文隔離。

集合。跟蹤鏈接旨在通過執行 JavaScript 代碼或讀取瀏覽器存儲，通過可用的瀏覽器功能收集用戶數據。

存儲。跟蹤鏈接可以使用?localStorage、sessionStorage、indexedDB?和 cookie jar 在用戶的瀏覽器中讀取、寫入或修改數據。 跟蹤器可以在后續訪問同一站點或不同站點時訪問存儲的數據。

共享。接下來，攻擊者的目標是與自己的服務器或合作伙伴的跟蹤服務器共享收集到的用戶數據。 為此，跟蹤鏈接可以通過以下四種方式之一發起包含用戶數據的網絡請求：（1） 作為請求 URL 查詢參數，（2） 請求負載，（3） 請求標頭，或 （4） 通過 HTTP Cookie。 方法 1-3 要求跟蹤腳本明確包含用戶數據，而與跟蹤器域關聯的 HTTP Cookie 會自動包含在對跟蹤器服務器的所有請求中。 我們使用此威脅模型來了解不同的 Web 跟蹤機制及其隨時間的演變。

跟蹤用戶最直接的方法包括在他們的瀏覽器中存儲唯一標識符，并在他們瀏覽不同的網站時檢索或修改它，這是一個稱為“狀態跟蹤”的過程。 瀏覽器提供了許多接口（例如?cookie），這些接口旨在將狀態與用戶的訪問相關聯。 瀏覽器還提供了許多接口，這些接口將信息存儲為提供給網站的其他功能（例如，電子標簽、HSTS 升級）的副作用，跟蹤鏈接有時會濫用這些功能來編碼唯一標識符。

Cookie — 由 Netscape 的 Lou Montulli 于 1990 年代首次指定 — 允許瀏覽器通過 HTTP（一種無狀態協議）與 Web 服務器通信時保持狀態[20]. 例如，網站可以通過 Cookie 將用戶的身份驗證令牌存儲在瀏覽器中，然后隨用戶瀏覽器發出的每個請求一起呈現給 Web 服務器，從而允許網站驗證用戶的身份驗證狀態。 瀏覽器調解哪些資源和域能夠訪問特定 Cookie

?

網頁上的第一方或第三方域可以設置和接收 Cookie，可以分別通過網絡請求和響應中的?cookie?和?set-cookie?標頭，也可以通過?document.cookie?JavaScript 方法。

在第一方上下文中，Cookie 允許重新識別用戶到他們訪問的網站，而在第三方上下文中，它允許跨站點跟蹤。 例如，在圖 2?中，news.com?和?sports.com?都包含帶有?tracker.com?廣告的 iframe。 因此，用戶的瀏覽器將發送相同的?tracker.com?Cookie，并請求在兩個頁面上加載 iframe。?tracker.com?服務器端，這兩個請求可以歸因于同一用戶，并與有關用戶訪問的網站的其他信息相結合。

第三方 Cookie 的隱私問題早在引入時就被發現隨著公眾對 Web 跟蹤的關注上升到 FTC 在 1997 年舉辦了一次關于該主題的研討會. 盡管如此，多年來，cookie 一直是網絡跟蹤的主要形式。

少數網站中包含的第三方只能跟蹤有限數量的網站上的用戶[25,26]. 此外，根據 SOP 限制，網頁上的第三方無法通過直接向其發起請求來與另一個第三方域共享其 cookie。 為了克服這些限制并交換在不同網站上收集的有關用戶的信息，第三方公司依賴于 cookie 同步或 cookie 匹配[27,28,29,30,31,32]—最初由 Olejnik 等人描述。[33]也被 Roesner 等人命名為“引用跟蹤”。[25].

?

此機制依賴于同步兩個不同第三方已知的用戶標識符，這些標識符通常存儲在第三方 Cookie 中，并且通常通過 URL 參數進行通信。 根據前面的示例，我們假設有兩個跟蹤鏈接 —?tracker1.com?和?tracker2.com。 如果?news.com?上僅存在?tracker1.com（如圖 3?所示），則它可以通過發起對?tracker2.com?的請求并將其添加到 URL 參數中來共享存儲在第三方 Cookie 中的用戶標識符。 這將允許?tracker2.com?知道用戶對?tracker1.com?的標識符，將其與?tracker2.com?的用戶標識符進行匹配，并在服務器到服務器之間通信，以進一步合并通過?tracker1.com?和?tracker2.com?收集的有關此用戶的信息。

傳統上，跟蹤像素（也稱為不可見像素）過去是嵌入在網頁上的基本 1x1 圖像元素，它指向某個跟蹤端點。 當用戶訪問嵌入 1x1 像素的網頁時，用戶數據將與跟蹤鏈接共享，從而允許用戶在同一站點和跨站點進行跟蹤。 基于圖像的跟蹤像素主要用于分析、廣告（再）定位和轉化跟蹤。 研究人員進行了各種大規模測量，以研究基于圖像的跟蹤像素[34,28,26,35,36,37].

?

多年來，跟蹤像素的功能有了顯著提高。 現代跟蹤像素（也稱為跟蹤標簽）依靠 JavaScript 在瀏覽器中收集更精細的信息。圖 4?顯示了一個簡單的場景，其中?tracker.com?的跟蹤像素嵌入到?news.com?的主頁和?/signup?頁面上，分別在其跟蹤腳本的幫助下，與自己的服務器收集和共享按鈕點擊和表單事件。 因此，跟蹤像素的范圍已經擴大到支持其他用例，例如通過單個標簽管理多個像素、機器人檢測和重放用戶會話。

由于大多數瀏覽器要么阻止[38]或對有狀態 API 的第三方訪問（按源）進行分區[39]，跟蹤鏈接無法跨站點存儲和檢索標識符。 存儲分區充其量允許跟蹤單個站點上的用戶活動。 為了規避這些保護措施，跟蹤鏈接采用了本節中描述的基于第一方的機制。

當第三方跟蹤腳本嵌入到第一方執行上下文中時，這些腳本會以與第一方腳本相同的權限執行，從而允許它們讀取和寫入 JavaScript 可訪問的第一方存儲，就像它們是第一方腳本一樣?第一方 cookie 通常存儲通過瀏覽器指紋識別創建的唯一用戶標識符，以及通過導航跟蹤退回的用戶標識符（參見第 5.2.4 節）。 最近的研究已表明，近 90% 的網站至少使用一個跟蹤第一方 Cookie，其中 96% 實際上是由在第一方上下文中運行的第三方腳本設置的。

第一方 Cookie 的隱私問題之一是將這些標識符與其他第三方同步。 這種共享 — 首先由 Fouad 等人描述。[31]— 允許第三方相互串通，并在第一方環境中從用戶跨不同網站收集的信息中獲益。 在某些情況下，Google 和 Facebook 設置的第一方 Cookie 會與數百個其他第三方域共享[41,40].

阻止第三方 Cookie 會使嵌入為圖像元素的跟蹤像素無效。 但是，依賴 JavaScript 的現代跟蹤代碼仍可用于在第一方上下文中跟蹤用戶[41]. 這些標簽通常由開發人員包含在網站的主框架上下文中，允許像素跟蹤公司使用第一方執行權限監控不同的用戶活動。

共享標識符的一種流行機制是通過鏈接裝飾，如圖?5?所示。 最近的研究發現，超過 70% 的網站上用于共享用戶數據（例如第一方 Cookie 和電子郵件地址）的查詢參數、資源路徑和 URL 片段，在沒有第三方 Cookie 或第一方分區的情況下。 除了鏈接裝飾之外，退回跟蹤是另一種基于導航的機制，它允許跟蹤器跨站點讀/寫他們的 cookie，從而使第三方 cookie 阻止無效[44].

?

概括地說，跟蹤鏈接的目標是在瀏覽器的第一方上下文中暫時出現或訪問自己的域，因為這可以讀取和寫入保留在第一方存儲中的標識符。

圖6顯示了一個典型的反彈跟蹤序列：

??news.com?上的第三方腳本讀取存儲在?news.com 。

? 將它們包含在對?tracker.com?的請求中。

? 瀏覽器重定向到?tracker.com?- 通過用戶單擊或自動重定向（例如，window.location.href=“...”;或?<meta http-equiv=“refresh”>）。

? 作為第一方加載后，tracker.com?從 URL 中讀取標識符或將其與現有 Cookie 合并，將 URL 重寫到其最終目的地（例如，返回到?news.com?或其他域），嵌入整合的標識符。

? 瀏覽器導航到?news.com;跟蹤鏈接的腳本從修飾的 URL 中提取 identifier。

? 將其存儲在?news.com?的第一方存儲中，完成跨上下文鏈接（如果重定向到同一個第一方）或跨站點鏈接（如果重定向到不同的域）。

?

退回鏈可能涉及兩個網站（news.com→tracker.com→?news.com 或更長時間），允許跟蹤鏈接在多個看似不相關的網站之間傳播穩定的用戶標識符，盡管有第三方 cookie 限制。

由于潛在的可用性中斷和防御措施的實施，退回跟蹤并未廣泛普及?2020 年的測量發現，11.6% 的網站使用前 100 個重定向器之一，2022 年，此類標識符存在于 8.1% 的抓取導航中。

鑒于狀態跟蹤的廣泛采用及其感知的侵入性，研究界提出了許多跟蹤對策，其中一些措施已被瀏覽器采用或通過瀏覽器擴展提供給用戶。

從邏輯上講，用戶可以在每次會話結束時清除瀏覽器中的 cookie，以保護自己不被跟蹤。 但是，瀏覽器 Cookie 清除功能通常不會清除提供給網站的所有狀態機制. 例如，清除 Cookie 通常不會刪除存儲在瀏覽器存儲 API?localStorage 中的標識符、IndexedDB?、電子標簽和瀏覽器緩存[50]惡意跟蹤器可以通過將其跟蹤標識符的副本存儲在瀏覽器未清除的位置來利用此限制。 一旦用戶清除了他們的 cookie，跟蹤器就可以使用這些隱藏的信息來 “重新生成” 或重建用戶的標識符，從而創建所謂的 “supercookie” 或 “evercookie”. 最廣為人知的 supercookie 示例是 Adobe 的 Flash 瀏覽器插件，它沒有為瀏覽器提供清除其存儲的機制[51,19]. 任何允許跟蹤鏈接將狀態持久化到用戶設備的 API 都是潛在的 supercookie 向量[53]. 如果跟蹤鏈接能夠將對 API 的多個調用串在一起，每個調用對標識符中的另一個位進行編碼，那么即使只有一個 bit 存儲也可能被濫用。 Samy Kamkar 首先通過在 HTTP 嚴格傳輸安全 （HSTS）、Web 緩存、window.name?和 Web 歷史記錄等 API 中對標識符進行編碼，展示了這種風險的廣泛性[54]. 稍后在其他瀏覽器 API 上也演示了相同攻擊的變體[55,56,57]. 最終，超級 cookie 風險是 Firefox、Chrome 和 Safari 進行網絡和存儲分區工作的主要動機[58,59,60]. 截至 2025 年，大多數瀏覽器已經阻止或分區了第三方對有狀態 API 的訪問，從而阻止了這些 API 用于跨網站跟蹤用戶。

瀏覽器供應商嘗試阻止大多數第三方 Cookie[39]但保留一些例外情況以支持非跟蹤用例，例如啟用單點登錄 （SSO） 的 Cookie，刪除單點登錄可能會導致網站損壞[61]. 注重隱私的瀏覽器，例如 Brave[62]，通過默認阻止所有第三方 Cookie 并允許第三方在瀏覽會話的生命周期內共享分區的臨時存儲，來應用最激進的限制[63]. 在主流瀏覽器中，Safari[64]和 Firefox[65]具有最有效的限制。 Safari 當前會阻止所有第三方 Cookie，除非用戶已作為第一方訪問了域 （eTLD+1），或者第三方通過 Storage Access API 明確請求使用 Cookie[38]. 如果用戶在過去 30 天內沒有作為第一方與域交互，它還依賴于 ML 模型來檢測具有第三方訪問權限的域是否參與跟蹤并限制其 Cookie。 Firefox 阻止來自已知跟蹤器的第三方 Cookie（由 Disconnect 的跟蹤保護列表確定[66]） 并對第三方 Cookie 進行分區，以便每個第一方和第三方源組合都有一個單獨的 Cookie jar[39]. 最初，追隨 Safari 和 Firefox 的腳步，Google Chrome[67]宣布計劃阻止所有第三方 Cookie[68]，經過幾次拖延，它決定不繼續進行[9]. Chrome 目前為開發者提供了各種工具來管理第三方 Cookie，包括 Storage Access API 等 JavaScript API[69]以及 Cookie 指令（如 “SameSite” 屬性）[70]. 但是，跟蹤鏈接可能不遵守或使用這些機制。 此外，他們已經通過規避現有的保護措施遷移到替代跟蹤技術。

????????瀏覽器（例如?Brave）和瀏覽器擴展（例如?uBlock Origin）廣泛使用過濾器列表來阻止第三方跟蹤請求。 但是，基于篩選條件列表的廣告或跟蹤鏈接攔截面臨重大限制：

（1） 手動策劃的列表由小型社區個人維護，不會捕獲細微的技術。

（2） 隨著列表大小的增加，它們包含過時或太窄的條目（例如，90% 的 EasyList 規則實際上從未觸發）).

（3） 由于是靜態的，跟蹤器一直在逃避它們。

為了克服這些挑戰，研究人員專注于構建 ML 驅動的廣告或跟蹤請求攔截器. AutoFR提出了一個完全自動化的框架來創建和評估篩選規則。 雖然 AdGraph、WebGraph和 WTAGraph[74]將網頁視為 HTML 結構、網絡請求和網頁的 JavaScript 行為圖，以訓練分類器來識別并隨后阻止廣告和跟蹤資源。 這些方法可以很好地泛化以發現以前未知的跟蹤器并適應不斷變化的跟蹤行為。 Brave 實施了基于 AdGraph 的 ML 解決方案 （PageGraph） 來檢測和阻止跟蹤器。 除了網絡請求之外，另一種流行的反跟蹤方法是檢測和阻止不同粒度的跟蹤腳本或 JavaScript 代碼，例如基于域或路徑的腳本阻止或在其他良性腳本中阻止函數對抗性跟蹤器被激勵來逃避此類阻止（例如，通過更改腳本位置或導致網站中斷），這帶來了挑戰。

與第三方 Cookie 不同，第一方 Cookie 不能輕易被完全阻止，因為它會破壞關鍵網站功能，例如保持登錄狀態。 因此，他們需要更有針對性的對策，如下所示。

Safari 的智能跟蹤保護 （ITP） 將使所有第一方 Cookie 或腳本設置的存儲過期，在 7 天內沒有用戶交互[38]. 為了減少使用 HTTP Cookie 自動覆蓋腳本編寫的 Cookie 的解決方法，Safari 使用應用于第一方主機的 CNAME 和 IP 地址的啟發式方法檢測隱藏在第一方子域下的第三方主機[38]. Brave 實現了一個有限版本，它將腳本設置的 cookie 的生命周期限制為 7 天[86].

一些瀏覽器會刪除跟蹤鏈接已知的 URL 參數。 火狐瀏覽器[87]在非默認模式下實現刪除，而 Brave[88]和 DuckDuckGo[89]默認發貨。 在導航中刪除 URL 參數后，嵌入在第一方上下文中的跟蹤腳本將無法跨站點訪問跟蹤 ID。 Safari 采用不同的方法：當 ITP 檢測到鏈接修飾時，它不會刪除跟蹤參數，而是將腳本可訪問存儲的生命周期從 7 天限制為 24 小時[38].

Bounce Tracking 不僅繞過了第三方存儲保護，還允許不受限制地訪問 tracker 的第一方存儲。 瀏覽器通過區分對網站的合法訪問和用于跟蹤目的的短暫退回來緩解它。 某些身份驗證流看起來與退回跟蹤相似的事實使它變得復雜[44]. Brave 和 Firefox 使用阻止列表來檢測潛在的退回跟蹤器，而 Safari 和 Chrome 使用基于網站行為的啟發式方法作為緩解措施[90]. Firefox、Chrome 和 Safari 會刪除這些域的所有站點存儲空間，除非有證據表明用戶與站點的交互是合法的，并且是最近的用戶;合法和最近的定義因瀏覽器而異[90,38]. 雖然 Brave 為可疑的退回跟蹤鏈接提供對短暫存儲的訪問權限，只要跟蹤鏈接尚未設置持久存儲，該跟蹤鏈接就會在關閉所有打開的標簽頁后被清除[91].

隱私增強擴展支持通過過濾器列表有針對性地刪除已知的跟蹤 Cookie，包括第一方 Cookie[92,93,94]. 雖然過濾器列表面臨上述挑戰，但它們也可以使用基于 ML 的方法自動管理[41,95,96].

瀏覽器（或設備）指紋識別是一種用于收集用戶瀏覽器和設備信息的技術。 通過使用 HTTP 標頭和調用特定的 JavaScript API 端點，網站可以收集有關瀏覽器及其配置（例如瀏覽器版本、屏幕大小、已安裝的字體列表、GPU 型號、時區和首選語言）到底層作系統和硬件的廣泛信息。 研究表明，互聯網連接設備的多樣性如此之大，以至于收集的屬性組合可能是唯一的，從而導致特定設備的識別[97,98,99].圖 7?描述了指紋識別的工作原理。 對所有屬性的真實指紋和熵計算的分析表明，某些屬性對用戶唯一性的貢獻比其他屬性大得多。 熵[100]測量數據集中的不確定性或不可預測性級別，以了解其分布的差異程度。 例如，如果設備的屏幕大小可以有 8 個不同的值，則其熵為 3 位。 與第 5 節中描述的技術不同，指紋識別： 1） 不依賴瀏覽器中的存儲狀態（即?ID）來跟蹤用戶，因為指紋收集是實時執行的以識別設備; 2） 難以檢測和阻止; 3） 也很難逃避，因為用戶會保留同一設備數月或數年，從而隨著時間的推移產生穩定的指紋。

?

自 2009 年首次開展瀏覽器指紋識別學術工作以來[101]，研究人員研究了：它對隱私的影響[97]，與其他跟蹤技術一起使用[52]，則其檢測[102,103]、在實際應用中使用[104,105]、可濫用的瀏覽器 API[106,107,108]和用戶保護[109]. 2013 年，僅在～前 10K 個網站的 1%[110]和～前 100 萬個網站中的 400 個[49]. 多年來，已經使用了各種技術來測量瀏覽器指紋識別[27,28,111,112]，兩個總體趨勢是：它被第三方更多地采用，以及多年來擴展到各種瀏覽器 API。 到 2021 年，發現前 100K 網站中有 10% 存在指紋識別腳本，其中更受歡迎的網站發生率更高（即前 1,000 個網站的 30%）[102]. 重要的是，瀏覽器指紋并不總是足夠穩定，無法隨著時間的推移跟蹤用戶：80% 的瀏覽器實例在不到 10 天的時間內更改了指紋[113]. 跟蹤器不僅在指紋發展過程中鏈接指紋，而且還將它們與有狀態技術相結合和持久化，即使在對有狀態 API 的第三方訪問進行分區的瀏覽器中也能有效（第 5.3 節）。 2022 年的一項研究通過在前 30K 站點中的 1,150 個站點上檢測到它來顯示此的下限[52]. 最近的其他研究表明，指紋識別風險因人口統計數據而異[114]并且限制指紋中包含的信息不會破壞用戶體驗[115].

除了瀏覽器指紋識別技術外，研究人員還展示了許多跟蹤用戶的側信道方法。 其中一種方法是擴展指紋識別，旨在推斷用戶瀏覽器中是否存在特定擴展[116]. 早期研究[117,118,116]演示了擴展如何包含可被網頁引用的特定資源（例如，圖像、腳本），從而揭示它們在用戶瀏覽器中的存在。 研究人員還探索了行為擴展指紋識別[119,116,120,121,122,123]（其中可以通過執行副作用隱式推斷擴展）和相應的緩解措施[124,125]例如隨機化 WAR、ID 或類[126]和基于訪問控制的擴展加載[127].

除了擴展指紋識別外，之前的工作還探索了各種瀏覽器支持的 JavaScript API 進行指紋識別，例如 Canvas[128]、 WebGL[129]、音頻 API[28]和電池狀態 API[130]. Sanchez-Rola 等人進一步演示了如何通過分析指令序列的執行時間來使用 JavaScript API 來構建硬件指紋[131]，而其他公司則演示了針對設備 CPU 的基于瀏覽器的指紋識別技術[132,133]或 GPU[134]. 最近的研究還從瀏覽器的角度證明了基于 DRAM 的設備指紋識別功能[135]. 在移動生態系統中，與硬件相關的指紋也得到了廣泛的探索[136,137,138,139,140,141]，由于額外的傳感器（例如陀螺儀、磁力計）的可用性，這些傳感器可能會表現出制造過程中出現的獨特硬件“缺陷”。 更廣泛地說，任何提取某種形式的數據或影響客戶端策略或行為而不存儲用戶特定標識符的瀏覽器機制，都應該被視為潛在的無狀態跟蹤向量并進行相應的分析[53]. 通常，側信道攻擊很難檢測，也可能同樣難以緩解。

從建設性的角度來看，指紋識別可以被視為入侵檢測的一種形式。 Web 應用程序可以了解其第一方用戶的瀏覽環境，并將其與特定的用戶身份相關聯[142]. 例如，網站可以了解到用戶 Alice 正在使用具有特定尺寸的智能手機或具有特定類型 GPU 的桌面瀏覽器。 如果 Alice 的憑據被盜，并且攻擊者試圖登錄該服務，該服務可以提取攻擊者的指紋，觀察到 Alice 的指紋與之前會話的主要差異，并請求攻擊者提供其他身份驗證數據（例如一次性密碼）。 可以建設性地使用相同的技術來區分真實用戶與惡意機器人，以及從事廣告欺詐的攻擊者。

破壞性地，可以識別用戶冒充攻擊者和機器人的相同技術可以用于對付希望保持身份匿名的用戶。 使用指紋識別，Web 應用程序可能能夠確定某個匿名用戶實際上是同名的，因為他們的瀏覽器指紋與同一平臺上已知用戶的指紋相匹配。 盡管用戶試圖通過刪除其 cookie 或使用瀏覽器的隱私模式來隱藏，但這種不希望的重新識別還是發生了。 在跨站點上下文中，即使禁用了第三方 Cookie，也可以濫用指紋識別將不相關的網站訪問鏈接在一起。

瀏覽器供應商將指紋識別視為一種對 Web 有害的隱蔽跟蹤形式[143]. 所有主流瀏覽器都部署了一些針對指紋識別的緩解措施，W3C 鼓勵規范作者考慮他們的 API 如何為瀏覽器的指紋識別表面做出貢獻[144]. 盡管如此，主要瀏覽器繼續公開大量可用于指紋識別用戶的信息。 沒有針對指紋識別的最佳策略，因為它通常以犧牲用戶的效用為代價。 供應商之間在完全緩解指紋識別的可行性以及在沒有明確路徑完成緩解的情況下部署增量改進的價值存在分歧[145,146].

緩解指紋識別的最常用方法是將瀏覽器公開的設備信息正常化，以減少指紋的實用性。 Tor 等瀏覽器使所有用戶看起來具有相同的指紋，因此很難區分他們[147]. 而其他方法則引入了隨機性，因此單個用戶的指紋在頁面加載過程中不斷變化，從而使用戶跟蹤復雜化。 后一種對策更容易在用戶群體中部署，因此比旨在使所有環境看起來相同的對策更受歡迎。 瀏覽器供應商減少了已發送到 Web 的 API 所暴露的身份信息，刪除了已知被濫用于指紋識別的 Web API，并拒絕實施暴露其他指紋識別表面的新 API。 示例包括：從 User-Agent 字符串中凍結次要瀏覽器版本[148]，由于可識別指紋而取消交付電池狀態 API[111]，以及 WebKit 和 Firefox 拒絕實施網絡信息 API，部分原因是出于指紋識別問題.

Web API 規范化有時會破壞希望能夠訪問設備信息的網站。 對于無法規范化的 Web API，瀏覽器已將特定于站點的隨機噪聲添加到這些 API 的輸出中，例如，添加到 2D 畫布的柵格化輸出中的噪聲、WebGL 渲染以及 WebAudio API 中的?AudioBuffer?樣本。 隨機化最初由 Brave 以“farbling”的名義部署[150]，后來被 Firefox 采用[151]和 Safari 瀏覽器[152].至關重要的是，仍然可以采用替代指紋識別技術[153].

除了更改單個 API 輸出外，瀏覽器還探索了基于策略的方法，以阻止指紋識別。 Mozilla 發布了一項禁止瀏覽器指紋識別的反跟蹤政策[154]隨后，當檢測到腳本包含瀏覽器指紋代碼時，阻止腳本在 Firefox 中加載[155]. Google Chrome 工程師提出了一項針對網站的隱私預算，允許網站訪問可指紋設備信息，但不得超過瀏覽器定義的預算[156]. 一旦超出該預算，瀏覽器將限制身份信息的進一步暴露。 這種方法受到了懷疑，因為網站可能會損壞，并且可能會暴露額外的跟蹤表面[145,146]，導致其停產[157]. 因此，過去十年缺乏解決指紋識別問題的統一努力表明，截至目前，科技界并無完全消除指紋識別的意愿。

跨設備跟蹤可以是確定性的或概率性的?[158,159,160].傳統上，用戶的帳戶信息（例如用戶名或電子郵件地址）用于鏈接或關聯跨設備的瀏覽活動。當這些確定性標識符失敗時，例如，如果用戶已注銷，則會使用概率信號，例如 （a） 屬于同一用戶的多個設備共享的 IP 地址[161]，（b） URL 瀏覽模式，因為人們傾向于跨設備訪問相同的網站和應用程序[162]，（c）作系統和硬件特性[129]或 （d） 鍵入行為[163].跟蹤鏈接將這些功能組合成跨設備圖表?[164,165].

局限性。然而，概率技術并不總是提供可靠的標識符（例如，ISP 在多個家庭之間動態輪換和共享公共 IP 地址）。因此，跟蹤器采用專有算法來消除噪音，例如忽略跨設備圖計算中的商業、私有和代理 IP 范圍，或為觀察到的標識符設置精細的時間閾值，以被視為來自同一用戶。

調節。為了讓廣告行業了解跨設備跟蹤的隱私侵略性質，FTC 于 2015 年舉辦了一次跨設備跟蹤研討會[166].它還向集成 Silverpush 的廣告網絡 Silverpush 的開發人員發出了警告信，Silverpush 是一個通過聽不見的超聲波信號執行跨設備跟蹤的廣告網絡[167].各種后續研究[168,169,133]強調了這種技術的侵入性。

防御跨設備跟蹤。確定性的跨設備跟蹤保護本質上受到用戶從不同設備登錄的帳戶的限制。另一方面，概率跨設備保護原則上與傳統跟蹤相同，例如，限制披露可用于關聯用戶的用戶數據。 在移動設備上，引入了攔截、檢查和阻止來自應用程序的傳出數據包的技術[170].關于使用聽不見的超聲波信號，人們努力推動了信標和作系統級 API 的標準化，以更好地控制對功能的訪問并有選擇地抑制某些頻率.

使用檢測瀏覽器進行 Web 爬蟲是衡量在線跟蹤的最常用方法。 瀏覽器插樁可以采用兩種形式：帶外或帶內。帶外或深度檢測直接修改瀏覽器或 JavaScript 引擎。相比之下，帶內在 JavaScript 級別利用插樁鉤子（如原型修補）來覆蓋感興趣的功能。

用戶代理。大多數測量都需要支持現代 Web 功能的瀏覽器。 不執行 JavaScript 或對 Web API 的支持不完整的簡化用戶代理可能適合進行有針對性的測量[71].

帶有 Instrumentation Hook 的自動化框架。為了驅動完整的消費者瀏覽器，研究人員依賴于為網站和瀏覽器測試而構建的自動化工具：例如，用于基于 Blink 的瀏覽器的 Chrome DevTools 協議 （CDP） 和用于基于 Gecko 的瀏覽器的 Marionette。這些內部接口由 Selenium 或 Puppeteer 等跨瀏覽器自動化庫使用[172,173,174]. 許多研究人員直接使用這些庫，同時也存在一些將完全瀏覽器自動化與其他儀器和測量工具捆綁在一起的項目[28,175,176,177,178].

深度檢測。在利用深度檢測進行與安全相關的 Web 測量方面，已經進行了許多嘗試[179,180,49,181,182].根本問題是瀏覽器發展迅速，使研究原型很快過時，因為維護補丁很困難或不可能[182]. 有兩項主要努力試圖克服這個限制：VisibleV8[183]和 PageGraph[184,185]. PageGraph 由 Brave 瀏覽器團隊直接維護，使其成為唯一支持瀏覽器的深度檢測框架。 VisibleV8 的設計使其補丁最少（用于實際 JavaScript 監控的 67 行代碼），并且已經成功地以最小的工作量提供了從 Chromium 63 到 137（提交時的版本）的構建[186,183].一個主要的好處是，深度檢測與需要監控的內容無關：所有?Web API 都可以掛接，即使事先不知道負責的 API[107].

隱蔽性。對主動 Web 測量有效性的一個重大威脅是網站檢測爬蟲和檢測瀏覽器的能力。檢測到后，網站可能會阻止爬蟲或更改其行為（這種做法稱為偽裝真實內容)?[187].自動化框架通常會在 JavaScript 上下文中注入可檢測的工件或更改用戶代理字符串。研究人員可能需要部署進一步的規避技術[188]以避免差別治療。

站點列表。熱門網站的頂級列表由多個來源根據不同的方法發布：Alexa Top Million[189]（現已棄用），Cisco Umbrella 人氣列表[190]、Majestic Million[191]、Tranco[192]、Google CrUX[193]或 Cloudflare Radar[194]. 過去，它們用作研究網站和真實用戶行為的代理引起了一些懷疑，因為這些列表可能不穩定、不一致且容易縱。此外，選擇排名靠前的列表有時會影響研究結果[192,195].

現有爬網數據集。另一種策略是利用現有的 Web 爬蟲數據集。非營利組織和社區驅動的項目，例如 Internet Archive[196]、常見爬網[197]和 HTTP 存檔[198]定期抓取網站并公開發布其數據。

局限性。代表性和泛化性問題是由于 機器人檢測措施[199], 測量有利位置[200], 設備外形規格[201,202]以及從爬取與人類真實瀏覽中獲得的結果的潛在差異[203].直接相關的是，研究通常很難復制和復制，因為研究人員并不總是完全記錄方法和實驗設置的差異[204,205].

在實踐中，用戶研究可以采取多種形式;它們可以通過可用性調查或訪談進行，也可以基于通過現場測量、眾包或通過瀏覽器擴展或應用程序直接收集從真實用戶那里收集的數據。例如，國家互聯網觀察站[206,207,208,209]是一項新興項目，旨在邀請美國居民自愿提供有關其在線行為的數據，并允許研究人員進行科學研究，以保護隱私。 通過這些技術，研究人員主要研究了參與者對 cookie 對話框的理解、感知和互動[210,211,212,213,214,215,216].他們通常會研究和比較不同的同意對話框設計，發現許多當前的設計有效地推動了參與者選擇更多隱私保護選項[211,212].這些研究還建議默認拒絕同意選項，并且用戶應該能夠輕松地重新訪問他們所做的選擇[213,217].

?

美國的監管行動。在美國，各州頒布了自己的隱私立法，聯邦層面只有少數狹義的隱私法，特別是針對兒童個人數據 （COPPA） 的法律[218]、 受保護健康 （HIPAA）[219]和個人財務（《格雷姆-里奇-比利雷法案》）[220]信息。因此，除了強制性規定外，通知和選擇原則（通常通過隱私政策實施）還規定了個人信息接收者可以如何處理這些信息[221]. 研究調查了這一原則[222]并表明它缺乏監管執行[223]、通知的模糊性和歧義[224]、不可用的 choice 實現[225]以及 nudging 和 inconvenience 因素[226].

根據《美國法典》第 15 卷第 45（a）（1） 條的規定，在其管轄范圍內，FTC 可以將歪曲企業數據處理做法的隱私政策視為不公平或欺騙性，從而影響商業[227]，并且過去已經這樣做了[228,229].通過過去幾十年的此類執法行動，FTC 實際上已經建立了一套普通隱私法體系[230]. 同樣，各州總檢察長也根據新的州隱私法增加了監管活動：加利福尼亞州于 2020 年和 2023 年通過了 CCPA，其他州很快也紛紛效仿，如圖?8?所示。 美國（和其他地方）隱私法的系統化和執行正在取得進展，盡管最近通過 CPRA 對 CCPA 的更改可能會對選擇退出銷售權的可用性、范圍和可見性產生負面影響[231].

歐盟的監管行動。幾個歐盟國家在 1970 年代后期制定了第一部數據保護法[232,233,234]，隨后是 1995 年的歐盟數據保護指令[235]以及 2018 年適用于所有歐盟成員國的 GDPR[236]. 從歐盟向美國的個人數據傳輸目前受歐盟-美國數據隱私框架 （EU-US Data Privacy Framework） 的監管[237]取代了之前失效的框架[238,239,240,241]. 《電子隱私指令》（2002 年，于 2009 年修訂）在其第 5 條第 （3） 款中要求在“在終端設備中存儲信息或訪問已存儲的信息”之前獲得用戶的有效同意?[242,243].GDPR 通過設定更高級別的法律要求重新定義了這一概念[244].由于將《電子隱私指令》更新為法規的努力迄今尚未達成共識[245]，歐盟監管機構不斷更新其國家法律和合規指南，以進一步解釋和實施《電子隱私指令》[216].

因此，《電子隱私指令》第 5（3） 條以不同的方式解釋為 （a） 在設置、讀取或向第三方發送 Cookie 之前需要獲得同意，（b） 確定如果所有跟蹤技術的使用是“絕對必要的”（例如，為了負載平衡）或“啟用通信”所必需的，則不需要同意所有跟蹤技術，以及 （c） 涵蓋各種類型的設備（例如移動和物聯網）和技術（跟蹤像素、 鏈接裝飾）[246]. 歐盟監管機構也一直在積極調查跟蹤技術、同意和不當行為。在 Planet49 案中，歐盟最高法院 （CJEU） 通過宣布同意設計界面中的預先勾選的框非法，確立了法律先例[247].同樣，法國數據保護局發現，同意橫幅必須在第一層提供拒絕選項[248,249]，公司因在同意之前設置 cookie 而被罰款[250,251]（有關更多決策，請參閱 GDPRhub[252]).

近年來，歐盟委員會試圖建立更簡單的同意規則[253]和歐盟法律，例如《數字市場法》[254]和數字服務法案[255]分別為大公司（定義為“守門人”）和在線平臺上的黑暗模式和廣告制定了額外規則。

以策略為導向的解決方案。我們多次嘗試實施選擇退出和同意信號，以便用戶將其隱私偏好傳達給服務。但是，發件人和收件人對此類信號的采用和強制實施是一個尚未解決的協調問題[256].

隱私偏好平臺 （P3P）?[257,258,259]使網站能夠以標準化和精細的格式向用戶傳達其隱私慣例。盡管如此，由于采用它的網站數量較少，它的實用性受到了限制[260]以及正確和透明地實施它的人[261,262].

請勿跟蹤 （DNT）?[263]，作為 2009 年開發的二進制選擇退出信號，其采用率也保持在較低水平。事實上，影響 DNT 設計的 COPPA 只要求在線服務說明他們是否尊重它[264].

全球隱私控制 （GPC）?[265]可以被視為 DNT 的繼任者。雖然人們發現 GPC 有用且可用，但采用速度很慢[266,267]，盡管加利福尼亞州要求遵守 GPC（2021 年）[268,269]和科羅拉多州 （2024）[270].GPC 是否可以在 ePrivacy 和 GDPR 背景下適用于歐盟，仍然是一個公開的討論[271].

面向策略的協議和框架仍處于早期階段，《數據權利議定書》就證明了這一點[272]和行業同意框架[273].

近一半的訪問量最大的網站已經在使用第一方跟蹤 cookie。我們預計，隨著第三方跟蹤限制、內容攔截工具和分區的進一步采用，這一趨勢將繼續下去。 Cookie 分區是一種根據 Cookie 設置的上下文對 Cookie 進行孤立或“分區”的方法，有效地限制了基于瀏覽器的存儲與每個訪問的站點保持緊密聯系，從而更難在不同站點之間鏈接用戶身份和行為。 盡管如此，最好將分區視為需要更廣泛的隱私措施的一個步驟：跟蹤器仍然可以使用嵌入在單個域上的指紋和第一方腳本。

隨著對第三方 cookie 的限制，網站現在依賴于少數主要身份提供商（例如，Google/YouTube、Facebook/Meta、Apple），這些提供商通過其看門人的地位，可以對用戶進行身份驗證，同時悄悄地附加持久的、特定于服務的標識符。 許多平臺進一步將此流與內部“第一方”和離線數據（如忠誠度卡和銷售點數據）融合在一起，構建專有的身份圖，將單個用戶（或家庭）映射到多個瀏覽器、應用程序和物理交易。 雖然這些集成有助于出版商在更嚴格的瀏覽器策略下衡量轉化率和個性化內容，但它們也將行為洞察集中在少數主導參與者身上，并削弱了用戶維護獨立或假名角色的能力，從而引發了新的反壟斷和隱私挑戰

會話重播（或錄制）腳本捕獲詳細的用戶交互，例如擊鍵、鼠標和滾動移動，以及訪問頁面的完整內容。 這允許出版商記錄和回放訪問，就像他們 “越過 [訪客] 的肩膀” 一樣，用于營銷、分析和故障排除等目的[277]. 但是，這些腳本也可以捕獲訪客填寫的敏感個人數據[278,279,280]，而 Session Replay 供應商提供的修訂措施通常很脆弱且效果有限[281,278].

避免廣告攔截器施加的限制[282]中，某些網站使用付費專區或注冊墻，這些付費專區或注冊墻在授予內容訪問權限之前需要用戶身份驗證（通常是付款信息）。 這種策略可能會降低用戶阻止 cookie 或私下瀏覽的動機，它還要求用戶保持“可識別”，為網站運營商提供一個可靠的標識符，該標識符在會話中持續存在，并且比第三方 cookie 更強大。 雖然付費墻可能支持合法的收入模式——特別是對于面臨廣告收入下降的出版商——但它們也創造了一個以匿名換取訪問的環境。 因此，如果付費墻變得更加普遍，注重隱私的用戶可能很難避免在線共享他們的個人數據。

為了規避廣告攔截技術，跟蹤鏈接已將其部分跟蹤邏輯從客戶端轉移到服務器端[283]. Google、Meta、Amazon 或 TikTok 等公司已經部署了所謂的轉化 API，這些 API 與數據凈室一起，允許營銷人員以保護隱私的方式對自己的數據與這些圍墻花園內的數據進行聯合分析。 但是，服務器端跟蹤很難審計，因為客戶端機制無法檢測到 API 和信號[284]然而，對 Meta 轉化 API 的分析發現，它與客戶端跟蹤相當，盡管在共享最少數據時會出現更多的錯誤匹配[285].

先前對指紋多樣性的研究是在各種大小的數據集上進行的;470 千米[97]、118K[98]、2.07 米[99]、7.2 米[286]和 1.5B[105]指紋。因此，結論各不相同，較小的數據集具有更多全局唯一指紋，而最大的數據集則按比例呈現特定收集屬性的更多唯一值。因此，目前尚不清楚這些關于指紋識別有效性的發現是否適用于不同的受眾和設備類型[114].最近的一項工作還表明，自動爬蟲無法準確捕獲指紋[287].此外，如果現有工作解釋了如何利用指紋識別進行跟蹤和提高安全性，那么實際目的和實時系統中的集成就不是很清楚了。

指紋識別的一個主要挑戰是，網站可以將相同的技術用于非常不同的目的;（重新）識別 Web 上的用戶，允許跨站點跟蹤和定向廣告，但還可以區分機器人和嘗試對帳戶進行身份驗證的人類訪問者。這種使用的雙重性阻礙了僅允許出于“良性”目的進行指紋識別的嘗試，即確保安全，同時保護用戶的隱私。

隨著對客戶端標識符的限制越來越多，跟蹤鏈接越來越多地轉向硬件級屬性來（重新）識別用戶，而無需依賴持久性 Cookie 或本地存儲。 與傳統的瀏覽器屬性（例如，User-Agent、語言設置或安裝的字體）不同，面向硬件的指紋（例如，來自制造過程中 CPU 和 RAM 缺陷的信號）更難被用戶欺騙或重置，因為它們利用了設備組件的內在屬性[135]. 硬件指紋識別允許跟蹤器保持跨會話和跨站點跟蹤功能，從而可能繞過現有瀏覽器的隱私措施和用戶的規避策略，以阻止或分區有狀態標識符。

瀏覽器指紋識別在很大程度上是由瀏覽器共享的信息實現的，以改善用戶體驗。雖然這在 1990 年代是必要的，但因為瀏覽器的功能和呈現相同的 HTML 文檔的方式不同，而現在瀏覽器都嚴格遵守同一套標準，并且呈現在設備和平臺上是一致的。因此，人們可以思考傳遞此類信息是否仍然相關，以及刪除它是否會有效地結束瀏覽器指紋識別。 主要挑戰是了解此刪除對 Web 的確切影響。在客戶端，User-Agent 似乎可以在網站損壞最少的情況下停用[115]，但目前尚不清楚此結論是否擴展到其他屬性，或者是否需要對瀏覽器進行特定的更改。在服務器端，當 Google 發起凍結 User-Agent 的計劃時[148]，人們擔心反欺詐和程序化廣告系統的負面影響。

HTTP Archive 等工作[198]或 WebREC[205]，存檔爬網結果并公開共享其數據集，可能會提供一些技術解決方案，使 Web 測量在未來更易于訪問和可重現。 對于仍有待填補的技術測量差距，我們觀察到需要自動化框架來監控 Web API 更改并檢測瀏覽器中新出現的側信道指紋識別風險，以便及時緩解。此外，我們需要更好地了解不同跟蹤技術的目的和合法用途[288]- 在 CookieBlock 的模型上[95]將 Cookie 映射到其用途，以實現大規模的合規性測量。具體來說，這將需要將用于跟蹤的指紋識別技術與機器人檢測分開。

各種研究表明，許多網站的實際行為并不符合自己的隱私政策[289,290]，或者不尊重或未正確注冊用戶的同意

合規率如此之低的原因有多種。首先，網站發布者缺乏激勵或不了解不考慮隱私合規性——除非存在法律要求或相應的準則[297,298]- 集成可能使用深色模式的第三方時[299,300].其次，監管機構的執法權和具有法律約束力的決定，他們可能沒有所需的人力、財力和專門的技術部門[301]調查網站是否合規，而不僅僅是“表面”[302].此外，可用的隱私社區并不總是了解監管要求，也不總是研究對監管機構有意義的設計和 UI 暗模式[216]. 最后，第三方可以逃避法律責任，因為現行法律通常將主要合規義務放在網站所有者身上[303]盡管研究發現了第三方服務的默認配置存在問題[304,305].

雖然大多數現代瀏覽器都提供了跟蹤對策，但被動指紋識別（依賴于 IP 地址、HTTP 和 Accept 標頭、User-Agent 等）仍然是一種隱蔽的跟蹤機制. 為了遏制這種情況，瀏覽器供應商減少了 User-Agent 標頭中可用的信息同時，Chrome 開發人員引入了一個不帶分隔符的 JavaScript API[310,311]以及基于 HTTP 的選擇加入方法，用于公開現在默認隱去的功能[312].然而，研究表明，廣告和分析腳本通常會訪問和泄露這些高熵用戶代理詳細信息[115,313]. 2021 年，Apple 發布了 Private Relay，這是一項付費 iCloud 功能，可通過兩個中間服務器路由網絡流量[314].研究人員發現它容易受到流量關聯和網站指紋識別攻擊[315]. 作為 Privacy Sandbox 項目的一部分，Google 提出了一項名為 IP 保護的類似功能，但尚未實施，其中只有流向第三方來源的流量通過兩個躍點路由[316].

個性化廣告和用戶隱私之間的內在緊張關系激發了各種旨在平衡這些相互競爭的利益的學術提案[317,318,319].同樣，瀏覽器也經常難以協調跟蹤保護與廣告商的利益。Mozilla 在 2013 年嘗試默認阻止第三方 cookie 的嘗試遭到廣告商的強烈反對[320]，當 Apple 在 2017 年實施 Safari 的智能防跟蹤 （ITP） 時，這種反應得到了回應[321].谷歌隨后在 2019 年決定將跟蹤保護集成到 Chrome 中，明確承認需要維護廣告商支持[322,68]. 因此，瀏覽器越來越多地采用隱私保護廣告技術的策略。Mozilla 進行了試驗并展示了設備端個性化的可行性[323].Google 和 Apple 同樣通過支持廣告商的新 API 來補充他們的跟蹤保護。到 2024 年，所有主要瀏覽器供應商都將在 2021 年成立的 W3C 私人廣告技術社區組 （PATCG） 中積極為廣告 API 開發做出貢獻[324].這些 API 通常分為兩類：廣告衡量和廣告定位。 雖然這些提案承諾在不影響廣告主效用的情況下增強隱私性，但對 Google 的 FLoC（現已棄用）的評估[325,326,327]主題[328,329,330,331,332]、受保護的受眾 （FLEDGE）[333,334,335]、用戶代理 API[313,115]和 Apple 的 Private Click Measurement[336]揭示了重大的隱私限制。問題包括匿名保證不足、新的指紋識別向量、有缺陷的實現以及由于瀏覽器支持不一致而導致的潛在碎片化[276].

雖然我們的重點是 Web 跟蹤，但移動應用程序和 IoT 生態系統中也存在類似的跟蹤機制，通常使用通過作系統 API 而不是 Web API 提供的更豐富的傳感器信息。存在一些關鍵的區別和相似之處：網絡跟蹤依賴于 Cookie，而應用程序跟蹤可以訪問設備級標識符，例如廣告 ID（在 iOS 上稱為“IDFA”，在 Android 上稱為“AAID”，在三星智能電視上稱為“TIFA”），此外，供應商可能會在生態系統中做出不同的設計選擇。例如，雖然 Apple 的 Safari 默認阻止第三方 Cookie，但 iOS 會請求授予對設備級標識符的訪問權限。同時，Google 的 Chrome 和基于 Android 的作系統默認不會分別阻止第三方 Cookie 或設備級標識符。

已經部署了生成式 AI 模型來改進廣告定位[337]和上下文廣告[338]. 此外，雖然生成式 AI 部署在 Web 瀏覽器中[339]或作為瀏覽器助手[340]可能會啟用新功能，也可能放大危害（例如隱私風險）或創建新的攻擊面[341]. 瀏覽器在確保新型 AI 集成的安全性和隱私性方面發揮著關鍵作用。

在推出幾十年后，Web 跟蹤仍然是一個典型的貓捉老鼠游戲。 每一次增量防御（無論是新的瀏覽器策略還是監管裁決）都會迅速引發同樣復雜的規避技術來跟蹤用戶。 這種對抗性動態表明，純粹的反應性方法無法為在線用戶提供隱私保證。

僅靠法規是不夠的 – GDPR 和 CCPA 等數據保護法規加強了問責制，但這種執行速度落后于不斷發展的跟蹤機制的技術變化速度。 此外，跟蹤器經常會找到容忍的灰色區域來繞過法規。 因此，執法經常因管轄權或解釋爭議而停滯不前。 監管機構需要通過與測量界合作來整合敏捷、循證驅動的審計方法，以避免任何監督，并確保法規與技術現實相適應。

另一方面，雖然瀏覽器是強大的守門人，但它們提供的防線并不可靠。 默認保護措施因瀏覽器供應商而異，實驗性功能有時會在發現問題數年后推出，而商業激勵措施通常會導致更寬松的設計。 因此，未來的研究必須超越“在瀏覽器中修復”的補救措施，并探索真正保護用戶隱私的補充方法。

因此，雖然基于瀏覽器的保護和策略驅動的更改在一定程度上有效，但當前的跟蹤環境需要一個默認的隱私優先解決方案，用戶可以控制自己的隱私，而不是瀏覽器或監管機構。 本 SoK 通過總結多年來網絡跟蹤發展及其預防的重要發現并提出未來的關鍵方向來強調這一點。 我們希望幫助研究界了解需要關注的新穎和重要內容，以改善用戶的在線隱私狀況。