智能追踪预防 2.1

2019 年 2 月 21 日

作者：John Wilander

注意：请阅读有关此技术的过往更新，请参阅关于智能追踪预防和存储访问 API 的其他博客文章。

iOS 12.2 以及 macOS High Sierra 和 Mojave 上的 Safari 12.1 的测试版中包含了更新版的智能追踪预防 (ITP)。为了便于开发者沟通，我们将其称为 ITP 2.1。

通过此次更新，我们进一步降低了追踪器跨网站识别用户身份的能力。

每个网站一份独立的 Cookie

ITP 的早期版本允许被归类为具有追踪能力的域存储分区 Cookie，即以顶级站点为键的额外 Cookie 集。从 ITP 2.1 开始，不再支持分区 Cookie，被归类为具有跨站点追踪能力的第三方现在必须使用 Storage Access API 才能获取任何 Cookie 访问权限。

被归类域的 Cookie 和网站数据的修订时间表如下所示

此项更改有多个原因

  • 为开发者简化。 我们收到了现有站点行为因分区 Cookie 而受阻的报告。例如，某个站点有一个脚本，如果它判断用户已注销，就会用空白值覆盖其 Cookie，以确保没有残留数据（除了 Cookie 名称）。当此站点在第三方 iframe 中呈现时，这种 Cookie 覆盖反而会创建一组新的空白 Cookie。
  • 降低内存占用。 从 ITP 1.1 开始，分区 Cookie 是会话 Cookie，这意味着它们不会被持久化。通过取消分区 Cookie，存储会话不必在内存中保留多组 Cookie。
  • 简化其他 WebKit 端口对 ITP 的采用。 分区 Cookie 需要 WebKit 下层 HTTP 层的支持。通过取消对它们的支持，我们增加了 ITP 的灵活性，并使其能够在更多平台上运行。

客户端 Cookie 存储上限为 7 天

Cookie 可以通过 HTTP 响应设置，也可以通过 document.cookie API 设置，后者有时被称为客户端 Cookie。通过 ITP 2.1，所有持久性客户端 Cookie，即通过 document.cookie 创建的持久性 Cookie，其有效期都被限制为七天。

此项更改的原因涵盖隐私、安全和性能

  • 跨站点追踪器已开始利用第一方站点的 Cookie 存储进行持久性追踪。第一方存储空间对隐私来说尤其麻烦，因为第一方上下文中的所有追踪脚本都可以互相读写数据。例如，social.example 将用户追踪 ID 写入 news.example 的第一方 Cookie。现在，analytics.example、adnetwork.example 和 video.example 都可以通过其在 news.example 上的脚本来利用或交叉感染该用户追踪 ID。
  • document.cookie 中可用的 Cookie 可能会被内存推测执行攻击窃取。因此，它们不应携带凭据等敏感信息。
  • document.cookie 中可用的 Cookie 可能会被跨站点脚本攻击窃取。因此，它们也不应携带凭据等敏感信息。
  • Cookie 的泛滥会减慢页面和资源加载速度，因为 Cookie 会被添加到每个适用的 HTTP 请求中。此外，许多 Cookie 具有高熵值，这意味着它们无法高效压缩。我们遇到过在每个资源请求中发送数千字节 Cookie 的站点。
  • 出于性能原因，传出的 Cookie 头部有大小限制，当跨站点追踪器添加第一方 Cookie 时，网站有达到此限制的风险。我们调查了新闻网站订阅者意外注销的报告，发现追踪器添加了太多的 Cookie，以至于新闻网站的合法登录 Cookie 被挤出。

Mike West (Google) 提供了与 Cookie 相关的统计数据。

此更改会导致用户注销吗？

身份验证 Cookie 应该是 Secure 和 HttpOnly，以保护它们免受中间人攻击、跨站点脚本攻击和推测执行攻击。通过 document.cookie 创建的 Cookie 不能是 HttpOnly，这意味着身份验证 Cookie 不应受到生命周期上限的影响。如果它们受到了影响，你需要通过 HTTP 响应设置身份验证 Cookie，并将其标记为 Secure 和 HttpOnly。

实现细节

  • 此更改仅影响通过 document.cookie 创建的 Cookie。
  • 此更改涵盖在第一方上下文以及第三方 iframe 中创建的 Cookie。
  • 会话 Cookie 不受影响，它们仍然是会话 Cookie。
  • 有效期短于七天的持久性 Cookie 将保留其较短的有效期。

已验证的分区缓存

WebKit 在五年多前实现了分区缓存。分区缓存意味着第三方资源的缓存条目通过其源和第一方 eTLD+1 进行双重键控。这禁止了跨站点追踪器使用缓存来追踪用户。即便如此，我们的研究表明，为了在 ITP 下维持其做法，追踪器已诉诸于滥用分区缓存。因此，我们开发了已验证的分区缓存。

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

ITP 目前对永久重定向执行此验证，因为这是我们目前发现滥用的地方。

移除弹出窗口兼容性修复

正如 ITP 2.0 博客文章中所述，我们为第三方弹出窗口实施了临时兼容性修复，自动转发打开页面下的存储访问。在 ITP 2.1 中，我们取消了在用户交互（即点击、轻触或文本输入）之前关闭的弹出窗口的兼容性修复。

移除对 DNT（“请勿追踪”）信号的支持

Apple 认为隐私是一项基本人权，用户不应在不知情或未经同意的情况下被跨网络追踪。智能追踪预防于 2017 年发布时默认对所有用户启用，并阻止用户被他们未曾交互的第三方追踪。自那时以来，ITP 已得到增强，以应对追踪器滥用网络技术追踪用户的情况，并且 Safari 中还添加了其他默认启用的隐私功能，例如浏览器指纹防御。

ITP 2.1 的推出恰逢 Safari 移除对“请勿追踪”(DNT) 信号的支持。DNT 信号是网络利益相关者试图提供给用户一种默认关闭的方式，以请求服务器不追踪他们。重要的是，DNT 没有提供技术强制措施来防止网站追踪用户。Apple 从 2011 年开始支持 DNT 项目，但从那时起，绝大多数网站不幸地未能响应选择开启 DNT 信号的用户而改变其行为。相反，尽管有 DNT 项目，在线追踪和追踪技术变得更加普遍和复杂。

DNT 项目最近在没有发布标准的情况下结束，部分原因是“这些扩展（按定义）的部署不足以证明进一步推进的合理性。”鉴于 DNT 部署的缺乏以及 Safari 默认开启的隐私保护（如 ITP），Safari 移除了对 DNT 的支持，以便用户不会遇到误导性和无效的隐私控制，这种控制如果说有什么作用的话，也只会提供额外的浏览器指纹熵。