Cookie の Independent Partitioned State（CHIPS）

デベロッパーは、トップレベル サイト別のストレージに「パーティション化して」保存される Cookie にオプトインできます。

実装ステータス

• Chrome 114 以降ではデフォルトでサポートされています。
• Chrome 100 ～ 116 でオリジン トライアルが利用可能になりました。
• テストの目的とリリースの目的を確認します。

CHIPS とは

Cookies Having Independent Partitioned State（CHIPS）により、デベロッパーは、トップレベル サイトごとに個別の Cookie の格納場所を使用して、Cookie をパーティショニングされたストレージに取り込むことができます。これにより、ユーザーのプライバシーとセキュリティが向上します。

パーティショニングがない場合、サードパーティのサービスは Cookie を使用することにより、多くの無関係なトップレベル サイトでユーザーをトラッキングし、それらの情報を結合できます。いわゆる「クロスサイト トラッキング」です。

サードパーティ Cookie がブロックされている場合、CHIPS、Storage Access API、関連ウェブサイト セットは、iframe などのクロスサイト コンテキストから Cookie を読み書きする唯一の方法です。

CHIPS では、トップレベルのコンテキストごとにパーティション化されるクロスサイト Cookie に対応するために、新しい Cookie 属性 Partitioned が導入されています。

Set-Cookie ヘッダー:

Set-Cookie: __Host-name=value; Secure; Path=/; SameSite=None; Partitioned;

JavaScript:

document.cookie="__Host-name=value; Secure; Path=/; SameSite=None; Partitioned;"

パーティション化されたサードパーティの Cookie は、最初に設定されたトップレベル サイトに関連付けられ、他からアクセスすることはできません。これにより、サードパーティのサービスによって設定された Cookie は、最初に設定されたトップレベル サイトの同じ埋め込みコンテキスト内でのみ読み取ることができます。

パーティション化された Cookie では、あるユーザーがサイト A にアクセスし、サイト C から埋め込まれたコンテンツによって Cookie が Partitioned 属性付きで設定されると、その Cookie は、サイト A に埋め込まれている場合にサイト C で設定された Cookie 専用のパーティション化された格納場所に保存されます。ブラウザでは、トップレベル サイトが A の場合にのみ、その Cookie を送信します。

このユーザーが新しいサイト、たとえばサイト B にアクセスしても、埋め込みの C フレームでは、C がサイト A に埋め込まれている場合に設定された Cookie を受け取ることはありません。

ユーザーがトップレベル サイトとしてのサイト C にアクセスした場合も、C が A に埋め込まれている場合に設定されたパーティション化された Cookie がリクエストで送信されることはありません。

ユースケース

たとえば、サイト retail.example で、サードパーティのサービス support.chat.example を使用してサイトにチャット サポート用のボックスを埋め込むとします。現在、埋め込み可能なチャット サービスの多くは Cookie を使用して状態を保存しています。

クロスサイト Cookie を設定できない場合、support.chat.example は状態を保存するための代替手段（多くの場合、より複雑な方法）を見つける必要があります。または、トップレベル ページに埋め込む必要がありますが、この場合、support.chat.example スクリプトが retail.example で昇格された権限（認証 Cookie にアクセスできるなど）を持てるため、リスクが発生します。

CHIPS は、パーティショニングされていない Cookie に関連するリスクを回避しながら、クロスサイト Cookie の使用を継続するための簡単なオプションを提供します。

CHIPS のユースケースの例には、以下のような、クロスサイトのサブリソースで 1 つのトップレベル サイトのユーザー アクティビティをスコープとするセッション概念または永続状態が必要となるあらゆるシナリオが含まれます。

• サードパーティのチャットの埋め込み
• サードパーティのマップの埋め込み
• サードパーティの支払いの埋め込み
• サブリソースの CDN 負荷分散
• ヘッドレス CMS プロバイダ
• 信頼できないユーザー コンテンツを配信するサンドボックス ドメイン（googleusercontent.com、githubusercontent.com など）
• Cookie を使用して自社サイトでの認証ステータスに基づきアクセス制御したコンテンツを配信しているサードパーティの CDN（例: サードパーティの CDN でホストされているソーシャル メディア サイト上のプロフィール写真）
• Cookie を使用したリモート API をリクエストに組み込んでいるフロントエンドのフレームワーク
• パブリッシャーごとに状態をスコープする必要がある埋め込み広告（たとえば、そのウェブサイトのユーザーの広告設定をキャプチャする）

CHIPS がオプトイン パーティショニング モデルを使用する理由

パーティション化されていないサードパーティの Cookie へのアクセスがブロックされている場合、別のパーティション化の方法もいくつか試みられています。

Firefox は、ETP Strict モードとプライベート ブラウジング モードではすべてのサードパーティの Cookie をデフォルトでパーティション化すると発表しました。これにより、すべてのクロスサイト Cookie がトップレベル サイトごとにパーティション化されます。ただし、オプトインしていないサードパーティの Cookie をパーティション化した場合は予期しないバグが発生する可能性があります。これは、一部のサードパーティのサービスでは、パーティション化されていないサードパーティの Cookie を想定したサーバーを構築しているためです。

Safari は、これまでにヒューリスティックに基づく Cookie のパーティション化を試みましたが、最終的には、デベロッパーの混乱を招くなどの理由により、それらをすべてブロックすることを決めました。最近は、オプトインに基づくモデルに関心を示しています。

すでに実装されている Cookie のパーティション化と CHIPS の違いは、サードパーティのオプトインです。（パーティション化されていない）サードパーティの Cookie の廃止後は、クロスパーティのリクエストで送信するためには Cookie を新しい属性付きで設定する必要があります。

サードパーティの Cookie は引き続き存在しますが、Partitioned 属性を使用することにより、より限定的でより安全な種類の Cookie 動作にオプトインできるようになります。CHIPS は、各サービスが今後のサードパーティの Cookie がない環境にスムーズに移行できるようにするための重要なステップです。

Cookie パーティショニングの技術設計

現在の Cookie には、設定元のサイトのホスト名またはドメインがキー（ホストキー）として設定されています。

たとえば、https://support.chat.example からの Cookie の場合、ホストキーは ("support.chat.example") となります。

CHIPS では、パーティション化にオプトインしている Cookie には、ホストキーとパーティション キーの 2 つが設定されるようになります。

Cookie のパーティション キーは、Cookie を設定したエンドポイントへのリクエストの開始時にブラウザがアクセスしていたトップレベル URL のサイト（スキームと登録可能なドメイン）になります。

https://support.chat.example が https://retail.example に埋め込まれた上記の例の場合、トップレベル URL は https://retail.example となります。

この場合のパーティション キーは ("https", "retail.example") になります。

同様に、リクエストのパーティション キーは、リクエストの開始時にブラウザがアクセスしているトップレベル URL のサイトになります。ブラウザは、Partitioned 属性が設定された Cookie を、その Cookie と同じパーティション キーを含むリクエストに対してのみ送信する必要があります。

以下は、CHIPS の適用前と適用後で Cookie のキーがどう変わるかを、上記の例を使って示しています。

CHIPS の適用前

key=("support.chat.example")

CHIPS の適用後

key={("support.chat.example"),("https", "retail.example")}

セキュリティ設計

適切なセキュリティ対策を促進するため、CHIPS では、Cookie の設定と送信は安全なプロトコルを介してのみ行われます。

• パーティション化された Cookie は Secure で設定する必要があります。
• パーティション化された Cookie を設定する際は（登録可能なドメインではなく）ホスト名に紐づけられるように __Host- プレフィックスを使用することをおすすめします。

例:

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

CHIPS の代替手段

Storage Access API と関連する関連ウェブサイト セット（RWS）は、特定のユーザー向け目的でクロスサイト Cookie へのアクセスを制限するウェブ プラットフォームのメカニズムです。

これらは、クロスサイトのパーティショニングされていない Cookie へのアクセスが必要な場合の CHIPS パーティショニングの代替手段です。

複数の関連サイトに埋め込まれたサービスで同じ Cookie を利用できるようにする必要がある場合は、Storage Access API と関連ウェブサイト セットの使用を検討してください。

CHIPS は、サービスが複数のサイトにまたがる分離されたコンポーネントとして機能する機能を提供します。この場合、同じ Cookie を複数のサイトで利用できるようにする必要はありません。サービスがパーティション化された Cookie を設定した場合、そのパーティション キーはトップレベル サイトになり、その Cookie はサービスを使用している他のサイトでは利用できません。

関連ウェブサイト セットの設計は Storage Access API に依存しており、CHIPS パーティショニングと統合されていません。RWS 内のサイト間で共有される Cookie パーティションに依存するユースケースがある場合は、GitHub の問題で例とフィードバックを提供できます。

デモ

このデモでは、パーティション分割された Cookie の仕組みと、DevTools での検査方法について説明します。

サイト A がサイト B の iframe を埋め込み、サイト B が JavaScript を使用してパーティション化された Cookie とパーティション化されていない Cookie の 2 つの Cookie を設定します。サイト B は、document.cookie を使用してその場所からアクセス可能なすべての Cookie を表示します。

サードパーティ Cookie がブロックされている場合、サイト B はクロスサイト コンテキストで Partitioned 属性付きの Cookie の設定とアクセスのみが可能になります。

サードパーティ Cookie が許可されている場合、サイト B はパーティション分割されていない Cookie を設定してアクセスすることもできます。

前提条件

1. Chrome 118 以降。
2. chrome://flags/#test-third-party-cookie-phaseout にアクセスしてこの設定を有効にします。

DevTools を使用してパーティション化された Cookie を検査する

1. https://chips-site-a.glitch.me にアクセスします。
2. Control+Shift+J（Mac の場合は Command+Option+J）を押して、デベロッパー ツールを開きます。
3. [アプリケーション] タブをクリックします。
4. [Application] > [Storage] > [Cookies] に移動します。
5. [https://chips-site-b.glitch.me] をクリックします。

選択したオリジンのすべての Cookie が DevTools に表示されます。

サイト B はクロスサイト コンテキストでのみパーティション Cookie を設定できます。パーティション化されていない Cookie はブロックされます。

• 最上位サイトのパーティション キー https://chips-site-a.glitch.me を持つ __Host-partitioned-cookie が表示されます。

__Host-partitioned-cookie のパーティション キー。

1. [Go to Site B] をクリックします。
2. DevTools で、[Application] > [Storage] > [Cookies] に移動します。
3. [https://chips-site-b.glitch.me] をクリックします。

このシナリオでは、トップレベル コンテキストでサイト B にアクセスしているため、両方の Cookie を設定してアクセスできます。

• unpartitioned-cookie に空のパーティション キーがある。
• __Host-partitioned-cookie Cookie にパーティション キー https://chips-site-b.glitch.me があります。

B をトップレベル サイトとしてアクセスしたときに、DevTools の [Application] タブに表示されるサイト B の Cookie。__Host-partitioned-cookie にはパーティション キー https://chips-site-b.glitch.me があります。

サイト A に戻ると、unpartitioned-cookie はブラウザに保存されますが、サイト A からアクセスすることはできません。

1. [Go to Site A] をクリックします。
2. [ネットワーク] タブをクリックします。
3. [https://chips-site-b.glitch.me] をクリックします。
4. [Cookie] タブをクリックします。

サイト A にアクセスしている間は、最上位サイト https://chips-site-a.glitch.me のパーティション キーを含む __Host-partitioned-cookie が表示されます。

[除外した Cookie リクエストを表示] をオンにすると、パーティショニングされていない Cookie がブロックされたことが DevTools に表示されます。この Cookie は黄色でハイライト表示され、ツールチップに「この Cookie はユーザー設定によりブロックされました」と表示されます。

[Application] > [Storage] > [Cookies] で https://chips-site-b.glitch.me をクリックすると、次の内容が表示されます。

• unpartitioned-cookie: 空のパーティション キー。
• パーティション キー https://chips-site-a.glitch.me を含む __Host-partitioned-cookie Cookie。

DevTools の [Application] タブに表示されたサイト B の Cookie。

Cookie を消去

デモをリセットするには、サイトの Cookie をすべて削除します。

• Control+Shift+J（Mac の場合は Command+Option+J）を押して、デベロッパー ツールを開きます。
• [アプリケーション] タブをクリックします。
• [Application] > [Storage] > [Cookies] に移動します。
• https://chips-site-b.glitch.me を右クリックします。
• [消去] をクリックします。

リソース

• GitHub: 解説の確認、質問の投稿、意見交換を行えます。
• デベロッパー サポート: プライバシー サンドボックス デベロッパー サポート リポジトリで質問や意見交換を行えます。