Cross-Origin Storage API：ファイルの二重ダウンロードを防ぐ
Cross-Origin Storage APIを利用すれば、ブラウザが2つのサイト間で33GBのAIモデルを共有できるようになり、ダウンロードデータ量を66GBから33GBへと削減できる可能性があります。
かつてブラウザは、あるサイトがすでに取得したファイルを、他のサイトでも再利用できるようにしていました。例えば、2つのページでCDNから同じReactのバンドルを読み込む場合、ブラウザは2回目にキャッシュされたコピーを提供します。しかし、プライバシーを重視した一連の変更により、この利便性は失われました。現在のブラウザはサイトごとにキャッシュをパーティション化（分離）しているため、たとえURLが同一であっても、オリジンごとに個別に保存されます。その結果、複数のサイトに登場する大規模なアセットごとに、重複したトラフィックが発生してしまいます。
なぜ今、重複ダウンロードの問題が重要なのか
この無駄は、Webフォントや数メガバイトのJavaScriptといった小さなファイルでも発生しますが、アセットが数ギガバイトのAIモデルやWebAssemblyモジュールになると、その影響は爆発的に増大します。
Cross-Origin Storage (COS) APIの仕組み
この提案は、URLベースの検索をコンテンツベースの検索に置き換えるものです。サイトは、必要とするファイルのSHA-256ハッシュを提供します。ブラウザは、どのオリジンが最初に取得したかにかかわらず、ローカルストア内にその正確なハッシュが存在するかを確認します。ファイルが存在すればブラウザはそれを渡し、存在しなければネットワークからファイルをフェッチして、将来的なクロスオリジンでの再利用のためにそのハッシュで保存します。
- ハッシュによる識別。 ハッシュはファイルの場所ではなく、ファイルの内容（バイト列）を一意に表します。
- クロスオリジン・アクセス。 ハッシュを知っているサイトであれば、たとえ別の場所から取得されたものであっても、そのファイルをリクエストできます。
- ローカルキャッシュの共有。 同一の物理的なコピーが、複数のリクエストを満たします。
このAPIは意図的に限定的な設計になっています。既存のCache APIやIndexedDBを置き換えるものではありません。それらは汎用ストレージのためのツールとして残り、COSは大規模で同一なブロブ（blob）のための単一目的のショートカットとして機能します。
設計に組み込まれたプライバシー保護策
サイトがユーザーのキャッシュを調査することを許可してしまうと、キャッシュのパーティション化が阻止しようとしていたトラッキングの手法を再び導入してしまう可能性があります。COSは、以下の3つのルールによってそのリスクをブロックします。
- 列挙の禁止。 スクリプトは「どのようなハッシュを持っているか？」と尋ねることはできません。ストレージの内容は不透明（opaque）です。
- 既知のハッシュの要件。 サイトは、正確なハッシュをすでに知っている場合にのみファイルをリクエストできます。事前の知識なしにランダムに調査することは不可能です。
- グローバルアクセスのための普及度しきい値。 異なるオリジンがファイルを回収できるようにするには、そのファイルが十分に一般的（すなわち「匿名」）である必要があります。珍しいファイルは、最初にダウンロードしたオリジン内に隔離されたままとなります。
これらの制限により、APIを真に共有されるべきアセットに有用なものに保ちつつ、フィンガープリント作成のためのサイドチャネルになることを防いでいます。
今後の注目点
Cross-Origin Storage APIは、ブラウザ内でのアセットの巨大化に伴って深刻化した問題に対し、明快な解決策を提示しています。ウェブコミュニティが、帯域幅の効率性と、キャッシュのパーティション化の動機となったプライバシー保証とのバランスをいかに取れるかが、このアイデアがドラフト段階を超えて進展するかどうかを左右するでしょう。もし実現すれば、将来のブラウザでは30GBを超えるAIモデルを一度ダウンロードするだけで、あらゆる場所で再利用できるようになり、時間、データ、そしてエネルギーの節約につながります。