Mozilla Hacks

介绍状态分区

头像照片 作者 Johann Hofmann，Tim Huang

发表于 2021 年 2 月 23 日 分类于 精选文章 和 Firefox

状态分区是 Firefox 中一项新隐私功能的术语，称为“全面 Cookie 保护”，它将在 Firefox 86 中的 ETP 严格模式下提供。本文展示了状态分区在 Firefox 中的工作原理，并解释了第三方集成开发人员如何与最新更改保持兼容。

网站利用各种不同的 API 在浏览器中存储数据。最著名的是 Cookie，它们通常用于构建登录会话并提供个性化的用户体验。我们将这些 API 称为有状态 API，因为它们能够建立在重新加载、导航和浏览器重启中持续存在的状态。虽然这些 API 允许开发人员丰富用户的网络体验，但它们也能够实现恶意的网络跟踪，从而危及用户隐私。为了对抗这些 API 的滥用，Mozilla 在 Firefox 86 中引入了状态分区。

Firefox 中的有状态 Web API 是

  • 存储：Cookie、本地存储、会话存储、缓存存储和 IndexedDB
  • 工作线程：SharedWorkers 和 ServiceWorkers
  • 通信通道：广播通道

为了对抗网络跟踪，Firefox 目前依赖于 增强型跟踪保护 (ETP)，它根据 Disconnect 列表 阻止来自已知跟踪器的 Cookie 和其他共享状态。这种形式的 Cookie 阻止是阻止跟踪的有效方法，但它也有局限性。ETP 保护用户免受 3000 个最常见和普遍识别的跟踪器的侵害，但它的保护依赖于列表的完整性和始终保持最新。确保完整性很困难，跟踪器可以尝试通过注册新的域名来规避列表。此外，识别跟踪器是一项耗时的任务，通常需要数月时间才能将新的跟踪域添加到列表中。

为了解决 ETP 的局限性并提供对跟踪器的全面保护，我们引入了一种称为状态分区的技术，它将防止基于 Cookie 的跟踪普遍发生，而无需列表。

状态分区得到了我们努力消除非传统存储机制（“超级 Cookie”）作为跟踪向量的使用，例如 通过网络状态分区，最近在 Firefox 85 中推出。

状态分区 - 它在 Firefox 中如何工作

为了解释状态分区，我们首先应该看看有状态 Web API 如何在网络上实现跟踪。虽然这些 API 不是为跟踪而设计的，但它们的状态与网站共享，无论它是作为第一方加载还是作为第三方嵌入，例如在 iframe 中或作为简单的图像（“跟踪像素”）。这种共享状态允许嵌入在其他网站中的跟踪器跨网络跟踪你，最常见的方法是设置 Cookie。

例如，如果 foo.com 和 bar.com 都将 www.tracker.com 作为第三方嵌入，则 www.tracker.com 的 Cookie 将在 foo.com 和 bar.com 上共享。因此，www.tracker.com 可以通过使用 Cookie 作为标识符来连接你在这两个网站上的活动。

ETP 将通过简单地阻止对嵌入的 www.tracker.com 实例的共享状态的访问来防止这种情况。没有设置 Cookie 的能力，跟踪器就无法轻松地重新识别你。

未经保护的基于 Cookie 的跟踪，www.tracker.com 的两个实例共享相同的 Cookie。

 

相比之下，状态分区也将防止共享的第三方状态，但它不会完全阻止 Cookie 访问。使用状态分区，共享状态（如 Cookie、localStorage 等）将按你正在访问的顶级网站进行分区（隔离）。换句话说，每个第一方及其嵌入的第三方上下文将被放入一个独立的桶中。

Firefox 使用双重键控来实现状态分区，这将在访问这些状态的网站来源中添加一个额外的键。我们使用方案和 可注册域（也称为 eTLD+1）作为顶级网站的额外键。按照上述示例，www.tracker.com 的 Cookie 将在 foo.com 和 bar.com 下使用不同的键控。存储分区不会查找 www.tracker.com 的 Cookie 存储，而是分别使用 www.tracker.com^http://foo.com 和 www.tracker.com^http://bar.com。

通过双重键控 www.tracker.com 的两个实例来防止状态分区阻止基于 Cookie 的跟踪。

 

因此，在这两个顶级网站下，www.tracker.com 将有两个不同的 Cookie 存储。

这消除了跟踪器使用 Cookie 和以前共享的状态来识别跨网站的个人用户的可能性。现在，状态是分开的（“分区”），而不是跨不同的第一方域共享。

重要的是要了解状态分区将应用于每个嵌入的第三方资源，无论它是否是跟踪器。

这为隐私带来了巨大的好处，使我们能够将保护扩展到 Disconnect 列表之外，并允许嵌入的网站继续像往常一样使用它们的 Cookie 和存储，只要它们不需要跨站点访问。在下一节中，我们将检查嵌入的网站在确实需要跨站点共享状态时可以做什么。

状态分区 - 网络兼容性

鉴于状态分区对 Firefox 带来了根本性的改变，确保网络兼容性和用户和开发人员不间断的体验是首要关注的问题。不可避免地，状态分区会通过阻止第三方状态的合法使用来破坏网站。例如，单点登录 (SSO) 服务依赖于第三方 Cookie 在多个网站上登录用户。状态分区将破坏 SSO，因为 SSO 提供者将无法访问其第一方状态，因为它嵌入在另一个顶级网站中，因此无法识别已登录的用户。

由状态分区分区的第三方 SSO Cookie，SSO iframe 无法获取第一方 Cookie 访问权限。

 

为了解决状态分区的这些兼容性问题，我们允许在某些情况下取消分区状态。当取消分区生效时，我们将停止使用双重键控并恢复普通的（第一方）键。

考虑到上述示例，在取消分区后，顶级 SSO 网站和嵌入的 SSO 服务的 iframe 将开始使用相同的存储键，这意味着它们将访问相同的 Cookie 存储。因此，iframe 可以通过第三方 Cookie 获取登录凭据。

SSO 网站已取消分区，SSO iframe 获取了第一方 Cookie 访问权限。

 

状态分区 - 获取跨站点 Cookie 访问权限

Firefox 可能会在两种情况下取消分区网站的状态，以允许访问第一方（跨站点）Cookie 和其他状态

  1. 当嵌入的 iframe 调用存储访问 API 时。
  2. 根据一组自动启发式算法。

存储访问 API

存储访问 API 是一个新提出的 JavaScript API，用于处理现代浏览器中隐私保护的合法例外情况，例如 Firefox 中的 ETP 或 Safari 中的智能跟踪防止。它允许受限的第三方上下文为自己请求第一方存储访问权限（访问 Cookie 和其他共享状态）。在某些情况下，浏览器会显示一个权限提示，让你决定是否信任第三方以允许此访问权限。

存储访问 API 的 Firefox 用户提示。

 

已分区的第三方上下文可以使用存储访问 API 获取存储权限，该权限授予对其实方状态的取消分区访问权限。

此功能通过 document.requestStorageAccess 方法表达。另一种方法，document.hasStorageAccess，可用于找出当前浏览上下文是否可以访问其实方存储。如 MDN 所述，document.requestStorage 受到许多限制，这些限制是标准化的以及 浏览器特定的，可以保护用户免受滥用。开发人员应该注意这些限制，并相应地调整他们网站的用户体验。

例如，Zendesk 将显示一条消息，其中包含一个操作元素，用于处理 瞬时用户激活 (例如，单击按钮) 的标准要求。在 Safari 中，它还会弹出一个窗口，用户必须激活该窗口才能确保满足 Webkit 的浏览器特定要求。

Zendesk 通知，允许用户触发存储访问请求。

 

用户授予访问权限后，Firefox 将记住存储权限 30 天。

请注意，第三方上下文仅在已请求存储访问权限的顶级域下才不会被分区。对于其他顶级域，第三方上下文仍然会被分区。假设有一个跨域 iframe example.com 嵌入在 foo.com 中。example.com 使用存储访问 API 请求 foo.com 上的一方访问权限，并且用户允许它。在这种情况下，example.com 将对 foo.com 上自己的第一方 Cookie 进行无分区访问。稍后，用户加载另一个页面 bar.com，该页面也嵌入 example.com。但是，这一次，example.com 将在 bar.com 下保持分区状态，因为这里没有存储权限。

document.hasStorageAccess().then(hasAccess => {
if (!hasAccess) {
return document.requestStorageAccess();
}
}).then(_ => {
// 现在我们拥有未来 30 天的无分区存储访问权限！
//
// …
}).catch(_ => {
// 获取存储访问权限出错。
});

使用存储访问 API 从用户获取存储访问权限的 Javascript 示例。

目前，Safari、Edge 和 Firefox 支持存储访问 API。它在 Chrome 中处于功能标志后面。

通过启发式算法自动取消分区

在 Firefox 存储访问策略 中，我们定义了若干启发式算法来解决 Web 兼容性问题。这些启发式算法旨在捕获在 Web 上使用第三方存储的最常见情况（跟踪之外），并允许存储访问，以便网站能够正常运行。例如，在单点登录流程中，通常会打开一个弹出窗口，允许用户登录，并将该登录信息传回打开弹出窗口的网站。Firefox 会检测到这种情况并自动授予存储访问权限。

请注意，这些启发式算法并非为长期使用而设计的。对于需要无分区访问权限的网站，建议使用存储访问 API。我们将持续评估限制的必要性，并在适当情况下予以消除。因此，开发人员现在或将来不应依赖它们。

状态分区 - 用户控制跨站点 Cookie 访问

我们引入了状态分区的新 UI，使用户能够了解哪些第三方已获得无分区存储，并提供对存储访问的细粒度控制。Firefox 将在站点标识面板的权限部分显示无分区域。“跨站点 Cookie”权限表示无分区域，用户可以通过单击权限条目旁的取消按钮直接从 UI 中删除该权限。

关于 Johann Hofmann

Firefox 安全与隐私工程师

Johann Hofmann 的更多文章…

关于 Tim Huang

Firefox 隐私工程师

Tim Huang 的更多文章…

12 条评论

  1. Fazal Majid

    其他形式的状态（如缓存（字体和收藏夹图标）、HSTS、ETag 和其他有状态机制）会如何？这些机制可能会被滥用于跟踪。

    2021 年 2 月 23 日 下午 07:18

  2. Graham Perrin

    一致性：https://mdn.org.cn/en-US/docs/Mozilla/Firefox/Privacy/State_Partitioning#dynamic_state_partitioning 导致“动态分区”。

    它不应该导致“动态状态分区”吗？

    2021 年 2 月 23 日 下午 11:58

  3. voracity

    这看起来不错，但是 30 天的有效期不会使 SSO 在实践中无法使用吗？或者也许我错过了一些方法，比如在有效期时将无分区数据复制到两个分区（似乎不太可能），或者能够在授予无分区访问权限时指定 Cookie/状态进入无分区空间还是分区空间，这样，当发生“伟大分区”时，关键 Cookie 不会受到影响？

    2021 年 2 月 24 日 上午 04:21

  4. Bill Wadley

    与以往一样，Firefox 在保持网络安全方面领先一步。

    谢谢！

    2021 年 2 月 24 日 上午 10:26

  5. Ronald Scott

    这是否会破坏跨域表单 POST 操作中的 Cookie 发送，从而破坏整个世界中所有联合 SAML 实现？

    2021 年 2 月 24 日 上午 10:49

  6. gwarser

    有没有办法立即禁用“Web 兼容性启发式算法”？

    2021 年 2 月 25 日 下午 14:31

  7. antistress

    您好，感谢您的文章。请解释一下最新 Total Cookie Protection 和之前的 First-Party Isolation 之间的区别。

    2021 年 2 月 25 日 下午 15:01

    1. antistress

      给自己回答
      Total Cookie Protection = 状态分区 = 动态第一方隔离

      “DFPI 和 FPI 之间最重要的区别是 DFPI 将遵守通过存储访问 API 授予的例外情况，从而确保更好的 Web 兼容性。”
      https://wiki.mozilla.org/Firefox_Security_Newsletter/FSN-2020-Q1#Privacy

      2021 年 2 月 26 日 上午 06:25

  8. Helle Vaanzinn

    感谢两位解释了这个新的隐私功能。我不是这方面的专家，只是 Firefox 的一个感兴趣的用户，我偶然发现了 https://blog.lukaszolejnik.com/large-scale-analysis-of-dns-based-tracking-evasion-broad-data-leaks-included/。对于不熟悉技术的用户来说，这一切都相当令人困惑，因此如果有人可以详细解释一下，那就非常有启发意义了。“状态分区”是否对这些基于 CNAME 的跟踪尝试提供任何保护？

    通过滥用 DNS 记录来消除第一方上下文和第三方上下文之间的区别，作者似乎暗示第三方 Cookie 阻止变得无效。我认为我理解了这一点。引用作者的话

    “截至今天，在主要的 Web 浏览器供应商中，只有 Firefox 提供了扩展防御的技术能力，Safari 有一些部分缓解措施（Cookie 泄露仍然存在），而 Brave 浏览器提供的防御措施是基于阻止 CNAME 泄露。从 Firefox 的 uBlock 1.25 版本开始，该扩展会动态解析主机并在找到匹配项时对这些请求进行清理。”

    对于 Firefox 用户来说，这是一个非常好的消息，但它仍然假设用户有足够的知识来安装 uBlock Origin，这似乎并不理想。是否计划将此非常优秀的附加组件所使用的技术纳入 Web 浏览器本身？

    此致

    2021 年 2 月 25 日 下午 23:36

  9. 谢谢！

    在严格模式下，“privacy.annotate_channels.strict_list.enabled” 设置为“true”。切换到自定义模式时，此设置不会更改。这独立于用户在自定义模式中选择的设置。因此，无法通过检查自定义模式设置来了解“privacy.annotate_channels.strict_list.enabled” 的状态。

    2021 年 2 月 26 日 上午 00:43

  10. 谢谢！

    Mozilla 在 Firefox 中引入了状态分区，真是太棒了！非常感谢！希望它不会助长浏览器指纹识别！
    选择“ETP 严格模式”会在 prefs.js 中设置五个首选项：browser.contentblocking.category = strict, network.cookie.cookieBehavior = 5, privacy.annotate_channels.strict_list.enabled = true, privacy.trackingprotection.enabled = true, privacy.trackingprotection.socialtracking.enabled = true。
    仅设置“network.cookie.cookieBehavior = 5” 是否足以仅激活状态分区（不启用基于 Disconnect 阻止列表的跟踪保护）？

    2021 年 2 月 26 日 上午 00:46

  11. Mark de Roussier

    如果可以避免，我不会使用 SSO。但现在，我经常访问网站，却不得不手动关闭 Firefox 自动授予 SSO 提供商的权限，而且这些权限是我不想要的。对此我别无选择，没有设置可以关闭此行为，而且非常令人讨厌。为什么我必须容忍这些 Cookie 被允许，除非我想要它们？这不是在“严格”选项下进行特定于站点的控制的意义吗？现在，Firefox 似乎剥夺了这种控制，并覆盖了用户的意愿。此功能被吹捧为某种重大进步，但实际上，如果您真的*不*希望第三方 Cookie（除非您明确允许它们），那它就会很麻烦。当我撤销 Firefox 未经我允许授予的权限时，Firefox 至少应该记住我不希望允许该域。

    2021 年 3 月 20 日 下午 19:11

本文的评论已关闭。