Chrome 115 通过在第三方上下文中进行分区,对存储空间、Service Worker 和通信 API 做出了更改。除了被同源政策隔离之外,在第三方上下文中使用的受影响 API 也会被顶级上下文的网站隔离出来。
尚未来得及支持第三方存储分区的网站可以参与弃用试用,以暂时取消分区(继续按同源政策进行隔离,但取消顶级网站的隔离),并恢复其网站上嵌入的内容中的存储、Service Worker 和通信 API 之前的行为。Chrome 127 于 2024 年 9 月 3 日发布后,此弃用试用期就已到期。请注意,这与第三方 Cookie 弃用试用期是分开的:这仅适用于访问存储空间。
作为一项长期解决方案,旨在应对因第三方非 Cookie 存储分区中断而中断的某些用例。Chrome 提议:让第三方能够通过 Storage Access API(自 Chrome 117 起开始发货)请求存储/通信访问权限(包括 Cookie 和非 Cookie 访问权限),该 API 已允许第三方请求 Cookie 访问权限。
从 Chrome 120 开始,此提案将可供通过源试用进行实验。开发者应参与此来源试用,以评估建议的解决方案如何解决其用例,确保在弃用试用结束前做好准备。
源试用详情
从 Chrome 120 开始,Chrome 将支持源试用 StorageAccessAPIBeyondCookies,以支持针对 Storage Access API 提议的扩展程序(向后兼容),以允许在第三方环境中访问未分区存储空间(Cookie 和非 Cookie)。
力学
该 API 可按如下方式使用(在嵌入式 iframe 中运行的 JavaScript):
// Request a new storage handle via rSA (this should prompt the user)
const handle = await document.requestStorageAccess({all: true});
// Write some 1P context sessionStorage
handle.sessionStorage.setItem('userid', '1234');
// Write some 1P context localStorage
handle.localStorage.setItem('preference', 'A');
// Open or create an indexedDB that is shared with the 1P context
const messageDB = handle.indexedDB.open('messages');
// Use locks shared with the 1P context
await handle.locks.request('example', ...);
如果您只需要特定的 API 访问权限,而不是对 all
的访问权限,则可以只传递所需的 API 句柄的名称。例如,您可以传递 {sessionStorage: true}
来仅获取对会话存储空间的访问权限,也可以传递 {indexedDB: true, locks:true}
来获取对 IndexedDB 和 Web 锁的访问权限。
除了调用以下额外的扩展之外,对非 Cookie 存储的访问也符合通过 Storage Access API 访问 Cookie 的当前要求。例如,在 Chrome 中,当源位于同一个 Related Website Set(First Party Set 的新名称:RWS)中时,系统就不会显示任何提示。不属于同一 RWS 的来源需要遵守 Chrome 中 Storage Access API 的提示要求。
时长
源试用从 Chrome 120 开始,一直持续到 Chrome 125(或任何里程碑阶段的 2024 年 8 月 6 日之后)。
范围
Chrome 120 仅支持 DOM Storage(会话和本地存储)、Indexed DB 和 Web Locks。
Chrome 121 中添加了缓存存储空间、源私有文件系统、配额、Blob 存储空间和广播通道。
Chrome 123 中添加了共享工作器以及对添加 Cookie 的控制。
从 Chrome 120 开始,如果在创建工作器之前调用了 requestStorageAccess
,专用工作器将继承对未分区的 Cookie 的访问权限(这不需要使用 Storage Access API 句柄)。
参与
- 评估您在第三方环境中如何使用 Cookie 和非 Cookie 存储。示例用例可能有助于您了解此方案是否符合您的需求。
- 启动 Chrome 120 或更高版本,并确保启用了 test-third-party-cookie-phaseout flag。
- 如果您想先在本地测试该功能,而不先设置来源试用令牌,可以在浏览器中启用 #enable-experimental-web-platform-features。
- 在本地完成测试后,您可以注册 StorageAccessAPIBeyondCookies 源代码试用计划,并为您的网域获取令牌。如需了解详细说明,请访问开始试用。Chrome 源试用问题排查指南提供了完整的核对清单,以确保正确配置令牌。
- 使用 HTTP 标头、HTML 元标记或程序化方式,将该来源试用令牌嵌入到您需要在其中使用 Storage Access API 句柄的 iframe 中。请注意,任何希望使用此 API 的框架都必须嵌入令牌,将令牌嵌入父级框架不会在子框架中启用该 API。
- 调用
document.requestStorageAccess(...)
以获取跨网站 iframe 中的 Storage Access API 句柄。如需了解此调用成功所需满足的要求,请参阅 Storage Access API 文档。 - 迁移 iframe 中的存储相关内容,以使用 Storage Access API 句柄(如果有)。例如,对
window.sessionStorage.setItem(...)
的调用会变为handle.sessionStorage.setItem(...)
。 - 打开您的网站,验证存储空间访问标识名是否按预期运行。
- 如要停止参与来源测试,请移除您在第 3 步中添加的令牌。
- 如需提交反馈或提出遇到的任何问题,请访问 Storage Access API 非 Cookie 存储 GitHub 代码库。
演示:使用 Storage Access API 访问未分区的本地存储空间
以下演示展示了如何使用 Storage Access API 从第三方 iframe 访问未分区的广播通道:
https://saa-beyond-cookies.glitch.me/
此演示版需要 Chrome 121 或更高版本,且已启用 test-third-party-cookie-phaseout 标志。