智能防追踪 2.0

2018 年 6 月 4 日

作者：John Wilander

注意：请阅读有关智能防追踪和存储访问 API 的近期博客文章，了解此技术的改进。

今天，我们很高兴为您带来智能防追踪 2.0 (ITP 2.0)。它建立在我们去年发布的 ITP 1.0 和三月份发布的 ITP 1.1 之上，并新增了存储访问 API。

移除 24 小时 Cookie 访问窗口

与早期版本不同，ITP 2.0 会立即对被认定具有追踪能力的域进行 Cookie 分区。之前用户交互后 24 小时的一般 Cookie 访问窗口已被移除。取而代之的是，经过身份验证的嵌入式内容可以通过存储访问 API 访问其第一方 Cookie。该 API 要求用户与嵌入式内容进行交互。

0 days: Cookies are partitioned and not persisted in 3rd-part contexts. | 30 days: Existing cookies are purged. New cookies are blocked. | Days of use after the most recent interaction with the website or successful use of the Store Access API.

示例

video.example 提供无广告订阅服务，并在其他网站上嵌入了许多视频。ITP 将 video.example 归类为具有追踪能力，因此对其 Cookie 进行分区。以下是 ITP 如何作用于 video.example 的时间线：

第 1 天：用户登录 video.example，这会更新 video.example 的用户交互时间戳。
第 22 天：用户点击在 news.example 上观看 video.example 剪辑，嵌入式视频调用存储访问 API。ITP 注意到用户之前没有在 news.example 上授予 video.example 访问其第一方 Cookie 的权限，因此会提示用户。用户授予存储访问权限，并且 video.example 的用户交互时间戳得到更新。
第 26 天：用户点击在 news.example 上观看另一个 video.example 剪辑，video.example 嵌入式内容调用存储访问 API。ITP 注意到用户之前已在 news.example 上授予 video.example 访问其第一方 Cookie 的权限，因此无需提示即可提供访问权限，并更新 video.example 的用户交互时间戳。
第 55 天：用户以第一方网站的形式与 video.example 交互，这会更新 video.example 的用户交互时间戳。
第 76 天：用户点击在 blog.example 上观看 video.example 剪辑，video.example 嵌入式内容调用存储访问 API。ITP 注意到用户之前没有在 blog.example 上授予 video.example 访问其第一方 Cookie 的权限，因此会提示用户。用户授予存储访问权限，并且 video.example 的用户交互时间戳得到更新。
第 80-82 天：用户未使用 Safari，这意味着这三天不计入网站数据清除前的 30 天。
第 109 天：由于 Safari 使用了 30 天但 video.example 的用户交互时间戳未更新，video.example 的 Cookie、网站数据和已授予的存储访问条目被清除。

开发者建议

如果您是经过身份验证的第三方内容的提供商，您应该采用存储访问 API。如果您的网站依赖第三方域进行用户身份验证，您的身份验证提供商应该采用存储访问 API 或通过 URL 将身份验证令牌传输给您。

存储访问 API 的用户提示

ITP 2.0 在 WebKit 对存储访问 API 的实现中添加了一个提示。如果用户允许访问，他们的选择将被持久化。如果用户拒绝，他们的选择不会被持久化，这使得他们可以在稍后点击调用存储访问 API 的类似嵌入式小部件时改变主意。

例如，video.example 可能提供无广告订阅服务，并在其他网站上嵌入了许多视频。因此，ITP 会将 video.example 归类为具有追踪能力并对其 Cookie 进行分区。当用户轻触或点击在 news.example 上播放剪辑时，video.example 可以调用存储访问 API 来检查用户是否是订阅者。如果用户之前没有在 news.example 下明确允许访问，则会提示用户。

Storage Access API prompt — 存储访问 API 提示

此提示为用户提供了一种方式来表明意图（轻触/点击启用 API 调用）并提供同意（提示中的“允许”）。如果用户选择“允许”，他们的选择将被持久化，随后 video.example 嵌入式内容在 news.example 上对存储访问 API 的调用将不再触发提示。相反，轻触或点击嵌入式内容就足以成功调用 API。一如既往，ITP 将 eTLD+1 视为“方”，因此用户在 sub.news.example 下对 sub.video.example 的“允许”将对 video.example 及其在 news.example 或其任何子域下的任何子域都有效。

成功使用存储访问 API 现在计为与第三方的用户交互，并在 ITP 清除第三方网站数据之前刷新 30 天的使用期限。通过成功使用，我们指的是用户要么立即被提示并选择了“允许”，要么之前已经选择了“允许”。成功调用存储访问 API 现在计为用户交互这一事实，使得用户可以保持登录那些他们很少作为第一方使用但作为嵌入式第三方继续使用的服务。

最后，我们收到了开发者的反馈（谢谢），他们表示应该可以在授予存储访问权限但用户未登录的情况下弹出一个窗口。我们原始版本的存储访问 API 会消耗用户手势，因此需要另一次轻触或点击才能弹出登录窗口。现在，第三方嵌入式内容可以在返回的 Promise 的解析范围内执行弹出操作，如下所示：

<script>
function makeRequestWithUserGesture() {
  var promise = document.requestStorageAccess();
  promise.then(
    function () {
      // Storage access was granted.
      // Check whether the user is logged in.
      // If not, do a popup to log the user in.
    },
    function () {
      // Storage access was denied.
    }
  );
}
</script>
<button onclick="makeRequestWithUserGesture()">Play video</button>

开发者建议

如果您提供经过身份验证的嵌入式内容，我们鼓励您采用存储访问 API。如果 ITP 已将您的域归类为具有追踪用户能力，API 的提示会为您提供一种方式来延长用户的身份验证会话。如果 ITP 对您的域进行分类而您不采用该 API，您的域将被永久阻止在第三方上下文中访问其第一方 Cookie。

临时兼容性修复：弹出窗口的自动存储访问

许多联合登录通过 URL 或 postMessage API 发送身份验证令牌，这两种方式在 ITP 2.0 下都能正常工作。然而，一些联合登录使用弹出窗口，并在用户返回打开页面后依赖第三方 Cookie 访问。后一类的一些实例在 ITP 2.0 下停止工作，因为具有追踪能力的域被永久分区。

我们的临时兼容性修复是检测此类弹出场景，并自动为打开页面下的第三方转发存储访问权限。由于弹出窗口需要用户交互，第三方也可以直接调用存储访问 API。

开发者建议

如果您提供联合登录服务，我们鼓励您首先调用存储访问 API 以获取 Cookie 访问权限，然后才弹出窗口以登录用户或获取特定同意。存储访问 API 提供更好的用户体验，无需新窗口和导航。我们还要强调，弹出窗口的兼容性修复是临时的。从长远来看，您唯一的选择是调用存储访问 API。

防止第一方跳转追踪器

ITP 2.0 能够检测域何时仅用作“第一方跳转追踪器”，这意味着它从不作为第三方内容提供商使用，而是纯粹通过导航重定向来追踪用户。

假设用户在 social.example 网站上点击了一个 news.example 链接。他们不是直接导航到目的地 news.example，而是在到达 news.example 之前快速导航通过 trackerOne.example 和 trackerTwo.example。这两个追踪域可以在第一方存储和 Cookie 中存储有关用户浏览历史的信息。ITP 2.0 会检测此类追踪行为，并将这些域像任何其他追踪器一样对待，即清除它们的网站数据。

First-party cookie bounce diagram

防止追踪器串通

通过我们的研究，我们发现跨站追踪器会互相帮助识别用户。这基本上是一个追踪器告诉另一个追踪器“我认为是用户 ABC”，此时第二个追踪器告诉第三个追踪器“嘿，追踪器一认为这是用户 ABC，而我认为这是用户 XYZ”。我们称之为追踪器串通，ITP 2.0 通过串通图检测此行为，并将所有相关方归类为追踪器。

Cross-site tracker collusion diagram

在上图中，一旦 trackerSix.example 被 ITP 分类，所有重定向到 trackerSix.example 的域也会被分类。这就是 trackerTwo.example、trackerThree.example 和 trackerFive.example。然后，重定向到这些域的域也会被分类，这涵盖了最后两个——trackerOne.example 和 trackerFour.example。

开发者建议

避免不必要地重定向到可能被分类为具有追踪能力的域。

无用户交互域的仅源引用者

ITP 清除网站数据并不能阻止追踪器接收所谓的引用者标头，该标头会泄露用户当前所在的网页。在 ITP 2.0 中，对于 ITP 已分类为可能追踪器且未收到用户交互的域的第三方请求，如果存在引用者，则会将其降级为仅包含页面的源。

以下是我们的意思：假设用户访问 https://store.example/baby-products/strollers/deluxe-navy-blue.html，并且该页面加载了来自 trackerOne.example 的资源。在 ITP 2.0 之前，对 trackerOne.example 的请求将包含完整的引用者“https://store.example/baby/strollers/deluxe-stroller-navy-blue.html”，这向第三方透露了许多关于用户的信息。有了 ITP 2.0，引用者将缩减为“https://store.example/”。

有关此主题的更多阅读，请参阅 Mozilla 关于仅源引用者的研究。

常见问题

ITP 会区分我的子域吗？
不会。ITP 收集有效顶级域加一（或称 eTLD+1）的统计数据并应用其规则。eTLD 是 .com 或 .co.uk，因此 eTLD+1 的一个例子是 social.co.uk，而不是 sub.social.co.uk (eTLD+2) 或仅仅是 co.uk (eTLD)。

eTLD 是指公共后缀吗？
是的。请参阅公共后缀列表。

用户有什么办法可以将我的域列入白名单，使其不受 ITP 规则的限制吗？
没有，没有这样的白名单功能。

ITP 如何对域的追踪能力进行分类？
有关机器学习模型的详细信息，请参阅原始的 ITP 1.0 博客文章。

我的域名不是追踪器，但却被 ITP 分类了。这是个 bug 吗？
ITP 不依赖于已知的追踪器集中黑名单。相反，它在设备上捕获每个域（eTLD+1）的统计数据，并对每个域进行跨站追踪能力的分类。如果一个域具有跨站追踪用户的功能，它就会受到 ITP 的 Cookie 和网站数据规则的约束。

如果我的域被 ITP 分类，用户仅仅访问我的网站就足以防止其 Cookie 被清除吗？
不是，仅仅访问是不够的。用户必须与您的网站交互，这意味着点击、轻触或填写表单。在 ITP 2.0 中，用户通过存储访问 API 授予的访问权限也算作此类用户交互。

如何重置 ITP 或我已允许存储访问的域？
清除您的 Safari 历史记录。请注意，这会清除可能需要重现 ITP 问题的数据。如果您正在调查与 ITP 相关的 bug，请在完成工作之前不要清除历史记录。

我需要调试我的网站与 ITP 相关的问题。有专门的开发者工具吗？
我们正在开发 ITP 调试模式，它将帮助您调试网站并捕获在提交 ITP 错误时有用的数据。它现在作为 Safari Technology Preview 62 版中的一个实验性功能提供。您可以在博客文章“Safari Technology Preview 62 中的 ITP 调试模式”中了解更多关于使用此开发者工具的信息。

什么是经过身份验证的小部件、经过身份验证的嵌入式内容或经过身份验证的第三方内容？
Web 平台允许网站之间进行强大的集成。这使得社交媒体等服务能够创建小部件，作为第三方内容嵌入到新闻网站和博客中，但这也同时带来了跨站追踪的可能性。有些小部件需要用户登录才能正常工作。例如，如果用户想用他们的 social.example 账户在 blog.example 上评论，social.example 评论小部件需要看到用户已登录他们的服务。我们将这些小部件称为经过身份验证的小部件，为了在禁用跨站追踪的同时启用它们，这些小部件现在必须按网站请求查看用户身份的权限。

移除 24 小时 Cookie 访问窗口如何阻止社交媒体等进行跨站追踪？
ITP 1.0 有一个 24 小时窗口，在此期间，用户与之交互的网站可以像 Safari 的早期版本一样使用它们的 Cookie。这是我们采取的一项兼容性措施，旨在启用联合登录（例如使用 social.example 登录 news.example）和经过身份验证的第三方内容（例如使用 social.example 在 blog.example 上发表评论）。然而，这也允许用户作为第一方与之交互的社交媒体和搜索引擎在 24 小时窗口内跨网站追踪用户。这些服务仅仅存在第三方内容就足以让它们看到用户访问了哪些网页。例如，如果用户使用了 social.example，然后几小时后访问了 news.example（该网站嵌入了 social.example 的“赞”按钮或评论小部件），social.example 就可以追踪他们在 news.example 上的浏览活动。在 ITP 2.0 中，我们限制此类第三方内容只能在用户实际使用内容时（例如撰写评论或播放视频）识别用户。这也是 Safari 会询问用户权限的时间点（如果小部件请求查看其 Cookie 的权限）。

反馈和 Bug 报告

请通过 bugs.webkit.org 报告 Bug，并将反馈发送给我们的布道者 Jon Davis。如果您对该功能的工作原理有技术问题，可以在 Twitter @johnwilander 上找到我。