大家读完觉得有帮助记得及时关注和点赞！！！
抽象
网络跟踪是一种普遍且不透明的做法，可实现个性化广告、重新定位和转化跟踪。 随着时间的推移，它已经演变成一个复杂的侵入性生态系统，采用越来越复杂的技术来监控和分析整个 Web 上的用户。
研究社区在分析新的 Web 跟踪技术、设计和评估对策的有效性以及评估隐私法规的合规性方面有着悠久的记录。 尽管在网络跟踪方面进行了大量工作，但文献仍然分散在范围不同的研究中，因此很难确定总体趋势、连接新的相关技术以及确定该领域的研究差距。
如今，Web 跟踪正在经历一场千载难逢的变革，这是由广告行业的根本转变、浏览器采用反跟踪对策以及新兴隐私法规的日益执行所推动的。 这种知识系统化 （SoK） 旨在整合和综合这些广泛的研究，全面概述塑造现代和快速发展的 Web 跟踪领域的技术机制、对策和法规。 该 SoK 还强调了开放的挑战并概述了未来研究的方向，旨在为研究人员、从业者和政策制定者提供统一的参考和介绍材料。
1介绍
在线用户访问 Web 上的各种免费内容和服务，这些内容和服务主要通过在线广告获得资金。 反过来，广告严重依赖出于各种目的监控用户的在线活动 例如 Analytics、个性化（重新）定位和转化跟踪。 为了实现这些目标，用户跟踪已成为 Web 的普遍组成部分。 到 2025 年，仅美国的在线广告就将超过 4000 亿美元[1].
自 1990 年代中期在 Web 上引入 cookie 以来，Web 跟踪已演变成一种更加普遍和复杂的做法。 第三方跟踪器的普及率有所增加，目前约有 92% 的网页嵌入了至少一个跟踪器. 此外，用户跟踪和分析通常涉及收集用户的个人详细信息（例如姓名、电子邮件和位置）、设备特征（例如设备型号和作系统）、浏览历史记录和行为信号（例如在页面上花费的时间和执行的交互）。 因此，网络跟踪已成为在线隐私研究的一个活跃领域。
研究人员进行了大量研究，以检查 Web 跟踪机制、浏览器开发和法规遵从性的演变。 然而，尽管有如此大量的工作，主要发现仍然分散在许多不同的研究中。 此外，随着浏览器中隐私防御的改进，跟踪器不断适应新的规避技术. 结果是跟踪技术的技术格局不断变化。 跟踪做法通常由法规管理，并确保浏览器提供必要的保护以保护用户隐私。 尽管这些监管变化的影响比基于浏览器的技术干预更为缓慢，但它们共同继续重塑生态系统。 如今，由于在主要 Web 浏览器中引入了隐私增强保护措施和不断发展的监管框架，Web 跟踪正在发生变革性变化。 在线广告的最新进展包括引入隐私保护范式[5]以及在 Web 上采用生成式 AI. 鉴于这些变化，全面、系统地研究不断发展的跟踪环境中的新兴趋势以确定关键的研究差距是重要且及时的。 因此，研究界显然可以从整合和系统化知识状态的统一资源中受益，帮助研究人员为该领域做出有意义的贡献，并确保采用结构化的方法来解决新的隐私问题。
为此，在本 SoK 中，我们综合了 Web 跟踪的不同研究和实践------跨越技术机制、浏览器缓解以及监管变化------以系统地提供 Web 跟踪当前状态的概述。 我们将这项工作的范围限定为如何收集有关用户的数据，而不是如何使用这些数据。 这种统一的视角使我们能够批判性地反思社区已经走了多远，以及它在研究方向方面下一步应该走向何方。 我们的贡献如下：
*
我们系统地组织了关于网络跟踪的广泛研究，提供了该领域进展的综合知识库，突出不断发展的趋势，桥接新兴但相关的跟踪机制，并确定该领域的差距。
*
我们概述了欧盟和美国基于浏览器的主要反跟踪干预措施和相关监管框架，以评估它们多年来如何改变生态系统。
*
我们确定了网络跟踪领域的关键开放挑战和有希望的未来方向，供社区在未来几年内解决。
2方法论
在线跟踪拥有大量文献，包括过去几十年发表的大量研究。 因此，我们首先进行了一项文献调查，以确定过去 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，如本文其余部分所述。
3Web 作为生态系统的背景
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 在查询字符串或请求负载中与远程服务器共享。
4Web 跟踪的威胁模型
我们的 Web 跟踪威胁模型考虑了四个主要实体：用户、浏览器、第一方网站和网站中包含的第三方。 用户是通过浏览器（也称为用户代理）访问 Internet 上的网站的个人），寻求对他们的在线行为保密，因此被视为受害者。 浏览器协调用户与 Web 内容之间的所有交互，执行第 3 节中描述的不同策略。 第一方网站是用户直接访问以浏览内容的网页。 它通常包括来自第三方的资源，这些资源不会被用户直接访问，并且通常托管在与第一方网站不同的域上. 跟踪器是指其目标是收集有关用户活动的数据以监控或识别用户在网络上的行为的任何一方。 我们将第一方和第三方跟踪器视为对手，其目标是收集有关用户的最大信息。
图 1 提供了我们模型的概念性概述，其中 news.com 和 sports.com 是用户从其个人设备访问的第一方网站。
tracker1.com 和 tracker2.com 是嵌入在第一方网站中的第三方。
图 1：Web 跟踪的威胁模型
**对手的目标。**用户数据可分为两类：
（1） 标识符（如电子邮件）或识别信息（如网络、软件或硬件配置）。
（2） 浏览活动，包括用户访问的网页和执行的网站交互。
跟踪链接的目标可以分为不同的范围：
**同一站点。**该跟踪链接旨在监控或识别同一第一方网站上的多次访问或页面加载的回访用户。
**跨站点。**嵌入在多个不相关的第一方网站上的跟踪链接通常旨在唯一地识别和跟踪这些网站上的用户，以便将不同的网站活动链接到同一用户。
**跨设备。**跟踪链接还可能旨在识别使用不同设备或浏览器浏览互联网的同一用户。 总之，攻击者的主要目标是持久且唯一地标记用户或用户的浏览器/设备，并随着时间的推移跨导航、站点和时间收集与该标签相关的用户数据，用于分析、分析或广告定位等目的。
此外，跟踪器的第二个目标可能是避免检测或预防，即跟踪器尽管采取了反跟踪措施，但仍旨在实现其目标。
对手的能力。 为了实现其目标，可以在包含、收集、存储和共享用户数据的上下文中解释对手的能力，但要遵守第 3 节中讨论的浏览器的上下文来源限制。 攻击者被认为有足够的能力在存在这些浏览器强制执行的策略限制或绕过这些限制的情况下跟踪用户。
**包容性。**假定第一方跟踪链接直接监控大型机上下文中的用户活动。 第三方跟踪链接可以作为内联资源（例如，图像/脚本标签）嵌入到大型机上下文中，由第一方假设信任委派，在其源下具有单独上下文的 iframe（即，具有自己的 DOM、状态和资源），或者作为第三方 iframe 中的资源，与大型机上下文隔离。
**集合。**跟踪链接旨在通过执行 JavaScript 代码或读取浏览器存储，通过可用的浏览器功能收集用户数据。
**存储。**跟踪链接可以使用 localStorage、sessionStorage、indexedDB 和 cookie jar 在用户的浏览器中读取、写入或修改数据。 跟踪器可以在后续访问同一站点或不同站点时访问存储的数据。
**共享。**接下来，攻击者的目标是与自己的服务器或合作伙伴的跟踪服务器共享收集到的用户数据。 为此，跟踪链接可以通过以下四种方式之一发起包含用户数据的网络请求：（1） 作为请求 URL 查询参数，（2） 请求负载，（3） 请求标头，或 （4） 通过 HTTP Cookie。 方法 1-3 要求跟踪脚本明确包含用户数据，而与跟踪器域关联的 HTTP Cookie 会自动包含在对跟踪器服务器的所有请求中。 我们使用此威胁模型来了解不同的 Web 跟踪机制及其随时间的演变。
5状态跟踪
跟踪用户最直接的方法包括在他们的浏览器中存储唯一标识符，并在他们浏览不同的网站时检索或修改它，这是一个称为"状态跟踪"的过程。 浏览器提供了许多接口（例如 cookie），这些接口旨在将状态与用户的访问相关联。 浏览器还提供了许多接口，这些接口将信息存储为提供给网站的其他功能（例如，电子标签、HSTS 升级）的副作用，跟踪链接有时会滥用这些功能来编码唯一标识符。
5.1第三方状态跟踪
5.1.1饼干
Cookie --- 由 Netscape 的 Lou Montulli 于 1990 年代首次指定 --- 允许浏览器通过 HTTP（一种无状态协议）与 Web 服务器通信时保持状态[20]. 例如，网站可以通过 Cookie 将用户的身份验证令牌存储在浏览器中，然后随用户浏览器发出的每个请求一起呈现给 Web 服务器，从而允许网站验证用户的身份验证状态。 浏览器调解哪些资源和域能够访问特定 Cookie
图 2：基于 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 一直是网络跟踪的主要形式。
5.1.2Cookie 同步
少数网站中包含的第三方只能跟踪有限数量的网站上的用户[25,26]. 此外，根据 SOP 限制，网页上的第三方无法通过直接向其发起请求来与另一个第三方域共享其 cookie。 为了克服这些限制并交换在不同网站上收集的有关用户的信息，第三方公司依赖于 cookie 同步或 cookie 匹配[27,28,29,30,31,32]---最初由 Olejnik 等人描述。[33]也被 Roesner 等人命名为"引用跟踪"。[25].
图 3：Cookie 同步
此机制依赖于同步两个不同第三方已知的用户标识符，这些标识符通常存储在第三方 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 收集的有关此用户的信息。
5.1.3跟踪标签
传统上，跟踪像素（也称为不可见像素）过去是嵌入在网页上的基本 1x1 图像元素，它指向某个跟踪端点。 当用户访问嵌入 1x1 像素的网页时，用户数据将与跟踪链接共享，从而允许用户在同一站点和跨站点进行跟踪。 基于图像的跟踪像素主要用于分析、广告（再）定位和转化跟踪。 研究人员进行了各种大规模测量，以研究基于图像的跟踪像素[34,28,26,35,36,37].
图 4：跟踪脚本
多年来，跟踪像素的功能有了显著提高。 现代跟踪像素（也称为跟踪标签）依靠 JavaScript 在浏览器中收集更精细的信息。图 4 显示了一个简单的场景，其中 tracker.com 的跟踪像素嵌入到 news.com 的主页和 /signup 页面上，分别在其跟踪脚本的帮助下，与自己的服务器收集和共享按钮点击和表单事件。 因此，跟踪像素的范围已经扩大到支持其他用例，例如通过单个标签管理多个像素、机器人检测和重放用户会话。
5.2第一方状态跟踪
由于大多数浏览器要么阻止[38]或对有状态 API 的第三方访问（按源）进行分区[39]，跟踪链接无法跨站点存储和检索标识符。 存储分区充其量允许跟踪单个站点上的用户活动。 为了规避这些保护措施，跟踪链接采用了本节中描述的基于第一方的机制。
5.2.1饼干
当第三方跟踪脚本嵌入到第一方执行上下文中时，这些脚本会以与第一方脚本相同的权限执行，从而允许它们读取和写入 JavaScript 可访问的第一方存储，就像它们是第一方脚本一样 第一方 cookie 通常存储通过浏览器指纹识别创建的唯一用户标识符，以及通过导航跟踪退回的用户标识符（参见第 5.2.4 节）。 最近的研究已表明，近 90% 的网站至少使用一个跟踪第一方 Cookie，其中 96% 实际上是由在第一方上下文中运行的第三方脚本设置的。
5.2.2Cookie 同步
第一方 Cookie 的隐私问题之一是将这些标识符与其他第三方同步。 这种共享 --- 首先由 Fouad 等人描述。[31]--- 允许第三方相互串通，并在第一方环境中从用户跨不同网站收集的信息中获益。 在某些情况下，Google 和 Facebook 设置的第一方 Cookie 会与数百个其他第三方域共享[41,40].
5.2.3跟踪标签
阻止第三方 Cookie 会使嵌入为图像元素的跟踪像素无效。 但是，依赖 JavaScript 的现代跟踪代码仍可用于在第一方上下文中跟踪用户[41]. 这些标签通常由开发人员包含在网站的主框架上下文中，允许像素跟踪公司使用第一方执行权限监控不同的用户活动。
5.2.4导航跟踪
共享标识符的一种流行机制是通过链接装饰，如图 5 所示。 最近的研究发现，超过 70% 的网站上用于共享用户数据（例如第一方 Cookie 和电子邮件地址）的查询参数、资源路径和 URL 片段，在没有第三方 Cookie 或第一方分区的情况下。 除了链接装饰之外，退回跟踪是另一种基于导航的机制，它允许跟踪器跨站点读/写他们的 cookie，从而使第三方 cookie 阻止无效[44].
图 5：导航跟踪
概括地说，跟踪链接的目标是在浏览器的第一方上下文中暂时出现或访问自己的域，因为这可以读取和写入保留在第一方存储中的标识符。
图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 的第一方存储中，完成跨上下文链接（如果重定向到同一个第一方）或跨站点链接（如果重定向到不同的域）。
图 6：弹跳跟踪
退回链可能涉及两个网站（news.com→tracker.com→ news.com 或更长时间），允许跟踪链接在多个看似不相关的网站之间传播稳定的用户标识符，尽管有第三方 cookie 限制。
由于潜在的可用性中断和防御措施的实施，退回跟踪并未广泛普及 2020 年的测量发现，11.6% 的网站使用前 100 个重定向器之一，2022 年，此类标识符存在于 8.1% 的抓取导航中。
5.3防御状态跟踪
鉴于状态跟踪的广泛采用及其感知的侵入性，研究界提出了许多跟踪对策，其中一些措施已被浏览器采用或通过浏览器扩展提供给用户。
5.3.1第三方状态跟踪保护
清除 Cookie。
从逻辑上讲，用户可以在每次会话结束时清除浏览器中的 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 的限制。
浏览器供应商尝试阻止大多数第三方 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 代码，例如基于域或路径的脚本阻止或在其他良性脚本中阻止函数对抗性跟踪器被激励来逃避此类阻止（例如，通过更改脚本位置或导致网站中断），这带来了挑战。
5.3.2防止第一方规避
对第一方 Cookie 的限制。
与第三方 Cookie 不同，第一方 Cookie 不能轻易被完全阻止，因为它会破坏关键网站功能，例如保持登录状态。 因此，他们需要更有针对性的对策，如下所示。
限制跟踪脚本写入的第一方存储的生命周期。
Safari 的智能跟踪保护 （ITP） 将使所有第一方 Cookie 或脚本设置的存储过期，在 7 天内没有用户交互[38]. 为了减少使用 HTTP Cookie 自动覆盖脚本编写的 Cookie 的解决方法，Safari 使用应用于第一方主机的 CNAME 和 IP 地址的启发式方法检测隐藏在第一方子域下的第三方主机[38]. Brave 实现了一个有限版本，它将脚本设置的 cookie 的生命周期限制为 7 天[86].
删除或限制在 URL 参数中传递的标识符的持久性。
一些浏览器会删除跟踪链接已知的 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，包括第一方 Cookie[92,93,94]. 虽然过滤器列表面临上述挑战，但它们也可以使用基于 ML 的方法自动管理[41,95,96].
6无状态跟踪
6.1浏览器指纹识别
浏览器（或设备）指纹识别是一种用于收集用户浏览器和设备信息的技术。 通过使用 HTTP 标头和调用特定的 JavaScript API 端点，网站可以收集有关浏览器及其配置（例如浏览器版本、屏幕大小、已安装的字体列表、GPU 型号、时区和首选语言）到底层作系统和硬件的广泛信息。 研究表明，互联网连接设备的多样性如此之大，以至于收集的属性组合可能是唯一的，从而导致特定设备的识别[97,98,99].图 7 描述了指纹识别的工作原理。 对所有属性的真实指纹和熵计算的分析表明，某些属性对用户唯一性的贡献比其他属性大得多。 熵[100]测量数据集中的不确定性或不可预测性级别，以了解其分布的差异程度。 例如，如果设备的屏幕大小可以有 8 个不同的值，则其熵为 3 位。 与第 5 节中描述的技术不同，指纹识别： 1） 不依赖浏览器中的存储状态（即 ID）来跟踪用户，因为指纹收集是实时执行的以识别设备; 2） 难以检测和阻止; 3） 也很难逃避，因为用户会保留同一设备数月或数年，从而随着时间的推移产生稳定的指纹。
图 7：通过浏览器指纹进行无状态跟踪
自 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].
6.2指纹识别的类型
除了浏览器指纹识别技术外，研究人员还展示了许多跟踪用户的侧信道方法。 其中一种方法是扩展指纹识别，旨在推断用户浏览器中是否存在特定扩展[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]. 通常，侧信道攻击很难检测，也可能同样难以缓解。
6.3指纹识别的需求
从建设性的角度来看，指纹识别可以被视为入侵检测的一种形式。 Web 应用程序可以了解其第一方用户的浏览环境，并将其与特定的用户身份相关联[142]. 例如，网站可以了解到用户 Alice 正在使用具有特定尺寸的智能手机或具有特定类型 GPU 的桌面浏览器。 如果 Alice 的凭据被盗，并且攻击者试图登录该服务，该服务可以提取攻击者的指纹，观察到 Alice 的指纹与之前会话的主要差异，并请求攻击者提供其他身份验证数据（例如一次性密码）。 可以建设性地使用相同的技术来区分真实用户与恶意机器人，以及从事广告欺诈的攻击者。
破坏性地，可以识别用户冒充攻击者和机器人的相同技术可以用于对付希望保持身份匿名的用户。 使用指纹识别，Web 应用程序可能能够确定某个匿名用户实际上是同名的，因为他们的浏览器指纹与同一平台上已知用户的指纹相匹配。 尽管用户试图通过删除其 cookie 或使用浏览器的隐私模式来隐藏，但这种不希望的重新识别还是发生了。 在跨站点上下文中，即使禁用了第三方 Cookie，也可以滥用指纹识别将不相关的网站访问链接在一起。
6.4针对无状态跟踪的防御
浏览器供应商将指纹识别视为一种对 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]. 因此，过去十年缺乏解决指纹识别问题的统一努力表明，截至目前，科技界并无完全消除指纹识别的意愿。
7跨设备跟踪
跨设备跟踪的类型。
跨设备跟踪可以是确定性的或概率性的 [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 的标准化，以更好地控制对功能的访问并有选择地抑制某些频率.
8测量方法
8.1爬行测量
使用检测浏览器进行 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].
8.2用户研究
在实践中，用户研究可以采取多种形式;它们可以通过可用性调查或访谈进行，也可以基于通过现场测量、众包或通过浏览器扩展或应用程序直接收集从真实用户那里收集的数据。例如，国家互联网观察站[206,207,208,209]是一项新兴项目，旨在邀请美国居民自愿提供有关其在线行为的数据，并允许研究人员进行科学研究，以保护隐私。 通过这些技术，研究人员主要研究了参与者对 cookie 对话框的理解、感知和互动[210,211,212,213,214,215,216].他们通常会研究和比较不同的同意对话框设计，发现许多当前的设计有效地推动了参与者选择更多隐私保护选项[211,212].这些研究还建议默认拒绝同意选项，并且用户应该能够轻松地重新访问他们所做的选择[213,217].
图 8：欧盟和美国的主要技术和浏览器特定变更的时间表以及法规概述。
9隐私法规
美国的监管行动。 在美国，各州颁布了自己的隐私立法，联邦层面只有少数狭义的隐私法，特别是针对儿童个人数据 （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].
10讨论和未来展望
10.1状态跟踪
转向第一方Cookie和Cookie分区。
近一半的访问量最大的网站已经在使用第一方跟踪 cookie。我们预计，随着第三方跟踪限制、内容拦截工具和分区的进一步采用，这一趋势将继续下去。 Cookie 分区是一种根据 Cookie 设置的上下文对 Cookie 进行孤立或"分区"的方法，有效地限制了基于浏览器的存储与每个访问的站点保持紧密联系，从而更难在不同站点之间链接用户身份和行为。 尽管如此，最好将分区视为需要更广泛的隐私措施的一个步骤：跟踪器仍然可以使用嵌入在单个域上的指纹和第一方脚本。
更依赖第一方数据和身份图谱。
随着对第三方 cookie 的限制，网站现在依赖于少数主要身份提供商 （例如，Google/YouTube、Facebook/Meta、Apple），这些提供商通过其看门人的地位，可以对用户进行身份验证，同时悄悄地附加持久的、特定于服务的标识符。 许多平台进一步将此流与内部"第一方"和离线数据（如忠诚度卡和销售点数据）融合在一起，构建专有的身份图，将单个用户（或家庭）映射到多个浏览器、应用程序和物理交易。 虽然这些集成有助于出版商在更严格的浏览器策略下衡量转化率和个性化内容，但它们也将行为洞察集中在少数主导参与者身上，并削弱了用户维护独立或假名角色的能力，从而引发了新的反垄断和隐私挑战
会话重播。
会话重播（或录制）脚本捕获详细的用户交互，例如击键、鼠标和滚动移动，以及访问页面的完整内容。 这允许出版商记录和回放访问，就像他们 "越过 [访客] 的肩膀" 一样，用于营销、分析和故障排除等目的[277]. 但是，这些脚本也可以捕获访客填写的敏感个人数据[278,279,280]，而 Session Replay 供应商提供的修订措施通常很脆弱且效果有限[281,278].
10.2无状态跟踪
付费墙强制用户保持可识别性。
避免广告拦截器施加的限制[282]中，某些网站使用付费专区或注册墙，这些付费专区或注册墙在授予内容访问权限之前需要用户身份验证（通常是付款信息）。 这种策略可能会降低用户阻止 cookie 或私下浏览的动机，它还要求用户保持"可识别"，为网站运营商提供一个可靠的标识符，该标识符在会话中持续存在，并且比第三方 cookie 更强大。 虽然付费墙可能支持合法的收入模式------特别是对于面临广告收入下降的出版商------但它们也创造了一个以匿名换取访问的环境。 因此，如果付费墙变得更加普遍，注重隐私的用户可能很难避免在线共享他们的个人数据。
服务器到服务器数据共享
为了规避广告拦截技术，跟踪链接已将其部分跟踪逻辑从客户端转移到服务器端[283]. Google、Meta、Amazon 或 TikTok 等公司已经部署了所谓的转化 API，这些 API 与数据净室一起，允许营销人员以保护隐私的方式对自己的数据与这些围墙花园内的数据进行联合分析。 但是，服务器端跟踪很难审计，因为客户端机制无法检测到 API 和信号[284]然而，对 Meta 转化 API 的分析发现，它与客户端跟踪相当，尽管在共享最少数据时会出现更多的错误匹配[285].
10.3浏览器指纹识别
真实世界的影响。
先前对指纹多样性的研究是在各种大小的数据集上进行的;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]，人们担心反欺诈和程序化广告系统的负面影响。
10.4测量与自动化
HTTP Archive 等工作[198]或 WebREC[205]，存档爬网结果并公开共享其数据集，可能会提供一些技术解决方案，使 Web 测量在未来更易于访问和可重现。 对于仍有待填补的技术测量差距，我们观察到需要自动化框架来监控 Web API 更改并检测浏览器中新出现的侧信道指纹识别风险，以便及时缓解。此外，我们需要更好地了解不同跟踪技术的目的和合法用途[288]- 在 CookieBlock 的模型上[95]将 Cookie 映射到其用途，以实现大规模的合规性测量。具体来说，这将需要将用于跟踪的指纹识别技术与机器人检测分开。
10.5法规遵从性
各种研究表明，许多网站的实际行为并不符合自己的隐私政策[289,290]，或者不尊重或未正确注册用户的同意
合规率如此之低的原因有多种。首先，网站发布者缺乏激励或不了解不考虑隐私合规性------除非存在法律要求或相应的准则[297,298]- 集成可能使用深色模式的第三方时[299,300].其次，监管机构的执法权和具有法律约束力的决定，他们可能没有所需的人力、财力和专门的技术部门[301]调查网站是否合规，而不仅仅是"表面"[302].此外，可用的隐私社区并不总是了解监管要求，也不总是研究对监管机构有意义的设计和 UI 暗模式[216]. 最后，第三方可以逃避法律责任，因为现行法律通常将主要合规义务放在网站所有者身上[303]尽管研究发现了第三方服务的默认配置存在问题[304,305].
10.6浏览器角色的演变
在防止跟踪中。
虽然大多数现代浏览器都提供了跟踪对策，但被动指纹识别（依赖于 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].
10.7在其他生态系统中跟踪
虽然我们的重点是 Web 跟踪，但移动应用程序和 IoT 生态系统中也存在类似的跟踪机制，通常使用通过作系统 API 而不是 Web API 提供的更丰富的传感器信息。存在一些关键的区别和相似之处：网络跟踪依赖于 Cookie，而应用程序跟踪可以访问设备级标识符，例如广告 ID（在 iOS 上称为"IDFA"，在 Android 上称为"AAID"，在三星智能电视上称为"TIFA"），此外，供应商可能会在生态系统中做出不同的设计选择。例如，虽然 Apple 的 Safari 默认阻止第三方 Cookie，但 iOS 会请求授予对设备级标识符的访问权限。同时，Google 的 Chrome 和基于 Android 的作系统默认不会分别阻止第三方 Cookie 或设备级标识符。
10.8生成式 AI
已经部署了生成式 AI 模型来改进广告定位[337]和上下文广告[338]. 此外，虽然生成式 AI 部署在 Web 浏览器中[339]或作为浏览器助手[340]可能会启用新功能，也可能放大危害（例如隐私风险）或创建新的攻击面[341]. 浏览器在确保新型 AI 集成的安全性和隐私性方面发挥着关键作用。
11结论
在推出几十年后，Web 跟踪仍然是一个典型的猫捉老鼠游戏。 每一次增量防御（无论是新的浏览器策略还是监管裁决）都会迅速引发同样复杂的规避技术来跟踪用户。 这种对抗性动态表明，纯粹的反应性方法无法为在线用户提供隐私保证。
仅靠法规是不够的 -- GDPR 和 CCPA 等数据保护法规加强了问责制，但这种执行速度落后于不断发展的跟踪机制的技术变化速度。 此外，跟踪器经常会找到容忍的灰色区域来绕过法规。 因此，执法经常因管辖权或解释争议而停滞不前。 监管机构需要通过与测量界合作来整合敏捷、循证驱动的审计方法，以避免任何监督，并确保法规与技术现实相适应。
另一方面，虽然浏览器是强大的守门人，但它们提供的防线并不可靠。 默认保护措施因浏览器供应商而异，实验性功能有时会在发现问题数年后推出，而商业激励措施通常会导致更宽松的设计。 因此，未来的研究必须超越"在浏览器中修复"的补救措施，并探索真正保护用户隐私的补充方法。
因此，虽然基于浏览器的保护和策略驱动的更改在一定程度上有效，但当前的跟踪环境需要一个默认的隐私优先解决方案，用户可以控制自己的隐私，而不是浏览器或监管机构。 本 SoK 通过总结多年来网络跟踪发展及其预防的重要发现并提出未来的关键方向来强调这一点。 我们希望帮助研究界了解需要关注的新颖和重要内容，以改善用户的在线隐私状况。