在我们推出所有 Firefox 用户的 状态分区 之前，我们打算对 存储访问 API进行一些隐私和人体工程学方面的改进。在这篇博文中，我们将详细介绍我们所做的一些新的更改。

使用状态分区，第三方在嵌入到不同的网站时无法访问相同的 Cookie 罐。相反，他们会为他们嵌入的每个网站获得一个新的 Cookie 罐。这不仅限于 Cookie，所有存储都是以这种方式分区的。

在理想情况下，这将阻止跟踪器在所有嵌入它们的地方跟踪你，因为它们无法在所有这些网站上保留你的唯一标识符。不幸的是，世界并不那么简单——跟踪器并不是唯一使用存储的第三方。如果你曾经使用过需要嵌入资源的身份验证提供商，你就知道第三方存储的重要性。

输入存储访问 API。此 API 允许第三方请求存储访问权限，就像他们是第一方一样。这被称为“取消分区”，它让浏览器和用户控制哪些第三方可以跨第一方来源维护状态，以及确定他们可以从哪些来源访问该状态。这是第三方跨网站共享存储的首选方法。

存储访问 API 为浏览器提供了很大的空间来决定何时允许第三方无限制地访问存储。这是一个让浏览器自由做出它认为最适合用户的决定的功能，并决定何时直接向用户呈现关于存储权限的选择。

另一方面，这意味着存储访问 API 在不同的浏览器和版本之间可能会有所不同。因此，除非我们做两件事，否则开发人员的体验会受到影响：1) 以开发人员的体验为中心进行设计；以及 2) 传达我们正在做的事情。

让我们深入研究！以下是我们对存储访问 API 做出的四项更改，这些更改将提高用户隐私并保持强大的开发人员体验…

要求用户同意第三方用户从未与之互动

使用存储 API，浏览器会决定是否让用户参与决定是否授予第三方存储访问权限。以前，Firefox 不会让用户参与，直到第三方已经在五个不同的网站上访问了其存储。在那一点上，第三方的存储访问请求会被呈现给用户以做出决定。

我们允许第三方在一些网站上取消分区他们的存储，因为我们担心弹出式权限请求会淹没用户。我们认为，只允许每个第三方进行几次权限授予将保持较低的权限频率，同时仍可以阻止任何一方在许多网站上跟踪用户。

我们还想通过减少第三方在不向用户提供大量存储访问请求的情况下自动取消分区自身次数来改善存储访问 API 实施中的用户隐私。我们最终做出的改进是，要求用户最近与第三方进行过互动，才能在不显式询问用户是否允许的情况下授予他们存储访问权限。我们认为，对于用户从未见过的网站，取消自动存储访问权限授予，可以在不给用户带来太多麻烦的情况下体现状态分区的精神。

细心的读者现在可能会担心，任何仅嵌入的页面，如一些身份验证服务，都会受到很大影响。为了进一步将天平倾斜到用户少操作的方向，我们扩展了“与网站互动”的定义，以支持仅嵌入的上下文。现在，无论何时用户通过权限弹出窗口授予存储访问权限，或者与具有存储访问权限的 iframe 交互，这些都算作用户互动。这种改变是仔细权衡保护合法用例、保护用户隐私和不因无休止的权限提示惹恼用户的结果。我们认为我们找到了最佳方案。

将第一方存储访问范围更改为站点

在推出状态分区的过程中，我们看到了许多关于存储访问 API 的用例。一种常见的用例是使用第三方启用身份验证。

我们偶尔发现，授予身份验证服务第一方存储访问权限的登录门户是一个子域，例如 https://login.example.com。当用户在登录后导航到 https://example.com 时，就会出现问题……他们不再登录！这是因为存储访问权限仅授予登录子域，而不是授予网站的其余部分。身份验证提供商可以访问 https://login.example.com上的 Cookie，但不能访问 https://example.com上的 Cookie。

我们通过将存储访问权限移至站点范围来解决此问题。这意味着，当第三方在页面上获得存储访问权限时，它可以访问同一站点上所有页面的未分区存储。所以在上面的示例中，身份验证第三方将可以访问 https://login.example.com、 https://example.com和 https://any.different.subdomain.example.com上的用户登录 Cookie！但他们仍然无法访问 http://example.com 或 https://different-example.com上的登录 Cookie。

清理用户互动要求

在请求存储访问权限时要求用户互动是存储访问 API 定义的一个粗糙边缘。让我们谈谈这个要求。

如果第三方在页面加载后立即调用 requestStorageAccess，它不应该获得该存储访问权限。它需要等待用户与其 iframe 交互。滚动或点击是获得这种用户互动的良好方式，它会在授予后几秒钟过期。不幸的是，此要求中有一些特殊情况，我们需要清理。

一个特殊情况涉及用户在权限提示上点击接受或拒绝时如何处理用户的互动状态。我们决定，当用户在存储访问权限提示上点击拒绝时，第三方应该失去其用户互动。这可以阻止第三方立即再次请求存储访问权限，从而让用户感到厌烦，直到他们接受。

相反，我们决定如果用户点击接受，则重置用户互动的计时器，以反映用户确实与第三方进行了互动。这将允许第三方仅通过一次用户与其 iframe 的互动来使用需要存储访问权限和用户互动的 API。

另一个特殊情况涉及在要求用户互动进行存储访问请求时，需要多么严格。随着我们对存储访问 API 的迭代，已经引入了微小的更改。其中一项更改与在页面上授予第三方存储访问权限，然后页面重新加载的情况有关。第三方是否必须在再次请求存储访问权限之前获得用户互动？最初，答案是否定的，但现在是肯定的。我们更新了我们的实现以反映该更改，并与其他浏览器保持一致。 

集成用户 Cookie 偏好设置

在 Firefox 的设置中 增强型跟踪保护，用户可以指定他们希望浏览器如何处理 Cookie。默认情况下，Firefox 会阻止来自已知跟踪器的 Cookie。但我们还有其他一些可能的选项，例如允许所有 Cookie 或阻止所有第三方 Cookie。用户可以根据自己的喜好更改此偏好设置。

在实施存储访问 API 时，我们一直尊重用户的这一选择。但是，这对开发人员来说并不清楚。例如，将 Firefox 设置为阻止所有第三方 Cookie 的用户会很高兴地知道存储访问 API 绝不会削弱他们的保护；即使是存储访问权限也不会让第三方访问存储。但这对第三方的开发人员来说并不清楚。

来自 requestStorageAccess 的返回 promise 将被解析，表明第三方可以访问其未分区存储。我们努力解决这个问题。在 Firefox 98 中，当用户通过首选项禁用第三方 Cookie 时，函数 requestStorageAccess 将始终返回拒绝 promise，hasStorageAccess 将始终返回 false。