存储访问策略：阻止来自跟踪器的 Cookie

在 Firefox 中测试

此 Cookie 策略自 Firefox 63 版本起已可用。本文档描述了我们计划向 Firefox Release 用户发布策略，但可能与当前 Firefox Release 版本中实现的不符。这是因为我们会在策略的新方面一经发布到我们的预发布渠道 Firefox Nightly，就立即进行文档记录。Firefox Nightly 还可能包含我们尚未计划向 Release 用户发布的功能；实验性功能将不包含在本文档中，但仍可能影响被归类为跟踪器的域的功能。

我们建议网站使用 Firefox Nightly 进行测试，因为它包含了我们最新版本的保护功能。如上所述，请注意 Nightly 可能包含最终会在发布给我们的 Release 用户之前被删除或更改的额外保护功能。随着我们加强保护功能，我们将不断更新此页面，提供最新信息。

这些保护措施在 Nightly 中默认启用。Cookie 策略可以通过 内容阻止设置 在其他版本的 Firefox 中启用（这些步骤因版本而异；链接文档包含一个下拉菜单，用于选择合适的 Firefox 版本）。

报告损坏的网站

如果您发现网站因本次更改而损坏，请在 Bugzilla 中的 Firefox 产品下的跟踪保护组件中提交一个错误。或者，您也可以通过点击 控制中心 的内容阻止部分中的“报告问题”来直接在 Firefox 中报告损坏的网站（此快捷方式可能并非在所有版本的 Firefox 中都可用）。

跟踪保护说明

Firefox 如何确定哪些资源是跟踪资源？

Firefox 使用跟踪保护列表来确定哪些资源是跟踪资源。跟踪保护列表由 Disconnect 维护。当该列表应用于 Firefox 时，我们进行了两项重要更改：

• 首先，我们只使用列表的“基本保护”版本，其中 排除了某些类别的跟踪器。将来，我们可能会扩展我们的保护范围，以使用列表的“严格保护”版本。
• 其次，Firefox 使用一个额外的“实体列表”，该列表 阻止域在其与同一组织拥有的顶级网站一起加载时被归类为跟踪器。

Firefox 使用内置的 跟踪保护 URL 分类器来确定哪些资源与跟踪保护列表匹配。域根据 SafeBrowsing v4 规范 与列表进行匹配。具体来说，我们根据列表检查资源的精确主机名，以及从最后五个组件开始并连续移除前导组件形成的最后四个主机名。考虑以下示例：

存储访问策略会阻止什么？

存储访问策略阻止被识别为跟踪器的资源在第三方上下文中访问 第三方 Cookie 和其他网站存储。这可以防止这些资源检索跟踪标识符并使用它们在多次访问多个第一方时识别用户。具体来说，Firefox 通过施加以下限制来实现此目的：

Cookie

• 阻止 Cookie 请求头并忽略 Set-Cookie 响应头。
• 对 Document.cookie 的调用返回一个空字符串，并忽略通过 Document.cookie 设置 Cookie 的请求。

DOM 存储

• localStorage: Window.localStorage: 读写尝试抛出 SecurityError 异常。在 Firefox 70 之前：Window.localStorage 为 null。因此，使用此对象进行读写尝试将抛出 TypeError 异常。
• sessionStorage: 允许读写尝试。
• IndexedDB: 尝试访问 IndexedDB 工厂对象会抛出 SecurityError 异常。

消息传递和 Worker

• Broadcast Channel: 尝试创建新的 BroadcastChannel 将抛出 SecurityError 异常。
• Shared Worker: 尝试创建新的 SharedWorker 将抛出 SecurityError 异常。
• Service Worker: 尝试创建新的 ServiceWorker 将抛出 SecurityError 异常。

DOM 缓存

• 对 CacheStorage 的调用将始终因 SecurityError 而被拒绝。

浏览器缓存

• HTTP 缓存、图片缓存和 替代服务 (Alt-Svc) 缓存 都为跟踪资源进行了分区，以便每个顶级源都将有一个独立的分区，并且不同顶级源上的跟踪资源将彼此独立缓存。

网络连接

• 当向被归类为跟踪器的嵌入式第三方资源建立 HTTPS 连接时，不会使用会话票证恢复 TLS 会话。
• 被归类为跟踪器的域的 HTTP 连接重用 仅限于在同一顶级源下发生的请求。例如，来自 news.example 上 tracker.example 的内容请求不会与来自 shopping.example 上 tracker.example 的内容请求或当 tracker.example 被直接访问时（即作为第一方）发生的请求重用 HTTP 连接。

HTTP 引用者

• 被归类为跟踪器的第三方资源的默认 Referrer Policy 设置为 strict-origin-when-cross-origin。

该策略没有阻止什么？

1. 此策略目前不限制未归类为跟踪资源的第三方存储访问。将来，我们可能会对第三方存储访问施加额外的限制。
2. 该策略施加的限制不会阻止归类为跟踪资源的第三方脚本访问页面主上下文中的存储。这些脚本可以继续使用限定于顶级源的存储。
3. 当以第一方上下文加载时，被归类为跟踪器的源将有权访问其自己的存储。
4. 从与顶级上下文相同的 eTLD+1 加载的跨源资源仍将有权访问其存储。
5. 通常被归类为跟踪器的源将 不会被阻止，如果顶级页面源被确定为与它们来自同一组织。

存储访问授权

为了提高网络兼容性并允许需要存储访问的第三方集成，Firefox 将授予特定第三方源的存储访问权限，该权限限定于第一方，如本节所述。目前，Firefox 包含一些网络兼容性启发式算法，当用户与这些第三方交互时，这些算法会授予被归类为跟踪器的第三方资源存储访问权限。我们这样做是因为我们预计不授予访问权限会导致网页损坏。我们还支持 Storage Access API 的初始实现，通过该 API，嵌入式 <iframe> 可以通过调用 Document.requestStorageAccess() 请求存储访问权限。尽管这两种方法都提供相同级别的存储访问权限，但我们建议第三方切换到使用 Storage Access API，以保证它们对存储的访问权限。

交互时自动存储访问

为了提高网络兼容性，Firefox 目前包含一些启发式算法，可在用户与第三方交互时自动授予其存储访问权限。这些启发式算法旨在允许一些常见的第三方集成继续正常运行。它们旨在作为临时措施，并将在 Firefox 的未来版本中移除。不应依赖它们进行当前和未来的网络开发。

当用户手势触发具有对原始文档的 opener 访问权限 的弹出窗口时，可能会授予第三方存储访问权限。如果用户与弹出窗口交互，则如果该源在过去 30 天内作为第一方接收过用户交互，则弹出窗口中最初加载的资源的源将获得对 opener 文档的存储访问权限。

当用户在同一窗口中导航到另一个源时，也可能授予第三方存储访问权限。如果用户与该源交互，然后快速导航到初始源中的文档，则中间页面将获得对该最终文档的存储访问权限。

存储访问范围

授予存储访问权限时，它会限定于 opener 文档的站点或该源的子域。在源的子域上授予的访问权限会扩展到顶级源。例如，如果来自 tracker.example 的资源在 foo.example.com 上获得存储访问权限，那么 tracker.example 将能够访问其在 bar.foo.example.com 和 example.com 上的 Cookie。

当 tracker.example 在 example.com 上获得存储访问权限时，从 example.com 加载的任何顶级文档上从 tracker.example 加载的所有资源将立即获得存储访问权限。这包括在页面主上下文中加载的所有资源、嵌入式 <iframe> 以及在嵌入式 <iframe> 中加载的资源。存储访问权限不会扩展到 example.com 上加载的其他资源（例如，other-tracker.example），也不会扩展到嵌入 tracker.example 的其他第一方（例如，example.org）。

存储访问权限扩展到第一层嵌套上下文，但不进一步。这意味着嵌入在页面主上下文中并从被归类为跟踪器的域加载的 <iframe> 将完全访问所有可通过 JavaScript 访问的存储位置。类似地，对嵌入在页面主上下文中并加载的 <iframe> 中的资源的请求将有权访问 HTTP Cookie。但是，更深层的嵌套上下文，包括但不限于来自被归类为跟踪器的源的上下文，将不被授予存储访问权限。

考虑在从 example.com 加载的顶级页面上以下嵌入场景，其中 tracker.example 已获得存储访问权限。

存储访问过期

存储访问授权在 30 天后过期。被归类为跟踪资源的域可能会在多个第一方上被授予第三方存储访问权限，并且每个方的存储权限独立过期。上述启发式算法还将延长已获得访问权限的源的第三方存储权限的生命周期。每次激活启发式算法或成功调用 Storage Access API 时，现有的存储访问过期时间将从上次授予访问权限的时间起延长 30 天。

请注意，将来我们预计会更改存储访问的有效期。如前所述，了解您将来如何以第三方身份使用存储的方法是使用 Storage Access API。

调试

我们鼓励网站所有者测试他们的网站，特别是那些依赖第三方内容集成的网站。我们已在 Firefox 中添加了几项新功能，使测试更轻松。

开发者工具通知

Firefox 开发者工具中的 网络监控器 现在包含一个指示器，用于所有被归类为跟踪资源的请求。此指示器在域列中显示为盾牌图标。在下面的示例图片中，trackertest.org 被归类为跟踪资源，而对 example.com 的请求则不是。

将自定义域添加到跟踪保护列表

想知道如果您的网站上的第三方域被归类为跟踪器，事情会如何发展吗？我们添加了一个首选项，允许您将自定义域添加到跟踪保护 URL 分类器。要执行此操作：

1. 在地址栏中输入 about:config。如果出现警告页面“这可能会使您的保修失效！”，请点击“我接受风险！”。
2. 搜索首选项名称“urlclassifier.trackingAnnotationTable.testEntries”。
3. 如果首选项已存在，请编辑首选项值。
4. 如果首选项不存在，请点击“字符串”，然后点击“+”创建一个新首选项。
5. 对于首选项值，输入您希望被归类为跟踪器的以逗号分隔的源。例如，“example.net,example.org”。

常见问题解答

此 Cookie 策略可能会导致网站损坏，但其设计旨在允许常见的第三方集成继续工作，同时防止跨网站跟踪。在本节中，我们描述了在不同集成场景中您可以预期的功能。

此存储访问策略会阻止广告显示在我的网站上吗？

不会 — 此功能仅限制对可用于在网站之间跟踪用户的 Cookie 和网站数据的访问。阻止跟踪标识符不会阻止广告的显示。

我使用被归类为跟踪器的第三方分析服务。我还会收到分析数据吗？

这取决于第三方分析服务的实现方式。第三方分析提供商将无法再使用其第三方存储来收集数据。这意味着使用限定于其第三方域的 Cookie 或存储在其源下的本地存储和其他网站数据的提供商将无法再访问其他网站上的这些标识符。

如果这些服务嵌入在页面的主上下文中，它们可以继续使用第一方 Cookie 和网站存储来跟踪用户在该特定第一方域上的页面访问。

我使用第三方服务进行社交登录、点赞和分享按钮集成。我的用户还能使用这些服务吗？

这取决于社交集成的实现方式。我们预计许多流行的社交集成将继续像在 Firefox 当前的 Cookie 策略下那样运行，但用户体验会有些微差异。

当用户首次访问新的第一方时，被归类为跟踪器的社交内容提供商将无法访问其第三方 Cookie。因此，尽管用户在直接访问提供商网站时已登录，但在服务看来，用户可能处于未登录状态。根据集成类型，用户可能需要采取一些操作才能与社交内容提供商交互，然后提供商才能访问其 Cookie。例如：

• 对于社交登录，用户可能必须点击第一方上的登录按钮。
• 对于社交点赞或分享按钮，用户必须首先在未登录状态下与按钮交互。一旦他们这样做，许多社交内容提供商会提示他们登录。

在这些交互之后，如果提供商以被上述存储访问激活启发式算法捕获的方式提示用户，他们将获得第三方存储访问权限。这些提供商应考虑尽快切换到通过 Storage Access API 明确请求存储访问。此 API 的 初始实现 目前已在 Nightly 中可用。

我使用第三方像素和其他工具来衡量广告系列的效果。我还能衡量广告的转化率吗？

这取决于第三方如何实现衡量工具，但一般来说，广告转化衡量将更加困难。考虑以下示例：

1. 您在社交媒体网站上投放了一则广告，用户多次看到，但从未点击。该用户随后访问您的网站，其中包括来自同一社交媒体网站的转化跟踪标签。这种类型的转化通常被称为“浏览型转化”。由于社交媒体网站无法访问其第三方存储，他们将无法识别该用户是同一位在他们网站上看到广告的用户，因此转化将不会被跟踪。我们预计大多数浏览型转化跟踪技术将不再有效，包括展示网络提供的技术。
2. 您在展示网络或社交媒体网站上投放了一则广告，用户点击了该广告。该用户访问了您的网站，其中包括来自显示您广告的同一网站的转化跟踪标签。这种类型的转化通常被称为“点击型转化”。由于社交媒体网站或展示网络无法访问其第三方存储，他们将无法识别该用户是同一位在他们网站上看到广告的用户，因此转化将不会被跟踪。我们预计这种版本的点击型转化将不再有效。
3. 您在社交媒体网站上投放了一则广告。用户点击您的广告并被带到包含来自第三方网络的转化跟踪标签的落地页。在社交媒体网站上，网络通过查询参数标注广告落地页 URL，该参数表明访问是点击广告的结果。在您的网站上，展示网络的标签检查 URL 查询参数并将任何广告跟踪参数保存到第一方存储。如果用户稍后完成转化事件，网络的标签会检查第一方存储以确定哪个点击（或哪些点击）导致了访问。我们预计以这种方式实现的点击型转化将继续有效。