跨源存储 API：停止重复下载文件

跨源存储 API (Cross-Origin Storage API) 可以让浏览器在两个网站之间共享一个 33 GB 的 AI 模型，从而将下载数据量从 66 GB 减少到 33 GB。

浏览器过去允许任何网站复用另一个网站已经获取的文件。例如，在两个页面上从 CDN 加载相同的 React bundle，浏览器在第二次请求时会提供缓存副本。然而，一系列以隐私为中心的变更破坏了这种便利性：浏览器现在按网站对缓存进行分区，因此即使是完全相同的 URL，也会为每个源 (origin) 分别存储。其结果是，每个出现在多个网站上的大型资源都会产生重复流量。

为什么重复下载问题现在变得至关重要

这种浪费在处理小文件（如 Web 字体或几兆字节的 JavaScript）时表现并不明显，但当资源是数 GB 的 AI 模型或 WebAssembly 模块时，问题就会呈爆炸式增长。

跨源存储 (COS) API 的工作原理

该提案将基于 URL 的查找替换为基于内容的寻址。网站提供其想要的文件的一个 SHA-256 哈希值。浏览器会在其本地存储中检查该精确的哈希值，而无需关心最初是由哪个源获取的。如果文件存在，浏览器会将其交付；如果不存在，则从网络获取文件，并将其存储在对应的哈希值下，以便未来进行跨源复用。

  • 通过哈希识别。 哈希值唯一代表文件的字节内容，而非其位置。
  • 跨源访问。 任何知道该哈希值的网站都可以请求该文件，即使它最初源自其他地方。
  • 本地缓存共享。 同一份物理副本可以满足多个请求。

该 API 的设计刻意保持精简：它并不取代现有的 Cache API 或 IndexedDB。后者仍是通用存储的工具；COS 是针对大型、相同 blob 的单一用途快捷方式。

设计中内置的隐私保护措施

允许网站探测用户的缓存可能会重新引入旨在通过缓存分区来阻止的追踪手段。COS 通过三条规则来规避这一风险：

  1. 禁止枚举。 脚本无法询问“你拥有哪些哈希值？”——存储内容是不透明的。
  2. 已知哈希要求。 网站只有在已知精确哈希值的情况下才能请求文件。在没有预知知识的情况下，无法进行随机探测。
  3. 全局访问的流行度阈值。 在其他源可以检索文件之前，该文件必须足够常见——即具有“匿名性”。稀有文件将仅保留在首次下载它们的源中。

这些限制确保了 API 对真正共享资源的实用性，同时防止其成为指纹识别 (fingerprinting) 的侧信道 (side channel)。

后续关注点

跨源存储 API 为随着浏览器内大型资源增加而日益严重的问题提供了一个直接的解决方案。Web 社区能否在带宽效率与促成缓存分区的隐私保证之间取得平衡，将决定该想法能否超越草案阶段。如果成功，未来的浏览器可以让你只下载一次 30 多 GB 的 AI 模型，然后在任何地方复用——从而节省时间、数据和能源。