无痕浏览 2.0

2024 年 7 月 16 日

作者：John Wilander, Charlie Wolfe, Matthew Finkel, Wenson Hsieh, and Keith Holleman

2005 年，当我们发明无痕浏览时，我们的目标是为用户提供一种简单的方式，使他们的浏览活动不被共享同一设备的人看到。我们创建了一种模式，用户在其中不会留下任何本地的、持久的浏览痕迹。最终，所有其他浏览器都推出了相同的功能。有时，这被称为“临时浏览”。

从 2003 年的 Safari 1.0 开始，我们通过 Cookie 政策将跨站点跟踪预防内置到所有 Safari 浏览中。在过去的 20 年里，我们逐步增加了隐私保护措施。（通过阅读WebKit 中的跟踪预防了解更多信息。）其他流行的浏览器在跟踪预防方面没有我们这么快，但也有所进展。

Apple 认为，用户不应在不知情或未经同意的情况下被跨网站跟踪。进入无痕浏览模式是用户希望获得最佳隐私保护的强烈信号，同时仍然能够享受和利用网络。如果仍停留在 2005 年对无痕模式的定义，即仅仅是临时性的，例如Chrome 的无痕模式，那显然已经不够了。用户期望也理应获得更多。

因此，我们决定进一步发展无痕浏览，并在普通的 Safari 体验之外增加更多保护。去年九月，我们在 Safari 17.0 中为无痕浏览添加了全新的隐私保护级别。在 Safari 17.2 和 Safari 17.5 中，我们又进一步增强了它。此外，当用户启用时，所有这些新的安全措施也适用于常规 Safari 浏览。

通过这项工作，我们极大地增强了网络隐私，并希望为无痕浏览设立新的行业标准。

无痕浏览增强功能概述

以下是 Safari 17.0 中为无痕浏览添加的保护和防御措施

  • 链接跟踪保护
  • 阻止已知跟踪器（包括 CNAME 伪装的已知跟踪器）的网络加载
  • 高级指纹保护
  • 默认关闭可访问网站或历史记录的扩展

此外，我们在所有浏览模式中添加了这些保护和防御措施

  • 限制伪装第三方 IP 地址响应中设置的 Cookie 的生命周期
  • 分区 SessionStorage
  • 分区 Blob URL（从 Safari 17.2 开始）

我们还扩展了 Web AdAttributionKit（以前称为 Private Click Measurement）作为 URL 中跟踪参数的替代，以帮助开发者了解其营销活动在无痕浏览下的表现。

Screenshot of Private Browsing in Safari
Safari 中的无痕浏览

然而，在我们深入探讨这些新的和增强的隐私保护措施之前，我们首先需要考虑这些变化的一个重要方面：网站兼容性风险。

网站崩溃的风险以及我们如何缓解它

关于如何在网络上保护隐私有很多想法，但不幸的是，其中许多可能会破坏用户的体验。就像现实生活中的安全保护一样，必须取得平衡。新的无痕浏览模式恰好达到了这个平衡点，力求不破坏网站。但当然，有些网站的部分功能可能无法正常工作。为了解决这个问题，我们为用户提供了按网站降低隐私保护的选项。这种隐私保护的更改只在浏览该网站时有效。当网页由于隐私保护而无法使用时，此选项是最后的手段。

Reload menu with Reload Reducing Privacy Protections selected
重新加载以降低隐私保护

无痕浏览中的所有新隐私保护措施也适用于常规浏览。在 iOS、iPadOS 和 visionOS 上，前往“设置”>“应用”>“Safari”>“高级”>“高级跟踪和指纹保护”并启用“所有浏览”。在 macOS 上，前往“Safari”>“设置”>“高级”并启用“使用高级跟踪和指纹保护”

Safari Advanced Settings with "Use advanced tracking and fingerprinting protection in all browsing" selected
在 Safari 高级设置中，在所有浏览中使用高级跟踪和指纹保护

现在，让我们来看看这些增强功能是如何工作的。

链接跟踪保护

Safari 的无痕浏览模式实现了两项新的保护措施，用于防止用户在不同网站之间导航时，目标 URL 中的跟踪信息。URL 中具体涵盖的部分是查询参数和片段。这些保护措施的目标是，使在目标站点上运行的第三方脚本更难以通过读取 URL 来关联用户在不同网站上的活动。

我们来考虑一个例子：用户点击了 clickSource.example 上的一个链接，该链接将他们带到 clickDestination.example。URL 看起来像这样

https://clickDestination.example/article?known_tracking_param=123&campaign=abc&click_val=456

Safari 会移除一部分被识别为用于普遍的、精确到用户或点击的跨网站跟踪的查询参数。这是在导航 之前 完成的，因此这些值永远不会通过网络传播。如果上面的 known_tracking_param 代表这样一个查询参数，用于导航的 URL 将是

https://clickDestination.example/article?campaign=abc&click_val=456

顾名思义，上面的 campaign 表示一个仅用于广告系列归因的参数，而不是点击或用户级别的跟踪。Safari 允许此类参数通过。

最后，在跨站点导航之后的目标网站上，所有尝试读取完整 URL（例如使用 location.search、location.href 或 document.URL）的第三方脚本都将获得一个没有查询参数或片段的 URL 版本。在我们的示例中，这个脚本暴露的值就是

https://clickDestination.example/article

类似地，Safari 在无痕浏览中也会隐藏所有跨站点的 document.referrer 不被脚本访问。

无痕浏览中的 Web AdAttributionKit

Web AdAttributionKit（以前称为 Private Click Measurement）是一种让广告商、网站和应用程序以保护隐私的方式实现广告归因和点击测量的工具。您可以在这里阅读更多信息。除了无痕浏览中新增的隐私保护套件外，Safari 还将 Web AdAttributionKit 的一个版本带到无痕浏览中。这使得点击测量和归因能够以保护隐私的方式继续运行。

无痕浏览中的 Web AdAttributionKit 的工作方式与常规浏览相同，但有一些限制

  • 归因范围限定在独立的无痕浏览标签页内，并在点击链接时将归因转移到新打开的标签页。然而，归因不会通过其他间接导航方式保留：例如，复制链接并粘贴到新标签页。实际上，这与 Web AdAttributionKit 在直接响应广告中的工作方式类似。
  • 由于无痕浏览不保留任何数据，因此当标签页关闭时，待处理的归因请求将被丢弃。

阻止已知跟踪器的网络加载

Safari 17.0 还为无痕浏览配备了自动启用的内容拦截器，可阻止对已知跟踪器的网络加载。虽然智能跟踪预防长期以来一直阻止所有第三方 Cookie，但首先阻止跟踪器的网络请求离开用户设备，可确保没有任何个人信息或跟踪参数通过 URL 本身泄露。

这个自动启用的内容拦截器是根据 DuckDuckGo 和 EasyList 中的 EasyPrivacy 过滤规则的数据编译而成的。此内容拦截器标记的请求仅是 DuckDuckGo 和 EasyPrivacy 都 标记为跟踪器的条目。通过这样做，Safari 特意允许大多数广告即使在无痕浏览中也能继续加载。

无痕浏览还阻止伪装的已知跟踪域的网络请求。否则，它们可以在第一方上下文中保存第三方 Cookie。此保护要求 macOS Sonoma 或 iOS 17。伪装指的是通过 CNAME 伪装或第三方 IP 地址伪装将子域映射到第三方服务器。另请参阅下面的“防御伪装的第一方 IP 地址”部分。

当 Safari 阻止对已知跟踪器的网络请求时，将记录以下形式的控制台消息，并可以使用 Web Inspector 查看

`Blocked connection to known tracker: tracker.example`

网络隐私增强

Safari 15.0 默认开始隐藏已知跟踪器的 IP 地址。Safari 17.0 中的无痕浏览为所有用户增加了以下保护

  • 加密 DNS。DNS 查询用于将服务器主机名解析为 IP 地址，这是访问互联网的必要功能。然而，DNS 传统上未加密，并允许网络运营商跟踪用户活动或将用户重定向到其他服务器。无痕浏览默认使用隐私 DNS over HTTPS，它对 DNS 查询进行加密和代理，以保护这些查找的隐私和完整性。
  • 代理未加密的 HTTP。无痕浏览中加载的任何未加密 HTTP 资源都将使用与隐藏跟踪器 IP 地址相同的多跳代理网络。这确保了本地网络中的攻击者无法查看或修改无痕浏览流量的内容。

此外，对于已开启 iCloud 私密转发的 iCloud+ 订阅用户，无痕浏览通过以下增强功能将隐私提升到新的水平

  • 每个标签页独立会话。用户在无痕浏览中打开的每个标签页现在都使用独立的会话连接到 iCloud 私密转发代理。这意味着网页服务器将无法判断两个标签页是否源自同一设备。每个会话独立分配出口 IP 地址。请注意，这不适用于需要程序化父子关系的窗口，例如弹出窗口及其打开者。
  • 默认的地理位置隐私。无痕浏览根据您的国家和时区使用 IP 位置，而不是更具体的位置。
  • 披露 IP 地址前的警告。当访问无法从公共互联网（例如本地网络服务器或公司内部服务器）访问的服务器时，Safari 无法使用 iCloud 私密转发。在无痕浏览中，Safari 现在会显示一个警告，要求用户在加载页面前同意向服务器透露其 IP 地址。

无痕浏览中的扩展

Safari 17.0 还提升了无痕浏览中扩展的隐私性。现在，默认情况下，在无痕浏览中，可以访问网站数据和浏览历史记录的扩展程序是关闭的。用户仍然可以选择允许扩展程序在无痕浏览中运行，并获得该扩展程序的所有功能。不访问网页内容或浏览历史记录的扩展程序（如内容拦截器）在 Safari 中开启后，默认在无痕浏览中开启。

高级指纹保护

随着 Safari 以及随后的其他浏览器限制有状态跟踪（例如跨站点 Cookie），许多跟踪器转向了无状态跟踪，通常称为 指纹识别。

指纹识别的类型

我们区分以下类型的指纹识别

  • 设备指纹识别。这是根据设备特性构建指纹，包括硬件、当前操作系统和浏览器。如果允许检测，它还可以包括连接的外围设备。这种指纹无法通过用户设置或网页扩展来更改。
  • 网络和地理位置指纹识别。这是根据设备如何连接到互联网以及任何检测其地理位置的方法来构建指纹。它可以通过测量网络请求的往返速度或简单地使用 IP 地址作为标识符来完成。
  • 用户设置指纹识别。这是指在用户可以更改设置的平台上读取用户设置的状态，例如深色/浅色模式、区域设置、字体大小调整和窗口大小。它还包括检测网页扩展和辅助功能工具。我们认为这种指纹识别尤其有害，因为它利用用户如何自定义其网络体验以满足其需求的方式。
  • 用户行为指纹识别。这是指检测用户行为中的重复模式。这可能是鼠标指针的使用方式、在表单字段中键入的速度，或者滚动方式。
  • 用户特征指纹识别。这是关于发现用户的个人信息，例如他们的兴趣、年龄、健康状况、财务状况和教育背景。这些获取的特征可以构成一个独特的 ID，也可以直接用于向他们定向特定内容、调整价格或定制消息。

指纹稳定性

任何试图创建指纹的跟踪器所面临的挑战是指纹在时间上的稳定性。软件版本指纹会随软件更新而改变，网页扩展指纹会随扩展更新和启用/禁用而改变，用户设置会随用户意愿而改变，同一设备的多用户意味着行为指纹会改变，漫游设备可能会经常改变网络和地理位置。

指纹识别隐私问题 1：跨站跟踪

指纹可用于跨网站跟踪用户。如果成功，它会破坏存储分区和链接装饰过滤等跟踪预防措施。

这个问题有两种解决方案

  1. 让指纹在许多用户之间共享，这被称为群体免疫。
  2. 使每个网站的指纹都独一无二，通常通过注入随机噪声来实现。

指纹识别隐私问题 2：每网站用户召回

较少被提及的是每网站用户召回的指纹识别问题。网页浏览器至少提供两种方式让用户重置他们与网站的关系：清除网站数据或使用无痕浏览。这两种方式都会使后续对网站的导航重新开始。

但是指纹识别会挫败这一点，并允许网站记住用户，即使他们选择了清除网站数据或使用无痕浏览。

这个问题有两种解决方案

  1. 让指纹在许多用户之间共享，这被称为群体免疫。
  2. 使指纹在每个网站上都是独一无二的，并为每次重新开始（例如删除网站数据时）生成一个新的独一无二的指纹。

指纹识别隐私问题 3：每网站访客唯一性

我们认为，终极反指纹识别挑战是解决特定用户在访问特定网站时的唯一性问题。这里有一个简单的例子

在许多情况下，将区域设置设为美式英语的 US/EN 可能会提供足够的群体免疫。但是，当一个拥有该设置的用户访问冰岛政府网站或韩国读书俱乐部网站时会发生什么？他们可能会在那个特定网站上发现自己处于一个非常小的“群体”中，再加上少数几个指纹识别接触点，他们就可以被唯一识别。

浏览器通常无法解决每网站访客唯一性问题，除非它知道单个网站的访客分布情况。

指纹保护高层概览

我们将跨站跟踪和每站用户召回视为浏览器需要解决的隐私问题。

我们的方法:
使指纹在每个网站上都是独一无二的，并为每次重新开始（例如删除网站数据时）生成一个新的独一无二的指纹。

我们的工具:

  • 使用多跳代理隐藏 IP 地址，并防御网络和地理位置指纹识别。
  • 尽可能限制可指纹识别的 Web API 数量。这可能意味着修改 API、将其置于用户权限之后，或者不实现它们。
  • 在可指纹识别的 Web API 返回值中注入少量噪声。

指纹保护详情

Safari 新的高级指纹保护措施，通过使用多个 Web API，使得脚本难以 可靠地 提取 高熵 数据

  1. 为了使其更难 可靠地 提取有关用户配置的详细信息，Safari 在各种 API 中注入了噪声：即在 2D canvas 和 WebGL 回读期间，以及在使用 WebAudio 读取 AudioBuffer 样本时。
  2. 为了减少通过其他 API 暴露的整体 熵，Safari 还会将某些与窗口或屏幕指标相关的 Web API 的结果覆盖为固定值，这样，对于具有不同屏幕或窗口配置的用户，调用这些 API 的指纹脚本将获得相同的结果，即使用户的底层配置不同。

2D 画布和 WebGL

许多现代网页浏览器使用计算机的图形处理单元 (GPU) 来加速图形渲染。Web 的 Canvas API（2D Canvas）和 WebGL API 为网页提供了使用 GPU 渲染任意图像和复杂场景，并分析结果的工具。这些 API 对网络平台很有价值，但它们允许网页在未经同意的情况下了解底层硬件的独特细节。启用 Safari 的高级指纹保护后，Safari 会对使用绘图命令绘制在画布上的像素应用微量的噪声。这些修改在不显著影响渲染图形的情况下降低了使用这些 API 时的指纹值。

务必强调以下几点

  1. 此噪声注入仅发生在画布上发生绘图的区域。
  2. 注入的噪声量极小，并且（大部分）不应导致可观察到的差异或伪影。

此策略有助于缓解由此类噪声注入引起的许多兼容性问题，同时仍保持强大的指纹识别缓解措施。

在 Safari 17.5 中，我们通过在 Service Worker 和 Shared Worker 中从离屏画布回读数据时额外注入噪声来加强这些保护。

Web 音频

同样，当使用 WebAudio API — 通过 AudioBuffer.getChannelData() — 读取样本时，每个样本都会被施加微量的噪声，使其很难可靠地测量操作系统差异。实际上，这些差异已经非常微小。通常是由于应用 FFT 或 IFFT 时操作顺序的微小差异。因此，相对较低的噪声量可以使得获取稳定指纹的难度大大增加。

在 Safari 17.5 中，我们通过以下方式使音频噪声注入更加健壮

  • 注入的噪声现在在给定的音频缓冲区中对相同的值保持一致——这意味着包含单个高熵样本的循环 AudioSourceNode 不能用于平均注入的噪声并快速获得原始值。
  • 我们现在使用正态分布噪声，而不是使用均匀分布噪声。与均匀分布噪声情况下最小和最大值的平均值相比，这种分布的平均值收敛到原始值的速度要慢得多。
  • 我们重构了噪声注入机制，以支持任意级别的噪声注入，而不是使用低而固定的噪声量（0.1%）。这使得我们可以轻松地微调噪声注入，例如在使用已知通过微小的样本值差异揭示细微 OS 或硬件差异的音频节点时，噪声的大小会增加。

当使用 Audio Worklets（例如 AudioWorkletNode）回读音频样本时，此噪声注入也会激活。

屏幕/窗口指标

最后，对于当前直接公开窗口和屏幕相关指标的各种 Web API，Safari 采取了不同的方法：不是使用上述基于噪声注入的缓解措施，而是通过将结果固定为硬编码值或与其他 API 匹配的值来降低熵。

  • screen.width / screen.height：屏幕尺寸固定为 innerWidth 和 innerHeight 的值。
  • screenX / screenY：屏幕位置固定为 (0, 0)。
  • outerWidth / outerHeight：与屏幕尺寸类似，这些值固定为 innerWidth 和 innerHeight。

这些缓解措施也适用于使用媒体查询间接观察屏幕尺寸的情况。

不要向网络添加可指纹识别的 API，例如 Topics API

多年来，我们一直与标准社区合作，以改善网络平台的用户隐私。现有的 Web API 是可指纹识别的，例如 Canvas，并且限制它们的可指纹识别性是一个漫长的过程。特别是因为我们希望确保现有网站能够继续良好运行。

对于网络的未来隐私而言，不应通过新增可指纹识别的 API 来加剧指纹识别问题。在某些情况下，权衡利弊告诉我们，丰富的网络体验或增强的可访问性需要一定程度的可指纹识别性。但总的来说，我们的立场是，我们应该在不增加指纹识别性的前提下推进网络发展。

我们最近反对的一项新提案是 Topics API，它现在正在 Chrome 浏览器中推出。作为标准流程的一部分，我们提供了广泛的批判性反馈，我们想在这里重点介绍几点。

Topics API 概述

根据提案

// document.browsingTopics() returns an array of up to three topic objects in random order.
const topics = await document.browsingTopics();

任何 JavaScript 都可以在网页上调用此函数。是的，这包括跟踪器脚本、广告脚本和数据代理脚本。

主题来自预定义的数百个主题列表。不是用户从这些主题中选择，而是 Chrome 会随着时间记录用户的浏览历史并从中推断出兴趣。用户不会被提前告知 Chrome 给他们标记了哪些主题，或者它将哪些主题暴露给哪些方。这一切都在后台默认发生。

此 API 的目的是帮助广告商根据每个用户的兴趣向其投放广告，即使当前网站不一定暗示他们拥有这些兴趣。

Topics API 的指纹识别问题

威斯康星大学麦迪逊分校的 Yohan Beugin 和 Patrick McDaniel 的一篇新研究论文详细介绍了 Chrome Topics API 的实际实现。

作者利用大规模真实用户浏览数据（自愿捐赠）来展示如何规避本应为用户提供合理否认权的 5% 噪声，以及 Topics API 如何被用于指纹识别和重新识别用户。

“我们得出结论，来自这个真实数据集的重要一部分用户在我们的实验中仅通过观察他们的兴趣主题就被跨网站重新识别。因此，我们数据集中的真实用户可以通过 Topics API 进行指纹识别。此外，正如所见，随着越来越多的用户被唯一重新识别，信息泄露和隐私侵犯会随着时间的推移而恶化。”——Beugin 和 McDaniel，威斯康星大学麦迪逊分校

该论文于 5 月在2024 年 IEEE 安全和隐私研讨会 (SPW) 上发表。

Topics API 的其他隐私问题

重新识别和跟踪用户并非 Topics API 唯一的隐私问题。还有用户跨站点活动的用户画像。这里有一个使用 Chrome 预定义列表中主题的例子。

想象一下，2024 年 5 月，您访问了 news.example，您是该网站的订阅者并提供了您的电子邮件地址。网站上嵌入了 dataBroker.example。数据代理从登录表单中获取了您的电子邮件地址，并调用 Topics API 来了解您当前拥有以下兴趣

  • 鲜花
  • 活动与工作室摄影
  • 奢华旅行

2026 年 5 月，您访问了 news.example，dataBroker.example 调用 Topics API，被告知您现在有这些兴趣

  • 童装
  • 家庭旅行
  • 玩具

最后，在 2029 年 5 月，您访问了 news.example，dataBroker.example 调用 Topics API，被告知您有这些兴趣

  • 法律服务
  • 家具租赁
  • 儿童看护

您没有向任何可以访问您电子邮件地址的网站透露任何有关您家庭生活的信息。但是数据代理已经能够读取您不断变化的兴趣，并将其存储在您的永久档案中——而您正在阅读新闻。

现在想象一下，先进的机器学习和人工智能可以根据兴趣信号的各种组合推断出您的什么信息。当数据代理和跟踪器可以在人群的大部分范围内进行比较和对比时，会出现什么模式？请记住，他们可以将 Topics API 的输出与他们可用的任何其他数据点结合起来，正是所有这些数据的分析共同作用于那些试图对您得出结论的算法。

我们认为，网络不应该在网站之间公开此类信息，我们也不认为浏览器，即 用户代理，应该协助任何此类数据收集或使用。

两种浏览模式下的隐私增强

我们对伪装第三方 IP 地址的防御以及 SessionStorage 和 blob URL 的分区在常规浏览和无痕浏览中默认启用。以下是这些保护措施的工作方式。

防御伪装的第一方 IP 地址

2020 年，智能跟踪预防 (ITP) 获得了将第三方 CNAME 伪装的 HTTP 响应中设置的 Cookie 有效期限制为 7 天的能力。

这种防御并未缓解使用 IP 别名将第三方请求伪装成第一方子域的情况。ITP 现在还对来自伪装第三方 IP 地址的响应中 Cookie 的有效期施加 7 天的限制。第三方 IP 地址的检测是启发式的，将来可能会改变。目前，如果满足以下任何条件，则两个 IP 地址被视为不同方

  1. 一个 IP 地址是 IPv4，而另一个是 IPv6。
  2. 如果两个地址都是 IPv4，则公共子网掩码的长度小于 16 位（完整地址长度的一半）。
  3. 如果两个地址都是 IPv6，则公共子网掩码的长度小于 64 位（也是完整地址长度的一半）。

分区 SessionStorage 和 Blob URL

网站有多种选择来存储较长时间的信息。会话存储 (Session Storage) 是 Safari 中的一个存储区域，其范围限定在当前标签页。当 Safari 中的标签页关闭时，与其关联的所有会话存储都将被销毁。从 Safari 16.1 开始，跨站点会话存储按第一方网站进行分区。

同样，Blob 是一种存储类型，允许网站在浏览器中存储原始的、类似文件的i数据。Blob 几乎可以容纳任何内容，从简单的文本到更大、更复杂的视频文件。可以为 Blob 创建一个唯一的 URL，只要 Blob 仍然存在，就可以使用该 URL 访问关联的 Blob。这些 URL 通常被称为 Blob URL，Blob URL 的生命周期限定在创建它的文档中。从 Safari 17.2 开始，跨站点 Blob URL 按第一方网站进行分区，第一方 Blob URL 不能被第三方使用。

设定新的行业标准

Safari 17.0、Safari 17.2 和 Safari 17.5 中无痕浏览的额外隐私保护措施为用户保护设定了新标准。我们很高兴所有 Safari 用户和网络本身都能从这项工作中受益！

反馈

我们很乐意倾听您的意见！如需分享您对无痕浏览 2.0 的看法，请在 Mastodon 上找到 John Wilander (@wilander@mastodon.social) 或在 X 上回复 @webkit。您也可以在领英上关注 WebKit。如果您遇到任何问题，欢迎您就 Safari UI 提交反馈（了解更多关于提交反馈的信息），或提交关于网页技术或 Web Inspector 的WebKit 错误报告。