WebKit 中的跟踪预防

目录

• 术语
• 默认 Cookie 政策
• 无痕浏览模式
• 分区第三方存储
• 分区 Service Worker
• 分区第三方 HTTP 缓存
• 反指纹识别
• 智能跟踪预防 (ITP)

WebKit 从 2003 年 Safari 1.0 发布至今，已实施了多项跟踪预防技术。其中大多数默认开启。本文档介绍了包括智能跟踪预防 (ITP) 在内的已发布功能行为。

您可以通过阅读我们的《跟踪预防政策》，了解我们为何阻止跨网站跟踪以及如何处理其固有的权衡。

术语

首先，我们来定义一些术语。

• **可注册域**是指网站的 eTLD+1 或有效顶级域加一个标签。有效顶级域在公共后缀列表中定义。
• **网站或站点**。网站是一个可注册域，包括其所有子域。其他人将站点定义为也包括方案，使得 http://news.example 和 https://news.example 成为两个不同的站点。就本文档而言，我们认为 http 和 https 属于同一站点，因为 Cookie 仍然可以跨方案。
• **跨网站**。用户可以在不同网站之间导航，或者一个网站可以从不同网站加载子资源。这些被称为跨网站导航和跨网站加载。就跟踪而言，跨网站意味着跨不同网站进行跟踪。
• **第一方和第三方**。如果 news.example 显示在 URL 栏中，并且它从 adtech.example 加载子资源，那么 news.example 是第一方，adtech.example 是第三方。请注意，不同的方必须是不同的网站。sub.news.example 在 news.example 下加载时被认为是第一方，因为它们被认为是同一站点。
• **第三方 Cookie**。没有哪种特殊的 Cookie 构成第三方 Cookie。相反，它指的是当内容从第三方加载时，其对自身 Cookie 的访问权限。假设您的浏览器正在从第一方网站 news.example 上的网页加载来自第三方 adtech.example 的图片。如果您的浏览器允许，对 adtech.example 的第三方请求可能包含 Cookie，并且来自 adtech.example 的后续响应可能会设置新的 Cookie。这两种能力——发送现有 Cookie 和接受第三方内容的新 Cookie——都被称为第三方 Cookie。
• **用户交互**是用户在网站上的点击、轻触或键盘输入。有些人将其称为*用户手势*。滚动不被视为用户交互。
• **分区**是一种允许第三方使用存储和有状态网页功能的技术，但这些功能在每个第一方网站上都是独立的。假设 adtech.example 是 news.example 和 blog.example 下的第三方，并且 adtech.example 使用 LocalStorage。通过分区 LocalStorage，adtech.example 将在 news.example 和 blog.example 下获得唯一的存储实例，从而消除了通过 LocalStorage 进行跨网站跟踪的可能性。
• **临时性**。当我们说临时存储时，我们指的是存储不会持久化到磁盘，并且会随着应用程序的关闭而消失，例如当用户退出浏览器或重启设备时。

默认 Cookie 政策

WebKit 在 Apple 的 iOS、macOS、iPadOS、tvOS 和 watchOS 上的默认 Cookie 政策是，除非第三方已经拥有 Cookie，否则不允许其设置新的 Cookie。这意味着，作为第三方要想使用 Cookie，该域必须首先成为第一方并在那里设置其初始 Cookie。这项默认 Cookie 政策自 Safari 1.0 起生效，并作为“阻止跨网站跟踪”设置的一部分，至今仍在生效。

无痕浏览模式

Safari 无痕浏览模式的基础是一个临时会话，它确保 Cookie 和其他有状态的内容不会持久化，并在用户关闭标签页、退出浏览器或重启设备时消失。Safari 的无痕浏览模式为用户打开的每个标签页使用一个新的临时会话，以隔离不同标签页。

分区第三方存储

第三方 LocalStorage 和 IndexedDB 按第一方网站进行分区，并也设为临时性。

分区 Service Worker

第三方 Service Worker 被分区，其缓存和 IndexedDB 也被分区。

分区第三方 HTTP 缓存

第三方内容的 HTTP 缓存条目按第一方网站进行分区。

反指纹识别

指纹识别涉及测量静态设备配置（例如内置硬件）、动态设备或浏览器配置（例如用户设置或已安装外设）以及用户浏览数据（例如检查用户登录了哪些网站，即所谓的登录指纹识别）的独特性。

在实施新的 Web 功能时，我们会寻找指纹识别漏洞和改进用户隐私的机会。我们旨在通过 Web 标准化流程与其他实施者合作，为用户争取权益，并确保规范允许或最好要求我们已添加的保护措施。

以下是已有的此类行为变更示例：

• 要求网站在移动设备上访问设备方向/运动 API 时需要用户许可，因为运动传感器的物理特性可能允许设备指纹识别。
• 通过 Web 实时通信 API (WebRTC) 阻止对连接的摄像头和麦克风进行指纹识别。
• 更改了 Web 内容的字体可用性，使其仅包含 Web 字体和操作系统自带字体，而不包括本地用户安装的字体。Web 字体、常用 Web 安全字体以及其他操作系统捆绑字体仍然可用。
• 更改了用户代理字符串，使其不随次要软件更新而改变。该字符串仅随平台和浏览器的市场版本而改变。

我们的下一道防线是尽可能移除现有的指纹识别向量。过去几年，我们已进行了以下更改：

• 移除了“请勿跟踪”标志，讽刺的是，该标志曾被用作指纹识别向量，增加了启用它的用户的独特性。
• 移除了对 macOS 上任何插件的支持。其他桌面版本可能有所不同。（iOS 上从未支持插件。）

最后，如果我们发现某些功能和 Web API 增加了指纹识别的可能性，并且无法安全地保护我们的用户，那么在找到有效降低指纹识别性的方法之前，我们将不会实现它们。我们继续通过 Web 标准化流程与其他浏览器制造商进行开放讨论，其中许多制造商也持有这些担忧。以下是我们因指纹识别、安全及其他担忧而决定暂不实现的一些功能示例，并且我们目前尚未找到解决这些担忧的方法：

• Web 蓝牙
• Web MIDI API
• 磁力计 API
• Web NFC API
• 设备内存 API
• 网络信息 API
• 电池状态 API
• Web 蓝牙扫描
• 环境光传感器
• EME 的 HDCP 策略检查扩展
• 距离传感器
• WebHID
• 串口 API
• Web USB
• 地理位置传感器（后台地理位置）
• 用户空闲检测

智能跟踪预防 (ITP)

完全阻止第三方 Cookie

ITP 默认阻止所有第三方 Cookie。此阻止没有例外。第三方 Cookie 访问只能通过 Storage Access API 和弹出窗口的临时兼容性修复获得授权。

Cookie 阻止锁定模式

一旦某个请求被阻止使用 Cookie，则该请求的所有重定向也将被阻止使用 Cookie。

降级第三方引荐来源网址

所有第三方引荐来源网址默认降级为其来源。这适用于 HTTP 引荐来源标头和 document.referrer。例如，如果完整的引荐来源网址是 https://www.social.example/feed?clickID=123456，它将显示为 https://www.social.example/。

阻止第三方 HSTS

HSTS（HTTP 严格传输安全）只能由第一方网站设置，且仅限于当前主机/域以及该网站的可注册域。此外，HSTS 不适用于不携带 Cookie 的第三方请求，并且由于所有第三方 Cookie 默认被阻止，因此第三方 HSTS 也被阻止。

分类为具有跨网站跟踪能力

除了全面阻止第三方 Cookie 和降级第三方引荐来源网址之外，ITP 还收集资源加载统计信息，并将其与已知的跨网站跟踪模式进行匹配。如果一个可注册域至少匹配其中一种模式，则会被归类为具有跨网站跟踪能力。

其中一种模式是作为第三方资源出现在多个第一方网站下。一个机器学习模型根据以下三个数字来决定何时将 domain.example 归类：

• domain.example 作为第三方子资源出现的唯一网站数量。
• domain.example 作为第三方 iframe 出现的唯一网站数量。
• domain.example 进行跨网站重定向的唯一网站数量。

另一种被检测为具有跨网站跟踪能力的模式是顶级框架重定向，通常被称为跳转跟踪。ITP 会计算 domain.example 执行的此类唯一重定向次数，并根据该数字进行分类。即使重定向因着陆到网页并在几秒后触发导航而延迟，ITP 仍将其计为一次跳转。

检测到的第三种模式称为跟踪器串通。如果 domain.example 被归类为具有跨网站跟踪能力，系统会检查之前有哪些其他域重定向到 domain.example，所有这些域也会被归类。然后，这个过程会通过重定向图递归地重复。

针对分类域采取的行动

对于在过去 30 天的浏览器使用中，未作为第一方接收用户交互或未通过 Storage Access API（见下文）被授权为第三方存储访问的已分类域，其所有网站数据都将被删除。此类网站删除操作会以一定间隔进行，以避免产生过多的磁盘 I/O。

已分类域如果作为第一方接收了用户交互或被授予了存储访问权限，但被发现参与跳转跟踪（顶级框架重定向），其 Cookie 可能会被重写为 SameSite=strict。

验证分区缓存

当为被 ITP 分类为具有跨网站跟踪能力的域创建分区缓存条目时，该条目会被标记以进行验证。七天后，如果对此类标记条目发生缓存命中，WebKit 将如同从未见过此资源一样，再次加载它。然后将新响应与缓存响应进行比较，如果它们在出于隐私原因我们关注的方式上匹配，则清除验证标志，并且该缓存条目从那时起被视为合法。然而，如果新响应与缓存条目不匹配，则丢弃旧条目，并创建一个设置了验证标志的新条目，验证过程重新开始。

通过链接装饰检测跨网站跟踪

一些跟踪器在链接中添加所谓的“点击 ID”作为 URL 参数，并通过链接目标网站上的 JavaScript 获取它们。然后，它们将点击 ID 存储在可用的一种存储形式中。通过这种方式，它们可以在网站之间建立用户身份。这称为通过链接装饰进行的跨网站跟踪。

ITP 检测此类链接装饰，并将着陆网页上通过 JavaScript 创建的 Cookie 的有效期限制为 24 小时。

所有可脚本写入存储的 7 天上限

在第一方上下文中执行脚本的跟踪器通常利用第一方存储来保存和检索跨网站跟踪信息。因此，ITP 会在用户与网站没有交互 7 天后，删除所有通过 JavaScript 创建的 Cookie 和所有其他可脚本写入的存储。后者的存储形式包括：

• IndexedDB
• LocalStorage
• 媒体密钥
• SessionStorage
• Service Worker 注册和缓存

CNAME 和第三方 IP 地址隐藏防御

ITP 检测第三方 CNAME 隐藏和第三方 IP 地址隐藏请求，并将 HTTP 响应中设置的任何 Cookie 的有效期限制为 7 天。

第三方 CNAME 隐藏定义为一种第一方子资源，它通过一个 CNAME 解析，该 CNAME 与第一方域不同，并且（如果存在）与顶级框架主机的 CNAME 也不同。

此表解释了七种可能的场景（1p 表示第一方，3p 表示第三方）

1p 主机，例如 www.blog.example	1p 子域，而非 1p 主机，例如 track.blog.example	Cookie 有效期受限？
无隐藏	无隐藏	无限制
无隐藏	other.blog.example (1p 隐藏)	无限制
无隐藏	tracker.example (3p 隐藏)	7 天上限
abc123.edge.example (隐藏)	无隐藏	无限制
abc123.edge.example (隐藏)	abc123.edge.example (匹配隐藏)	无限制
abc123.edge.example (隐藏)	other.blog.example (1p 隐藏)	无限制
abc123.edge.example (隐藏)	tracker.example (3p 隐藏)	7 天上限

主屏幕 Web 应用程序域不受 ITP 限制

主屏幕 Web 应用程序的第一方域不受 ITP 对所有可脚本写入存储的 7 天上限限制，即 ITP 在其网站数据删除算法中始终跳过该域。此外，主屏幕 Web 应用程序的网站数据与 Safari 保持隔离，因此不会受到 ITP 在 Safari 中跟踪行为分类的影响。