【Web技术】存储访问策略：阻止跟踪器的cookie

Firefox包含一个新的存储访问策略，可以阻止来自第三方跟踪资源的cookie和其他网站数据。此策略被设计为旧cookie策略的替代方案，旧cookie策略在Firefox中已经存在多年。此策略可防止跨站点跟踪，同时最大限度地减少与传统cookie阻止相关的站点破坏。本文介绍了该策略的工作原理以及如何对其进行测试。

在Firefox中测试

此cookie策略自63版起在Firefox中可用。本文档描述了我们打算向Firefox Release用户提供的策略，但可能与当前版本的Firefox中实现的策略不匹配。这是因为一旦政策的新方面登陆我们的预发布频道Firefox Nightly，我们就会记录下来。Firefox Nightly也可能包含我们尚未计划向Release用户提供的实验功能；实验特性将不包括在本文档中，但可能会影响分类为跟踪器的域的功能。

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

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

报告损坏的网站

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

跟踪保护说明

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

Firefox使用“跟踪保护”列表来确定哪些资源正在跟踪资源。追踪保护列表由Disconnect维护。在Firefox中应用该列表时，我们会进行两个重要更改：

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

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

Hostname on the list	Hostname of resource	Matched
example.com	example.com	Yes
example.com	a.b.example.com	Yes
blah.example.com	example.com	No
a.b.example.com	c.d.example.com	No
blah.example.com	foo.blah.example.com	Yes

存储访问策略阻止什么？

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

Cookie：

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

DOM存储：

• localStorage:Window.localStorage:读取和写入尝试引发SecurityError异常。在Firefox 70之前：Window.localStorage为null。因此，尝试使用此对象进行读写操作将引发TypeError异常。
• sessionStorage：允许进行读取和写入尝试。
• IndexedDB:试图访问IndexedDB工厂对象时引发SecurityError异常。

消息传递和Workers：

 

• 广播频道【Broadcast Channel】：尝试创建新的广播频道将引发SecurityError异常。
• 共享工作者【Shared Worker】：尝试创建新的SharedWorker将引发SecurityError异常。
• 服务工作者【Service Worker】：尝试创建新的服务工作者将引发SecurityError异常。

DOM缓存：

• 对CacheStorage的调用将始终以SecurityError拒绝。

浏览器缓存：

• HTTP缓存、Image缓存和Alternative Services（Alt-Svc）缓存都是为跟踪资源而分区的，因此每个顶级源都将有一个单独的分区，并且不同顶级源上的跟踪资源将被缓存为彼此独立。

网络连接：

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

HTTP引用

• 跨来源时，分类为跟踪器的第三方资源的默认“推荐人策略”设置为严格来源。

政策没有阻止什么？

 

• 此策略当前不限制未分类为跟踪资源的资源的第三方存储访问。我们将来可能会选择对第三方存储访问应用额外的限制。
• 该策略应用的限制不会阻止分类为跟踪资源的第三方脚本访问页面主上下文中的存储。这些脚本可以继续使用作用域为顶级源的存储。
• 当被归类为跟踪器的原始文件在第一方环境中加载时，它们将可以访问自己的存储。
• 从与顶级上下文相同的eTLD+1加载的跨源资源仍然可以访问其存储。
• 如果确定顶级页面来源与通常分类为跟踪器的来源来自同一组织，则不会阻止它们。

存储访问授权

为了提高web兼容性并允许需要存储访问的第三方集成，Firefox将按照本节所述，将存储访问权限授予特定第三方来源的第一方。目前，Firefox包括一些网络兼容性启发法，当用户与第三方交互时，这些启发法允许存储访问被归类为跟踪器的第三方资源。当我们预计不授予访问权限会导致网页破裂时，我们会这样做。我们还支持Storage Access API的初始实现，嵌入式＜iframe＞s可以通过调用Document.requestStorageAccess（）来请求存储访问。尽管这两种方法都提供了相同级别的存储访问，但我们建议第三方改用存储访问API，以保证其对存储的访问。

交互时自动访问存储

为了提高网络兼容性，Firefox目前包括一些启发式方法，可以自动向接收用户交互的第三方授予存储访问权限。这些启发法旨在允许网络上常见的一些第三方集成继续发挥作用。它们是临时的，将在未来版本的Firefox中删除。当前和未来的网络开发不应依赖它们。

当用户手势触发具有对原始文档的开启访问权限的弹出窗口时，可以向已被分类为跟踪资源的资源授予第三方存储访问权限。当这种情况发生时，有三种可能的方式可以授予第三方来源访问权限：

• 如果最初加载在弹出窗口中的资源的来源在过去30天内作为第一方接收到用户交互，则该来源被授予对打开文档的存储访问权限。
• 在弹出窗口中加载初始资源后，该窗口可能会经过一系列重定向到其他主机。如果用户在重定向后与弹出窗口交互，则会向弹出窗口中加载的内容的来源授予对打开文档的存储访问权限。
• 当存在从跟踪原点到非跟踪原点的顶级重定向时，跟踪原点在非跟踪原点和重定向链下游出现的任何其他非跟踪原点上接收短暂的存储访问（即，如果负载继续重定向）。跟踪来源必须在过去30天内作为第一方收到用户交互，并且存储访问权限在15分钟后过期。

存储访问范围

当授予存储访问权时，它的作用域为起始文档的站点或该源的子域。在源的子域上授予的访问权限确实扩展到顶级源。例如，如果tracker.example中的资源被授予在foo.example.com上的存储访问权限，那么tracker.examples将能够访问其在bar.foo.example.com和example.com上的cookie。

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

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

考虑从example.com加载的顶层页面上的以下嵌入场景，其中tracker.example已被授予存储访问权限。

Embedding	tracker.example resource storage access
An image is loaded from tracker.example and embedded in the main context of example.com.	HTTP: Yes JS: N/A
example.com embeds an <iframe> from example.org. That <iframe> goes on to load an image from tracker.example.	HTTP: Yes JS: N/A
example.com embeds an <iframe> from example.org. That <iframe> goes on to embed an <iframe> from tracker.example.	HTTP: Yes JS: No
example.com embeds an <iframe> from tracker.example.	HTTP: Yes JS: Yes
example.com embeds an <iframe> from example.com (same origin). The nested <iframe> embeds an <iframe> from tracker.example.	HTTP: Yes JS: No

存储访问过期

存储访问授权将在30天后过期。被归类为跟踪资源的域可以被授予多个第一方的第三方存储访问权限，并且每个第三方的存储权限独立到期。上述启发式方法还将有助于延长第三方存储许可对已被授予访问权限的源的使用寿命。每次激活试探，或成功调用存储访问API时，预先存在的存储访问期限将延长30天，从上次授予访问权限开始计算。

请注意，我们希望在未来更改存储访问的有效期。如前所述，要知道您今后能够将存储作为第三方使用，请使用storage Access API。

调试

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

开发人员工具通知

Firefox开发工具中的网络监视器现在包括一个指示器，用于所有已分类为跟踪资源的资源请求。该指示器在域列中显示为屏蔽图标。在下面的示例图像中，trackertest.org被归类为跟踪资源，而对example.com的请求则不是。

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

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

1. 在地址栏中键入about:config。如果您看到一个页面，警告您“这可能会使您的保修无效！”，请单击“我承担风险！”
2. 搜索首选项名称“urlclasser.trackingAnnotationTable.testEntries”。
3. 如果首选项已经存在，请编辑首选项值。
4. 如果首选项不存在，请单击“字符串”，然后单击“+”创建新的首选项。
5. 输入逗号分隔的原点作为首选项值，您希望将其分类为跟踪器。例如“example.net，example.org”。

警告：请确保在完成测试后删除这些条目。

常见问题

此cookie策略有可能导致网站崩溃，但其设计目的是允许常见的第三方集成继续工作，同时防止跨网站跟踪。在本节中，我们将描述您在不同集成场景中可以期望的功能。

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

否--此功能仅限制访问可用于跨网站跟踪用户的cookie和网站数据。阻止跟踪标识符并不妨碍广告的显示。

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

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

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

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

这取决于社会融合的实施方式。我们预计，许多流行的社交集成将继续像Firefox当前的cookie政策下那样发挥作用，但用户体验会有一些细微的差异。

当用户首次访问新的第一方时，被归类为跟踪器的社交内容提供商将无法访问其第三方cookie。因此，当用户直接访问提供商的网站时，尽管用户已登录，但用户可能看起来已注销该服务。根据集成类型的不同，在允许社交内容提供商访问他们的cookie之前，用户可能必须采取一些行动与该提供商进行交互。例如

• 对于社交登录，用户可能必须点击第一方的登录按钮。
• 对于社交点赞或共享按钮，用户必须首先在注销状态下与按钮进行交互。一旦他们登录，许多社交内容提供商就会提示他们登录。

在这些交互之后，如果第三方存储访问以上述存储访问激活启发法捕获的方式提示用户，则提供商将接收第三方存储器访问。这些提供商应考虑尽快切换为通过存储访问API明确请求存储访问。此API的初始实现目前在Nightly中可用。

我使用第三方像素和其他工具来衡量我的广告活动的有效性。我还能测量广告的转化率吗？

这取决于第三方如何实施测量工具，但通常广告转化测量会更加困难。考虑以下示例：

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