智能跟踪预防 2.3

2019年9月23日

作者：John Wilander

注意：请阅读关于智能跟踪预防、存储访问 API 和 ITP 调试模式的其他博客文章中这项技术的过往更新。

智能跟踪预防 (ITP) 2.3 版已包含在 iOS 13 上的 Safari、iPadOS 测试版以及 macOS Catalina、Mojave 和 High Sierra 上的 Safari 13 中。

通过链接装饰增强跟踪预防

我们之前的版本 ITP 2.2 专门关注了所谓的链接装饰在跨站跟踪方面的滥用。通过 ITP 2.2，当网页从被 ITP 分类的域导航而来，且目标 URL 包含查询字符串或片段时，在该页面上创建的持久客户端 Cookies 的有效期为 24 小时。

不幸的是，我们发现链接装饰仍在被持续滥用，因此 ITP 2.3 采取了两项新措施来应对此问题。

所有可由脚本写入的网站数据生命周期设限

自 ITP 2.2 以来，一些跟踪器已宣布从第一方 Cookie 转向替代的第一方存储，如 LocalStorage。ITP 2.3 通过以下方式对此进行反制：

  1. 如果用户从具有跨站跟踪能力的分类域导航到带有查询字符串和/或片段标识符的最终 URL（例如 website.example?clickID=0123456789），则 website.example 将被标记为删除非 Cookie 网站数据。
  2. 如果用户在 Safari 使用的七天内没有与 website.example 上的网页进行交互，则 website.example 的所有非 Cookie 网站数据将被删除。

结合 ITP 对客户端 Cookie 的有效期限制，此更改消除了跟踪器使用链接装饰结合长期第一方网站数据存储来跟踪用户的能力。换句话说，ITP 2.3 限制了从分类域进行链接装饰导航后所有*可由脚本写入*的网站数据的生命周期。

我们限制可由脚本写入的存储生命周期的原因很简单。多年来，网站所有者一直被说服在其网站上部署第三方脚本。现在这些脚本被重新利用来规避浏览器对第三方跟踪的保护。通过限制使用*任何*可由脚本写入的存储进行跨站跟踪的目的，ITP 2.3 确保第三方脚本不能利用它们在所有这些网站上获得的存储权限。

document.referrer 降级为 eTLD+1

我们的研究发现，跟踪器不再装饰目标页面的链接，而是装饰它们自己的引用者 URL，并通过目标页面上的 document.referrer 读取跟踪 ID。

ITP 2.3 通过以下方式对此进行反制：如果引用者有链接装饰且用户是从分类域导航而来，则将 document.referrer 降级为引用者的 eTLD+1。例如，用户从 social.example 导航到 website.example，且引用者是 https://sub.social.example/some/path/?clickID=0123456789。当 social.example 在 website.example 上的脚本读取 document.referrer 以检索并存储点击 ID 时，ITP 将确保只返回 https://social.example。

有关引用者的滥用和浏览器总体变化进一步阅读，请参阅 WHATWG Fetch issue 限制 Referer 头的长度。

存储访问 API 更新

开发者增强请求

开发者向我们提出了对存储访问 API 的两项更改请求，我们很高兴能在 iOS 13 测试版、iPadOS 测试版和 macOS Catalina 测试版上的 Safari 中提供这些功能：

  • 仅在用户明确拒绝访问时（即当用户被提示并选择“不允许”时）才消耗用户手势（轻触或点击）。以前，当请求被拒绝而没有用户提示时（即当请求域被 ITP 分类且在过去 30 天的 Safari 使用中没有收到第一方网站的用户交互时），手势也会被消耗。这意味着用户必须再次轻触或点击才能显示弹出窗口以登录第三方服务。
  • 当 ITP 关闭时，使 document.hasStorageAccess() 返回 true。当 document.hasStorageAccess() 返回 false 但 ITP 关闭时，开发者感到困惑。现在在这种情况下它返回 true。请注意，返回 true 并不保证第三方可以设置 Cookie，因为 Safari 的默认 Cookie 策略是如果第三方尚未拥有 Cookie，则拒绝它们设置 Cookie。

用户增强请求

用户要求我们限制特定嵌入式网页内容可以请求存储访问的次数。

一些服务在每次点击或轻触时都请求存储访问，无论之前与用户的交互如何。为了应对这种重复提示，WebKit 的存储访问 API 实现现在将自动拒绝用户已在提示中两次选择“不允许”的文档的存储访问请求。我们之所以不将其限制为一次提示，是因为用户在第一次选择“不允许”并看到结果后可能会改变主意。

如果我们收到有关持续过度提示的报告，我们将进一步限制此 API。

macOS Catalina 上的 Safari 中的 ITP 调试模式

macOS 上的 Safari 13 包含 ITP 调试模式。它在 Safari 技术预览版中已经可用了一段时间，但现在它也在常规 Safari 中可用，以便您可以使用客户使用的相同 Safari 来调试您的网站。

以下是如何使用 ITP 调试模式的分步指南。请注意，菜单位置和命名都已从早期的实验性功能中更改。

如果您更喜欢使用控制台

  1. 启动控制台应用。
  2. 点击操作菜单 → 包含信息消息。
  3. 过滤“ITPDebug”（不含引号）。

如果您更喜欢使用终端

log stream -info | grep ITPDebug

现在您已准备好启用 ITP 调试模式并查看日志输出。

  1. 通过 Safari 偏好设置 → 高级 → “在菜单栏中显示开发菜单”启用开发菜单。
  2. 点击开发菜单中的“智能跟踪预防调试模式”。
  3. 完成后，通过相同的开发菜单项或退出 Safari 来禁用 ITP 调试模式。当您不使用 ITP 调试模式时，请勿将其保持开启状态，因为它会记录您浏览时可能敏感的信息。（日志记录在临时信息（INFO）级别进行。）

启用 ITP 调试模式后，当您浏览网页时，将在日志中看到 ITP 消息。每当 ITP 决定调度网站数据删除时，它将在日志中指示“所有数据”或“除 Cookie 外所有数据”，以告知您是常规删除所有网站数据，还是如上所述新的非 Cookie 网站数据的受限生命周期。

在 ITP 调试模式下，域名 3rdpartytestwebkit.org 被永久分类为具有跟踪能力，因此您至少应该在日志中看到该域名。

分类自定义域以进行测试

借助 ITP 调试模式和用户默认设置，您可以手动将自定义域设置为永久分类为具有跟踪功能。以下是如何为名为 website.example 的域实现此操作：

  1. 打开“系统偏好设置”，点击“安全性与隐私”，并解锁挂锁以进行更改。
  2. 在左侧选择“完整磁盘访问”类别。
  3. 使用 + 按钮将“终端”应用程序添加到列表中，并确保其复选框已选中。
  4. 打开终端并执行以下命令：defaults write com.apple.Safari ITPManualPrevalentResource website.example
  5. 返回“系统偏好设置”中的“安全性与隐私”，并取消勾选“终端”的复选框，以防止其永久获得完整磁盘访问权限。

关于 HttpOnly Cookie 的注意事项

我们关于 ITP 2.1 的博客文章提供了关于如何保护 Cookie 的指导。我们特别鼓励使用 安全和 HttpOnly Cookie。

自发布该帖子以来，我们发现对于 HttpOnly Cookie 一词存在一些困惑，有时被错误地简称为“HTTP Cookie”。有人说任何由服务器设置的 Cookie 都是 HttpOnly Cookie。这是不正确的。服务器需要在 Set-Cookie 响应头中添加 HttpOnly 属性才能使 Cookie 成为 HttpOnly，如下所示：

Set-Cookie: ExampleSessionID=a66e30012cc49846; path=/; HttpOnly

添加 HttpOnly 属性提供了以下两项安全和隐私保护：

  • HttpOnly Cookie 不会暴露给 JavaScript。这意味着网站上的跟踪脚本或跨站脚本攻击无法读取和泄露这些 Cookie 的内容。
  • HttpOnly Cookie 不会复制到 WebKit 的网页内容进程中。这意味着它们不会受到推测执行攻击的影响，否则这些攻击可能会窃取这些 Cookie 的内容。