ユーザーのプライバシーを強化し、サイドチャネルによるクロスサイト トラッキングに対抗するため、Chrome ではストレージ パーティショニングと呼ばれるプロセスを通じて、サードパーティのコンテキストでほとんどのストレージ API と通信 API を分離するようになりました。
実装ステータス
この機能は、Chrome 115 以降のすべてのユーザーに対して有効になっています。同様のストレージ分割は、Firefox や Safari などの他の主要なブラウザでも実施または計画されています。GitHub のストレージ パーティショニング プロポーザルは、引き続き議論が開かれています。
ストレージ パーティショニングとは
特定の種類のサイドチャネルによるクロスサイト トラッキングを防止するため、Chrome ではサードパーティのコンテキストでストレージ API と通信 API をパーティショニングしています。
ストレージ パーティショニングがないと、サイトは異なるサイト間でデータを結合して、ウェブ全体でユーザーを追跡できます。また、埋め込みサイトは、タイミング攻撃、XS-Leaks、COSI などのサイドチャネル手法を使用して、トップレベル サイトのユーザーに関する特定の状態を推測できます。
これまで、ストレージはオリジンでのみキー付けされていました。つまり、example.com の iframe が a.com と b.com に埋め込まれている場合、ストレージに ID を保存し、ストレージから ID を正常に取得することで、これらの 2 つのサイトのブラウジング習慣を学習できます。サードパーティのストレージ パーティショニングが有効になっている場合、example.com のストレージは 2 つの異なるパーティション（1 つは a.com 用、もう 1 つは b.com 用）に存在します。
一般に、パーティショニングとは、iframe 内のローカル ストレージや IndexedDB などのストレージ API によって書き込まれたデータに、同じオリジンを共有するすべてのコンテキストからアクセスできなくなることを意味します。代わりに、そのデータは分離され、同じオリジンと同じトップレベル サイトの両方を共有するコンテキストでのみ使用できるようになりました。
変更前
変更後
連結された iframe でのストレージ パーティショニング
iframe がネストされている場合、特にチェーン内に同じオリジンが複数回出現する場合、ストレージ パーティショニングの複雑さは大幅に増加します。
たとえば、A1 に B の iframe が含まれ、その iframe に A2 の iframe が含まれており、A1 と A2 の両方が同じサイトにある場合です。パーティショニングで最上位サイトと現在のフレームのオリジンのみが考慮されると、iframe A2 は、間にクロスサイト iframe B があるにもかかわらず、最上位サイト（A1）とサイトを共有しているため、「ファースト パーティ」と誤って扱われる可能性があります。A2 がデフォルトでパーティショニングされていないストレージにアクセスできる場合、A2 がクリックジャッキングなどのセキュリティ リスクにさらされる可能性があります。
この問題に対処するため、Chrome ではストレージ パーティション キーに「祖先ビット」が追加されます。このビットは、現在の iframe とトップレベル サイトの間にあるドキュメントが別の（クロスサイト）オリジンからのものである場合に設定されます。この場合、サイト B はクロスサイトであるため、A2 にビットが設定され、そのストレージは A1 からパーティショニングされます。
iframe チェーンが同じサイトのコンテキストのみで構成されている場合（A2 を含むサイト A1 が A3 を含むなど）、祖先ビットはストレージをさらにパーティショニングしません。この場合、ストレージは共有されたままになり、共通のオリジンと最上位サイトによってキーが設定されます。
連鎖された iframe 全体にパーティション化されていないアクセスが必要なサイトの場合、Chrome ではこのユースケースを可能にするために Storage Access API の拡張を試験運用しています。Storage Access API では、フレーム内のサイトが API を明示的に呼び出す必要があるため、クリックジャッキングのリスクを軽減できます。
パーティショニングによる API の変更
パーティショニングの影響を受ける API は、次のグループに分類できます。
ストレージ API
- 割り当てシステム
- 割り当てシステムは、ストレージに割り当てるディスク容量を決定するために使用されます。割り当てシステムは、各パーティションを個別のバケットとして管理し、許可される容量と、その容量が消去されるタイミングを決定します。
navigator.storage.estimate()メソッドで、ストレージ パーティションに固有の情報が提供されるようになりました。window.webkitStorageInfoやnavigator.webkitTemporaryStorageなどの Chrome 専用の API は非推奨になりました。- IndexedDB とキャッシュ ストレージは、パーティション分割された割り当てシステムを使用します。
- Web Storage API
- Web Storage API は、ブラウザが Key-Value ペアを保存できるメカニズムを提供します。メカニズムは 2 つあります。ローカル ストレージとセッション ストレージです。割り当て管理対象ではありませんが、パーティショニングは行われます。
- オリジンのプライベート ファイル システム
- File System Access API を使用すると、ユーザーがアクセス権を付与した後、サイトはデバイス上のファイルやフォルダに変更を直接読み取ったり保存したりできます。オリジンのプライベート ファイル システムを使用すると、オリジンはプライベート コンテンツをディスクに直接保存できます。このコンテンツは引き続きユーザーがアクセスできますが、パーティショニングされます。
- Storage Bucket API
- Storage Bucket API は Storage Standard 用に開発されています。この API は、バケットという新しいコンセプトを使用して、IndexedDB や localStorage などのさまざまなストレージ API を統合します。バケットに保存されているデータとバケットに関連付けられているメタデータはパーティショニングされます。
- Clear-Site-Data ヘッダー
- レスポンスに
Clear-Site-Dataヘッダーを含めると、サーバーはユーザーのブラウザに保存されているデータを消去するようリクエストできます。キャッシュ、Cookie、DOM ストレージを削除できます。ヘッダーを使用すると、1 つのパーティション内のストレージのみが消去されます。
- Blob URL ストア
- Blob URL は、元のデータを含むオブジェクトであるblob へのアクセスを提供します。ストレージ パーティショニングを使用しない場合、1 つのサイトのサードパーティ iframe で生成された blob URL は、別のサイトに埋め込まれた同じオリジンの iframe で使用できます。たとえば、
example.comiframe がa.comとb.comの両方に埋め込まれている場合、a.comに埋め込まれた iframe で生成された blob URL を、制限なくb.comに埋め込まれた iframe に渡して使用できます。Chrome 137（2025 年 5 月 27 日リリース）以降、Blob URL はトップレベル ナビゲーションを除くすべての用途でパーティショニングされます。ブロックされるケースには、fetch()で使用されるクロスパティション blob URL や、さまざまな HTML 要素のsrc属性値として使用されるクロスパティション blob URL が含まれます。window.open()の呼び出しやtarget='_blank'によるリンクのクリックなど、Blob URL へのトップレベル ナビゲーションは、パーティション間であってもブロックされませんが、blob URL サイトが、ナビゲーションを開始したページのトップレベル サイトと異なる場合は、noopenerが適用されます。noopenerが適用されている場合、ナビゲーションを開始したドキュメントは、開いた blob URL ドキュメントのウィンドウ ハンドルを取得できなくなります。上の例では、パーティショニングにより、b.comの iframe が blob URL のコンテンツを取得できなくなりますが、window.open()は引き続き行えます。
Communication API
ストレージ API に加えて、1 つのコンテキストがオリジンの境界を越えて通信できるようにする通信 API もパーティショニングされます。この変更は主に、ブロードキャストまたは同一オリジン ランデブーを使用して他のコンテキストを検出できる API に影響します。
パーティショニングにより、次の通信 API では、サードパーティの iframe が同じオリジンのコンテキストとデータを交換できなくなります。
- ブロードキャスト チャンネル
- Broadcast Channel API を使用すると、ブラウジング コンテキスト（ウィンドウ、タブ、iframe）と同じオリジンのワーカーとの通信が可能になります。
- クロスサイト iframe
postMessage()の動作は、それらのコンテキストの関係がすでに明確に定義されているため、変更されることは提案されていません。
- SharedWorker
- SharedWorker API は、同じオリジンのブラウジング コンテキスト間でアクセスできるワーカーを提供します。
- ウェブロック
- Web Locks API を使用すると、同じオリジンの 1 つのタブまたはワーカーで実行されているコードが、一部の処理を実行しながら共有リソースのロックを確保できます。
Service Worker API
Service Worker API を使用すると、サイトはバックグラウンドでタスクを実行できます。サイトは、イベントに応答するために新しいワーカー コンテキストを作成するサービス ワーカーを登録します。従来、これらのワーカーは、同じオリジンのコンテキストと通信できました。ただし、Service Worker はナビゲーション リクエストのタイミングを変更できるため、履歴スニッフィングなどのクロスサイト情報漏洩のリスクがあります。
このため、サードパーティ コンテキストから登録された Service Worker はパーティショニングされるようになりました。
Extensions API
拡張機能は、ユーザーがブラウジング エクスペリエンスをカスタマイズできるプログラムです。
拡張機能ページ（chrome-extension:// スキームのページ）は、ウェブ上のサイトに埋め込むことができます。このシナリオでは、拡張機能ページは引き続き最上位パーティションにアクセスできます。拡張機能は他のサイトを埋め込むこともできます。埋め込まれたサイトは、拡張機能にホスト権限が付与されている場合、トップレベル パーティションにアクセスします。
詳細については、拡張機能のドキュメントをご覧ください。
デモ: ストレージ パーティショニングのテスト
デモサイト: https://storage-partitioning-demo-site-a.glitch.me/
ストレージ パーティショニングありのブラウザ（左）とストレージ パーティショニングなしのブラウザ（右）の出力を示すデモのスクリーンショット。このデモでは、サイト A とサイト B の 2 つのサイトを使用します。
- トップレベルのコンテキストでサイト A にアクセスすると、さまざまなストレージ方法を使用してデータが設定されます。
- サイト B がサイト A のページを埋め込み、その埋め込みが以前に設定されたストレージ オプションの読み取りを試みます。
- サイト A がサイト B に埋め込まれている場合、ストレージがパーティショニングされているときにそのデータにアクセスできないため、読み取りが失敗します。
- このデモでは、各読み取りの成功または失敗を使用して、データがパーティショニングされているかどうかを示します。
現時点では、--disable-features=ThirdPartyStoragePartitioning コマンドライン スイッチを使用して、Chrome でストレージ パーティショニングをオフにできます。注: このコマンドライン スイッチは開発とテストを目的としており、今後の Chrome バージョンで削除または変更される可能性があります。
他のブラウザでも同様にテストして、パーティショニング ステータスを確認できます。
移行期間の延長をリクエストする
依存関係の移行にさらに時間が必要なサイトについては、DisableThirdPartyStoragePartitioning3 の非推奨トライアルが延長されました。このトライアルでは、ページに埋め込まれたサードパーティ コンテキストで、最上位サイトがパーティショニングされていないストレージ、サービス ワーカー、通信 API を有効にするための一時的なメカニズムを提供します。
詳細については、ストレージ パーティショニングのサポート終了に関するトライアルの更新をご覧ください。
意見交換とフィードバックの提供
- GitHub: 元の提案を読み、質問を投稿し、ディスカッションに参加します。
- デベロッパー サポート: プライバシー サンドボックス デベロッパー サポート リポジトリで質問や意見交換を行えます。
- バグを報告する: 何かが想定どおりに動作していないと思われる場合は、Chromium トラッカーでバグを報告してください。