为了加强用户隐私保护并防范边信道跨网站跟踪,Chrome 现在通过一项名为“存储分区”的流程,隔离第三方上下文中的大多数存储和通信 API。
实现状态
我们已为使用 Chrome 115 及更高版本的所有用户启用此功能。其他主要浏览器(如 Firefox 和 Safari)也已实施或计划实施类似的存储分区措施。GitHub 上的存储分区提案已开放供进一步讨论。
什么是存储分区?
为了防止某些类型的边信道跨网站跟踪,Chrome 会在第三方上下文中划分存储空间和通信 API。
如果不进行存储分区,网站可以联接不同网站中的数据,以便在网络上跟踪用户。此外,它还允许嵌入式网站使用边信道技术(例如时间攻击、XS-Leaks 和 COSI)推断顶级网站中用户的特定状态。
过去,存储空间仅按来源设置键值。这意味着,如果 a.com
和 b.com
中嵌入了 example.com
中的 iframe,它可以通过存储 ID 并从存储空间中成功检索该 ID,了解您在这些网站上的浏览习惯。启用第三方存储分区后,example.com
的存储空间会位于两个不同的分区中,一个用于 a.com
,另一个用于 b.com
。
一般来说,分区意味着由 iframe 中的存储 API(例如 localStorage 和 IndexedDB)写入的数据将无法再被共享相同源的所有上下文访问。相反,这些数据现在是隔离的,并且仅适用于共享相同来源和相同顶级网站的情境。
链接的 iframe 上的存储分区
嵌套 iframe 时,存储分区的复杂性会显著增加,尤其是当链中出现多次相同来源时。
例如,A1 包含 B 的 iframe,B 包含 A2 的 iframe,并且 A1 和 A2 位于同一网站上。如果分区仅考虑顶级网站和当前框架的来源,则 iframe A2 可能会被误认为是“第一方”,因为它与顶级网站 (A1) 共用一个网站,尽管中间有跨网站 iframe B。如果 A2 默认有权访问未分区的存储空间,则可能会导致 A2 面临点击劫持等安全风险。
为解决此问题,Chrome 会向存储分区键添加“祖先位”。如果当前 iframe 和顶级网站之间的任何文档都来自其他(跨网站)来源,系统就会设置此位。在本例中,站点 B 是跨站点,因此系统会为 A2 设置该位,并将其存储空间从 A1 分区。
如果 iframe 链仅由同一网站上下文组成(例如,网站 A1 包含 A2,A2 包含 A3),祖先位不会进一步划分其存储空间。在这种情况下,其存储空间仍会共享,并以其共同的来源和顶级网站作为键。
对于需要跨链接的 iframe 实现未分区访问的网站,Chrome 正在尝试扩展 Storage Access API 以实现此用例。由于 Storage Access API 要求嵌套的网站明确调用该 API,因此这会降低点击欺骗风险。
因分区而发生的 API 更改
受分区影响的 API 可分为以下几类:
Storage API
- Web Storage API
- Web Storage API 提供了浏览器可以通过的机制来存储键值对。有两种机制:本地存储和会话存储。它们不受配额管理,但仍会进行分区。
- 源私有文件系统
- File System Access API 允许网站在用户授予访问权限后,直接读取或保存对设备上文件和文件夹的更改。借助源私有文件系统,源可以直接将私密内容存储到磁盘。用户仍可访问此类内容,但现在已分区。
- Storage Bucket API
- Storage Bucket API 正在为 Storage Standard 开发,该 API 通过使用名为存储分区的新概念,整合了 IndexedDB 和 localStorage 等各种存储 API。存储在存储分区中的数据以及与存储分区关联的元数据会进行分区。
- Clear-Site-Data 标头
- 在响应中添加
Clear-Site-Data
标头后,服务器可以请求清除存储在用户浏览器中的数据。可以清除缓存、Cookie 和 DOM 存储空间。使用该标头只会清除一个分区中的存储空间。
通信 API
除了存储 API 之外,允许一个上下文跨源边界进行通信的通信 API 也会进行分区。这些变更主要影响允许使用广播或同源集合点发现其他上下文的 API。
由于分区,以下通信 API 会阻止第三方 iframe 与其同源上下文交换数据:
- SharedWorker
- SharedWorker API 提供了一个可跨同一源的浏览上下文访问的工作器。
- 网页锁定
- 借助 Web Locks API,在同一个源的某个标签页或工作器中运行的代码可以在执行某些工作时为共享资源获取锁。
Service Worker API
借助 Service Worker API,网站可以在后台执行任务。网站会注册服务工件,这些工件会创建新的工件上下文来响应事件。传统上,这些 worker 可以与任何同源上下文进行通信。不过,由于 Service Worker 可以更改导航请求的时间,因此存在跨网站信息泄露(例如历史记录嗅探)的风险。
因此,从第三方环境注册的 Service Worker 现在会进行分区。
扩展程序 API
扩展程序是可让用户自定义浏览体验的程序。
扩展程序页面(采用 chrome-extension://
架构的网页)可嵌入到网络上的网站中。在这种情况下,扩展程序页面仍可以访问其顶级分区。扩展程序还可以嵌入其他网站;如果这样做,这些嵌入的网站将访问其顶级分区,前提是该扩展程序对这些网站拥有主机权限。
如需了解详情,请参阅扩展程序文档。
演示:测试存储分区
演示网站:https://storage-partitioning-demo-site-a.glitch.me/

该演示使用了两个网站:网站 A 和网站 B。
- 当您在顶级上下文中访问网站 A 时,该网站会使用各种存储方法设置数据。
- 网站 B 嵌入了网站 A 中的某个网页,并且该嵌入会尝试读取之前设置的存储选项。
- 当网站 A 嵌入到网站 B 中时,在存储空间分区后,网站 A 将无法访问这些数据,因此读取会失败。
- 该演示使用每次读取的成功或失败情况来显示数据是否已分区。
目前,您可以使用 --disable-features=ThirdPartyStoragePartitioning
命令行开关在 Chrome 中关闭存储分区。注意:此命令行开关仅用于开发和测试目的,可能会在未来的 Chrome 版本中移除或更改。
您还可以通过相同的方式测试其他浏览器,以查看它们的分区状态。
互动和分享反馈
- GitHub:阅读原始提案,提出问题并参与讨论。
- 开发者支持:在 Privacy Sandbox 开发者支持代码库中提问和参与讨论。
- 提交 bug:如果您认为某项功能未能按预期运行,请在 Chromium 跟踪器中提交 bug。