ストレージ パーティショニング

特定の種類のサイドチャネルによるクロスサイト トラッキングを防止するため、Chrome ではほとんどのストレージ API と通信 API をサードパーティのコンテキストでパーティショニングしています。

実装ステータス

この機能は、Chrome 115 以降のすべてのユーザーに対して有効になっています。ストレージ パーティショニングの提案は、引き続き議論中です。

ストレージ パーティショニングとは

特定の種類のサイドチャネルによるクロスサイト トラッキングを防止するため、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 によって保存されたデータに、同じオリジン内のすべてのコンテキストからアクセスできなくなることを意味します。代わりに、同じオリジンと同じ最上位サイトのコンテキストでのみデータが使用できます。

変更前

パーティショニングのないストレージ API の図。
ストレージ パーティショニングの前に、example.com は a.com に埋め込まれているときにデータを書き込み、b.com に埋め込まれているときにデータを読み取ることができました。

変更後

パーティショニングを使用したストレージ API の図。
ストレージ パーティショニング後、example.com が b.com に埋め込まれている場合、a.com に埋め込まれている example.com のストレージにアクセスできなくなります。

連結された iframe でのストレージ パーティショニング

iframe に iframe が含まれていると、さらに複雑になります。これは、同じオリジンがチェーンの複数の場所に存在する場合に特に当てはまります。

たとえば、A1 に B の iframe が含まれており、その iframe に A2 の iframe が含まれており、A1 と A2 の両方が同じサイトにある場合です。パーティショニング時にトップレベルと現在のレベルのコンテキストのみを考慮する場合、iframe A2 は、サードパーティの iframe（B）が介在しているにもかかわらず、トップレベル（A1）と同じサイトにあるため、ファーストパーティと見なすことができます。A2 がデフォルトでパーティショニングされていないストレージにアクセスできる場合、A2 がクリックジャッキングなどのセキュリティ リスクにさらされる可能性があります。

この問題に対処するため、Chrome にはストレージ パーティション キーの一部として追加の「祖先ビット」が含まれています。これは、現在のコンテキストと最上位コンテキストの間にあるドキュメントが現在のコンテキストとクロスサイトである場合に設定されます。この場合、サイト B はクロスサイトであるため、A2 にビットが設定され、そのストレージは A1 からパーティショニングされます。

チェーンにクロスサイト コンテキストがない場合、ストレージはパーティショニングされません。たとえば、A2 の iframe を含むサイト A1 に A3 の iframe が含まれている場合、A1、A2、A3 はすべて同じサイトに存在するため、A1、A2、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 用に開発されています。これは、バケットという新しいコンセプトを使用して、IndexedDB や localStorage などのさまざまなストレージ API を統合します。バケットに保存されているデータとバケットに関連付けられているメタデータはパーティショニングされます。
  • Clear-Site-Data ヘッダー
    レスポンスに Clear-Site-Data ヘッダーを含めると、サーバーはユーザーのブラウザに保存されているデータを消去するようリクエストできます。キャッシュ、Cookie、DOM ストレージを削除できます。ヘッダーを使用すると、1 つのパーティション内のストレージのみが消去されます。
  • Blob URL ストア
    blob は、処理する元データを格納するオブジェクトです。blob URL を生成してリソースにアクセスできます。Blob URL ストアはパーティショニングされません。トップレベルのコンテキストで任意の blob URL に移動するユースケース（ディスカッション）をサポートするために、blob URL ストアはトップレベル サイトではなくエージェント クラスタでパーティショニングされる場合があります。この機能はまだテストできません。また、パーティショニング メカニズムは今後変更される可能性があります。

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 API はナビゲーション リクエストのタイミングを変更できるため、履歴スニッフィングなどのクロスサイト情報漏洩が発生する可能性があります。

したがって、サードパーティ コンテキストから登録された 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 でストレージ パーティショニングをオフにできます。

他のブラウザでも同様にテストして、パーティショニング ステータスを確認できます。

意見交換とフィードバックの提供