Cookies Having Independent Partitioned State、略称CHIPSという提案があります。

一言でいうと、サードパーティCookieをドメイン毎に分けます。

現在のサードパーティCookieをざっくり解説するとこうです。

・a.comに埋め込んだtracking.comには、tracking.com用のCookieが送信される。
・b.comに埋め込んだtracking.comには、tracking.com用のCookieが送信される。

a.comを見たときもb.comを見たときも、tracking.comには同じtracking.com用のCookieが送信されます。
このせいで、tracking.comは一人のユーザがa.comとb.comでそれぞれ行った行動を簡単に結合できてしまうわけです。

CHIPSでは、これを以下のように変更します。

a.comに埋め込んだtracking.comには、a.com+tracking.com用のCookieが送信される。
b.comに埋め込んだtracking.comには、b.com+tracking.com用のCookieが送信される。

呼び出し元のドメインごとに異なるCookieを発行します。
これによってどうなるかというと、tracking.comはa.comを見ているブラウザを追跡できるし、b.comを見ているブラウザも追跡できますが、a.comとb.comのブラウザを紐付けることができません。
アクセス解析などの用途にはこれまでどおりサードパーティCookieを使い続けることができるけど、複数のサイトからデータを結合して悪用する、みたいなことはできなくなるわけです。

Cookies Having Independent Partitioned State

Motivation

Webのプライバシーを向上させるため、ブラウザベンダはクロスサイトトラッキングの制限を予定しているか、あるいはすでに実施しています。
これにはサードパーティCookieの段階的廃止も含まれています。
サードパーティCookieは、トップレベルドメインのサイト以外で発行されたCookieのことであり、異なるドメイン間でユーザの行動を追跡することを可能にします。

まずred.comのフレームが埋め込まれたgreen.comを訪れます。
次にred.comのフレームが埋め込まれたblue.comを訪れると、green.comで埋め込んだCookieにアクセスすることができます。

サードパーティCookieは、トップレベルが異なるサイト間でユーザの行動を追跡することを可能にします。
現在のWebにおいては、ひとつのトップレベルサイトだけに限定された永続状態を必要とするようなCookieの使用例が存在します。
例としてはSaaS プロバイダ、ヘッドレスCMSプロバイダ、さらには信頼できないユーザコンテンツを提供するサンドボックスドメインなどです。

CHIPS: Opt-in Partitioned Cookies

このようなユースケースに対応するため、パーティション化したCookie、通称CHIPSの導入を提案します。
クロスサイトCookieにPartitioned属性を指定することで、CHIPSをオプトインできます。
この属性が存在する場合、そのクロスサイトCookieは、そのCookieが作成されたトップレベルでのみ使用可能になります。

この提案では以下のようになります。
red.comのフレームが埋め込まれたgreen.comを訪れCookieを指定した場合、トップレベルがgreen.comである場合にのみred.comにCookieが送信されます。
red.comのフレームが埋め込まれたblue.comを訪れても、そのCookieが送信されることはありません。

Firefoxでは、ETP Strictモードと呼ばれる機能により、全てのサードパーティCookieがデフォルトでこの動作をするようになりました。
またSafariでは、ITPのあるバージョンで一時的にこの機能を有効にしていました(後にロールバックした)。

Non-goals

トップレベルサイト自身のCookieについては本文書の対象外です。

同じ組織が所有する複数のドメイン間で共有されるサードパーティCookieの代替については、本文書の対象外です。
個のユースケースにおいてはFirst-Party Setsの使用を検討してください。

Cookie以外のストレージについては本文書の対象外です。

Key Scenarios

以下は、CHIPSが想定しているサードパーティCookieの使用例です。
まず現在のサードパーティCookieがどのように動くかを解説し、次いでクロスサイトCookieをトップレベルドメインで分割した理想的な動作について説明します。

Third-party store-finder service

Before unpartitioned third-party cookies are blocked

shoes.comのページでは、ユーザに店の地図を表示したいと考えています。
shoes.comは、地図サービスembed.maps.comを埋め込み、ユーザに近い店舗を選んだり、道順を調べるのに利用できる地図を表示することにしました。

ブラウザがshoes.comにアクセスすると、embed.maps.comはユーザの選んだ店舗を覚えておくためにCookieを発行します。

Set-Cookie: __Host-locationid=187; SameSite=None; Secure; HttpOnly; Path=/;

これ以降shoes.comにアクセスすると、埋め込みembed.maps.comへのリクエストには自動的にCookie: __Host-locationid=187;ヘッダが発行されるようになります。

これによって、embed.maps.comはユーザがshoes.comのよく見る場所を知ることができ、サーバ側でマップをレンダリングすることができます。
ユーザはよく行く店舗が最初から登録された状態でマップを見ることができるようになります。

しかしながら、shoes.com以外のサイトにユーザがアクセスした際にもこのCookieは送信されます。
従って、embed.maps.comはクロスサイトでユーザの行動を追跡することが可能になります。

After unpartitioned third-party cookies are blocked

クロスサイトCookieを使えない場合、embed.maps.comはLocalStorageなどCookie以外のブラウザストレージを使用することはできます。
しかしこの場合は、JavaScriptが実行されるまでembed.maps.comはユーザの設定にアクセスすることができません。
このためロード時間が長くなり、ユーザエクスペリエンスは低下します。

この文書の目的は、embed.maps.comがshoes.comに埋め込まれている場合にのみ送信可能なCookieを作れるようにするというものです。
ユーザが異なるサイトに移動したあとは、embed.maps.comが埋め込まれていたとしても、shoes.comで作成したCookieが送信されることはありません。

これによってembed.maps.comは、ブラウザにクロスサイト識別子を発行することなく、ユーザの好みを把握することが可能になります。

Design Principles

Opt-in partitioned cookies

この提案が既存の実装と異なる点は、サードパーティによるオプトインが必要であるという点です。

この原則は、長期的には最小権限の原則と一致します。
この新しい方法は、既存のサードパーティCookieより送信できる範囲を制限するため、Cookieの範囲は狭まります。
しかし、長期的には、このCookieがクロスサイトで使用できる唯一のCookieになります。

この新しい属性をサポートするために既存のソフトウェアやAPIを更新する必要があるかもしれませんが、予期せぬバグを引き起こすことなく移行するためには、オプトインが最適な方法であると考えます。

Only sent over secure protocols

分割されたサードパーティCookieは、安全なプロトコルからのみ設定・送信が可能です。
これによって、Cookieの気密性と完全性の弱さの一部を克服します。

Hostname-bound

分割されたサードパーティCookieは、ホスト名に紐付けられます。
この要件と、安全なプロトコルのみ有効という要件により、分割されたサードパーティCookieはオリジンに縛られることになります。
さらにポートごとに分割することも考えていますが、これはOrigin-Bound Cookiesが有効になったあとで実施されるべきです。

Avoid a large memory footprint

分割されたサードパーティCookieを導入する際の懸念のひとつは、ユーザマシン上での情報の急増です。
分割していないサードパーティCookieは、ひとつのサードパーティにつきCookieはひとつでした。
分割されたサードパーティCookieは、ひとつのサードパーティにつき、トップレベルのドメイン毎にそれぞれのCookieが登録されることになり、その結果ユーザマシンに設定されるCookieの量は格段に増えることになります。
分割されたサードパーティCookieをサポートするブラウザは、サードパーティが使用可能なCookieの数に制限を加える必要があるでしょう。
また実装時には、第三者がクロスサイト情報を調べることができないように制限を設計することも必要です。
これらの詳細については後述のLimit the number of cookies in a partitionおよび Applying the 180 cookies-per-domain limit in Alternative Designs for CHIPSを参照してください。

Detailed Design

Partitioning model

現在、Cookieは発行したサイトのホスト名やドメインをキーにしています。
CHIPSでは、Cookieは発行したサイトhost keyと発行されたサイトpartition keyの複合キーとなります。

Cookieのpartition keyは、Cookieを発行したエンドポイントへのリクエスト開始時にブラウザがアクセスしていたURL(スキームとドメイン)です。

ブラウザは、Partitioned属性を持っているCookieに対して、そのCookieと同じpartition key以外からのリクエストだった場合はCookieを送信してはいけません。

スキームがHTTPSであり、同一のFirst-Party Setであった場合は、異なるpartition keyでも同じCookieを共有することができます。
この場合partition keyの所有者はFirst-Party Setのオーナードメインになります。
これはファーストパーティごとにIDを分割するというChromeのプライバシー原則に沿った動作です。
分割していないサードパーティCookieを破棄することで、無関係なサイト間でのトラッキングを防止します。

httpスキームが存在する場合、First-Party Setは適用されません。
First-Party Setはセキュアオリジンでのみサポートされます。

Opt-in cookie attribute

Cookieに新たな属性Partitionedを追加します。
この属性が存在する場合、サードパーティCookieはそのCookieが設定されたのと同じドメインであれば送信されることになります。
Partitioned属性の無いCookieは、いずれサードパーティには送信されなくなります。

Using Set-Cookie with Partitioned

以下は、分割されたサードパーティCookieを発行するSet-Cookieの例です。

Set-Cookie: __Host-SID=31d4d96e407aad42; SameSite=None; Secure; HttpOnly; Path=/; Partitioned;
Set-Cookie: abc=21ef; SameSite=None; Secure // ブロックされてサードパーティには送信されない

Attaching a Partitioned cookie to a request

サードパーティへのリクエストでは、分割されたサードパーティCookieがリクエストヘッダに設定されます。

Cookie: __Host-SID=31d4d96e407aad42

Example usage

以下は、分割されたサードパーティCookieをどのように使用できるかを説明する例です。
全てのリソースは安全なプロトコルが使用されている前提です。

上で出たshoes.comとembed.maps.comの例をもう一度考えてみましょう。
お気に入り店舗などshoes.comに関する情報を保存したいとします。

embed.maps.comは、Partitioned属性が設定されていないかぎりshoes.comに対してCookieを発行することはできません。

Set-Cookie: __Host-locationid=187; SameSite=None; Secure; HttpOnly; Path=/; Partitioned;

分割されたサードパーティCookieを設定した後は、shoes.com内のページからembed.maps.comを呼び出すと次のリクエストヘッダが送信されます。

Cookie: __Host-locationid=187;

しかし、別のサイトに移動すると、そこからembed.maps.comへのリンクがあっても、ブラウザはCookieを送信しません。
これによって、embed.maps.comはshoes.comのユーザのお気に入り店舗を保存することができます。
しかし、他のサイトからはこのCookieが送信されないため、異なるサイト間でのユーザの活動を追跡することはできなくなります。

How to enforce design principles

Partitioned cookies must use the __Host- prefix

分割されたサードパーティCookieには、__Host-というプレフィックスが必須となります。
ユーザエージェントは、__Host-プレフィックスを持たない分割されたサードパーティCookieは受け入れません。

__Host-プレフィックスは、CookieにSecureとPath=/を必須とし、さらにDomain属性を無視します。
この解釈により、分割されたサードパーティCookieは安全なオリジンからのみ設定可能で、安全なオリジンにのみ送信されることになります。
この要求事項により、分割されたサードパーティCookieは可能なかぎりオリジンだけに紐付けられます。

HttpOnly attribute

分割されたサードパーティCookieにはHttpOnly属性も必須にすることができますが、ユーザエージェントはそれを強制しません。

SameSite attribute

SameSite属性はNoneのみが許可されます。
SameSite=None以外の設定は実質的にSameSite Cookieであるため、サードパーティに送信することはできません。

SameParty attribute

ユーザエージェントは、SameParty属性がある分割されたサードパーティCookieを拒否します。

Limit the number of cookies a third party can use in a single partition

分割されたサードパーティCookieで使用できるCookieの数は、既存の閾値(Chromeではドメイン毎に180個)よりずっと少なくする必要があります。
ユーザエージェントは、分割されたサードパーティCookieで使用できるCookieの数を1つ、あるいは少数に制限します。
サードパーティがサブドメインを使って制限を回避できなくするために、この制限はドメイン単位で行われます。

またユーザエージェントは、分割されたサードパーティCookie全体の数にグローバルな制限を設けることができます。
これは、ユーザが多数のサイトを訪れることにより分割されたサードパーティCookieが無制限に増えることを防ぐためです。

Clearing partitioned cookies

サードパーティがClear-Site-Dataを送信した場合、ユーザエージェントはそのサイトの分割されたサードパーティCookieをクリアします。
他のサイトの分割されたサードパーティCookieを削除してはいけません。
これはクロスサイトトラッキングを防ぐためです。

Handling older or incompatible clients

新しいCookie属性Partitionedは、古いブラウザでは無視され、デフォルトの動作になります。

Service workers

Service workersはCookieStoreAPI経由で、もしくは直接fetchのHTTPリクエストを送ることでCookieにアクセスできます。

分割していないサードパーティCookieは、HttpOnlyであってもService workersから利用することができます。
分割されたサードパーティCookieは、分割されたService workersからのみ利用することができます。

Safariは既にService workersを登録したドメインで分割しており、Service workersはインストールしたときのドメインと同じドメインのみとしか対話できません。
このようにService workersが分割されている場合、分割されたサードパーティCookieをService workersに公開してもクロスサイトトラッキングの心配はありません。

FirefoxではDynamic Partitioningを有効にするとService workersが使えなくなります。
現在は分割されたService workersの実装に取り組んでいます。

Browser extensions

ブラウザ拡張機能が他サイトのリソースを読み込む場合のパーティションキーについて。

拡張機能がそのフレームのホスト権限を所有している場合は、パーティションキーは拡張機能のサイトではなくフレームのサイトになります。
それ以外の場合、パーティションキーは拡張機能のサイトです。

Security and Privacy Considerations

この提案は、新しいCookie属性に対応するついでに、__Host-プレフィックスとSecure属性を必須とすることで、機能をSecure Contextsに制限します。

分割されたクロスサイトCookieは、分割していないクロスサイトCookieに比べてCSRF攻撃の影響を受けにくくなります。
分割されたクロスサイトCookieは、そのCookieが実際に作成されたサイトを訪れないかぎり送信されないため、悪意のあるサイトが分割されたクロスサイトCookieを偽装することができないからです。

このproposalでは、クロスサイトCookieの改善案を提供することで、クロスサイトトラッキングさせないようにします。
これは、サードパーティCookieを削除するという、Webの大きなプライバシー改善に向けた第一歩となります。

検討事項のひとつとして、分割されたクロスサイトCookieは後述のドメインあたり180個のCookie制限の対象としてはいけません。
さもなければ、この制限を利用してクロスサイトトラッキングを引き起こせる可能性があるためです。

プライバシーに関するもうひとつの注意点は、host_permissionsを持つブラウザ拡張機能は分割されたクロスサイトCookieの制限を乗り越えることができるということです。
拡張機能パーティションを超えてCookieを照会・保存することができますし、拡張機能の性質上、この機能を制限することはできません。

Alternate Designs for CHIPS

代替手段など。

Limit the number of cookies in a partition

ユーザエージェントは、1つのパーティションに与えるCookieの数を宣言することができます。
これによって、1つのパーティションがCookieを占有することを防ぐことができます。

ただし、パーティションごとにグローバルな制限は与えません。
これを強制すると、サイドチャネル攻撃が可能になるからです。

たとえば、パーティションごとに分割されたクロスサイトCookieの上限が1つで、グローバル制限が10だったとしましょう。
悪意のある第三者はとあるトップレベルドメイン1p.comにevil[1-10].comを埋め込み、それぞれにサードパーティCookieを発行します。
さらに他の第三者が1p.comに分割されたクロスサイトCookieを設定すると、evil[1-10].comのCookieのひとつが削除されます。
悪意のある第三者はこの情報を利用することで、ユーザがログインしたか、他者のロケータサービスを使用しているかなどの情報を知ることができます。

Applying the 180 cookies-per-domain limit

メモリの大量消費を防ぐため、ひとつのドメインに対して発行されるCookieの個数を制限する必要があります。
Chromeではドメイン毎に180個です。
しかし、この方法は悪意のある第三者に再度チャネル攻撃を生じさせる可能性があります。

たとえば1p.comを訪れたときにevil.comへのCookieを180個埋め込みます。
次にトップレベルドメインevil.comに訪れたとき、evil.comはCookieをひとつだけ設定します。
ユーザがその後1p.comに戻ったときに、そこから呼び出されたCookieの数を数えることで、ユーザがevil.comを訪れたかどうかを判定することができます。

この攻撃から、evil.comが特定のユーザに対してどの程度の情報を得られるかは未調査です。
この攻撃を回避するために、どのようにグローバルおよびパーティションごとの制限を設けるべきであるかは未決定です。

Requiring the __Secure- prefix

__Host-プレフィックスを持つCookieは、__Secure-プレフィックスを暗黙的に包含します。
分割されたクロスサイトCookieに前者を要求する場合、後者と要求した場合と同じプロパティが存在することが保証されます。

Not requiring the __Host- prefix

CookieにPartitioned属性を要求しつつ__Host-プレフィックスを要求しないという選択肢もありえます。
すなわちSecureとPath=/を必須とし、Domain属性を禁止します。

理由はふたつあります。
ひとつはPartitioned属性を認識しない、かつ__Host-プレフィックスを認識するブラウザでも動作する点です。
もうひとつは、属性と接頭辞という複数種類のセマンティクスが混在することによって見通しが悪くなるという問題を回避できることです。

DNS CNAME’ing

Webサイトの中には、CNAMEレコードを使ってサブドメインをサードパーティに移譲しているところもあります。
たとえばmyblog.exampleというサイトにfoo.myblog.exampleというサブドメインをつくり、そしてそのドメインを、専用のサードパーティ用エンドポイントmyblog.cms.exampleにCNAMEでマッピングします。
こうすると、ブラウザはfoo.myblog.exampleをファーストパーティとして扱うので、*.myblog.example用のCookieがmyblog.cms.exampleに送られてしまうことになります。
クロスサイトCookieの制限を突破することができました。

このパターンには、セキュリティ上の問題点が幾つも存在します。
・foo.myblog.exampleに発行されたSSL証明書をmyblog.cms.exampleにも適用する必要があります。
・*.myblog.exampleで発行した全てのCookieをmyblog.cms.exampleに送ることができるため、他のサブドメインで発行した重要なデータも送られるかもしれません。

References and Acknowledgements

References

cfredric/sameparty
Chromium Blog: Building a more private web: A path towards making third party cookies obsolete
Clear-Site-Data for partitioned storage can be used for cross-site tracking · Issue #11 · privacycg/storage-partitioning
Cookie Store API Explainer | cookie-store
cookie_monster.h - Chromium Code Search
draft-ietf-httpbis-rfc6265bis-07 - Cookies: HTTP State Management Mechanism
[Dynamic FPI] The user and password for Facebook did not transfer to messenger.com
Firefox 86 Introduces Total Cookie Protection - Mozilla Security Blog
[FirstPartyIsolation] Failed to sign in to the pixnet.net
Fx with FPI feature wrongly displays that sign-in on youtube has failed even though it did not
Googleusercontent.com can trip you up, if you disable third-party cookies · Kerika
Headless CMS Github Gist · LOGIN-issues.md
Headless content management system - Wikipedia
HTML Standard
Intelligent Tracking Prevention 2.1 | WebKit
Isolate service workers and DOM cache by first party domain
Let embedees optionally request access to partitioned cookies and storage · Issue #75 · privacycg/storage-access
michaelkleber/privacy-model: A Potential Privacy Model for the Web: Sharding Web Identity
mikewest/http-state-tokens: Incrementally better HTTP state management.
Principle of least privilege - Wikipedia
privacycg/first-party-sets
privacycg/storage-partitioning: Client-Side Storage Partitioning
SameSite=None: Known Incompatible Clients - The Chromium Projects
sbingler/Origin-Bound-Cookies
Secure Contexts
Software as a service use case for FPS · Issue #33 · privacycg/first-party-sets
State Partitioning - Mozilla | MDN
View Source shows source code of login page instead of current webpage on local django server
Workers at Your Service | WebKit
[Working] Fix Google Drive Downloads Not Working in Microsoft Edge – Gadgets To Use

感想

なんてこった、これで万事解決めでたしめでたしじゃないか。
FLoCやらFirst-Party Setsみたいなゴミより、こっちのほうをもっと推進するべきじゃないですかね？

この技術だけではクロスサイトトラッキングはできませんが、他のブラウザフィンガープリントなどを用いることでa.com+tracking.com用のCookieとb.com+tracking.com用のCookieが同じブラウザであると、それなりの精度で特定することは可能です。
そうなってしまうと結局ただのサードパーティCookieになるので、そのあたりの対処もやはり必要となってきます。
とはいえ、現在のような筒抜けCookieよりは遥かにマシであることには違いありません。
もはや即座にこっちをデフォルトにしていいレベルですよ。

本プロジェクトはInitial commitが2021/04/22であり、最近始まったばかりです。
W3C配下のプロジェクトだというのにコミットもほぼDCtheTall一人であり、個人プロジェクトと見紛うレベルです。
ただ、この人はGoogleの中の人なので、いずれこのプロジェクトもChromeのメインストリームに組み込まれることになるかもしれません。
もちろんこのまま立ち消えになるかもしれません。
FLoCなんてものをごり押ししている時点でCHIPSの未来もあまり明るくなさそうな気はしますが、果たして今後どうなることでしょうね。

あとどうでもいいけど、CHIPS関連情報を調べようとするとGoogle Original Chipsが引っかかってきてめっちゃ検索妨害される。