Google Chromeが勧めるプライバシーサンドボックス技術のひとつ、CHIPSってなんぞ

[Cookies Having Independent Partitioned State](https://github.com/WICG/CHIPS)、略称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のことであり、異なるドメイン間でユーザの行動を追跡することを可能にします。

![01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26088/378537b2-49d6-94ae-e732-919e0c11f12e.png)

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

サードパーティCookieは、トップレベルが異なるサイト間でユーザの行動を追跡することを可能にします。
現在のWebにおいては、ひとつのトップレベルサイトだけに限定された永続状態を必要とするようなCookieの使用例が存在します。
例としては[SaaS](https://github.com/privacycg/first-party-sets/issues/33)[プロバイダ](https://github.com/privacycg/storage-access/issues/74)、[ヘッドレスCMSプロバイダ](https://gist.github.com/rexxars/42d870946d82a3daa0e35b238e0b7d7a)、さらには信頼できないユーザコンテンツを提供する[サンドボックス](https://blog.kerika.com/googleusercontent-com-can-trip-you-up-if-you-disable-third-party-cookies/)[ドメイン](https://gadgetstouse.com/blog/2020/12/11/fix-google-drive-downloads-not-working-in-microsoft-edge/)などです。

## 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が送信されることはありません。

![02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26088/d6b29c32-4ff2-f53e-7d3d-5fdb60bd2842.png)

:::note info
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を発行します。

```js
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

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

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

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

### Only sent over secure protocols

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

### Hostname-bound

分割されたサードパーティCookieは、ホスト名に紐付けられます。
この要件と、安全なプロトコルのみ有効という要件により、分割されたサードパーティCookieはオリジンに縛られることになります。
さらにポートごとに分割することも考えていますが、これは[Origin-Bound Cookies](https://github.com/sbingler/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](https://qiita.com/rana_kualu/items/13a77f76257767a23643)であった場合は、異なる`partition key`でも同じCookieを共有することができます。
この場合`partition key`の所有者はFirst-Party Setの[オーナードメイン](https://github.com/privacycg/first-party-sets#declaring-a-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`の例です。

```js
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がリクエストヘッダに設定されます。

```js
Cookie: __Host-SID=31d4d96e407aad42
```

### Example usage

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

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

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

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

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

```js
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個](https://source.chromium.org/chromium/chromium/src/+/master:net/cookies/cookie_monster.h;l=104;drc=da465ccade3a693e1deac3bf01b1c83d12dbf553))よりずっと少なくする必要があります。
ユーザエージェントは、分割されたサードパーティCookieで使用できるCookieの数を1つ、あるいは少数に制限します。
サードパーティがサブドメインを使って制限を回避できなくするために、この制限はドメイン単位で行われます。

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


### Clearing partitioned cookies

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

### Handling older or incompatible clients

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

### Service workers

`Service workers`は[CookieStore](https://wicg.github.io/cookie-store/explainer.html)API経由で、もしくは直接`fetch`のHTTPリクエストを送ることでCookieにアクセスできます。

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

Safariは既に`Service workers`を[登録したドメインで分割](https://webkit.org/blog/8090/workers-at-your-service/)しており、`Service workers`はインストールしたときのドメインと同じドメインのみとしか対話できません。
このように`Service workers`が分割されている場合、分割されたサードパーティCookieを`Service workers`に公開してもクロスサイトトラッキングの心配はありません。

Firefoxでは[Dynamic Partitioningを有効にするとService workersが使えなくなります](https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning)。
現在は[分割された`Service workers`の実装に取り組んでいます](https://bugzilla.mozilla.org/show_bug.cgi?id=1495241)。


### Browser extensions

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

拡張機能がそのフレームの[ホスト権限](https://developer.mozilla.org/ja/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#host_permissions)を所有している場合は、パーティションキーは拡張機能のサイトではなくフレームのサイトになります。
それ以外の場合、パーティションキーは拡張機能のサイトです。


## Security and Privacy Considerations

この提案は、新しいCookie属性に対応するついでに、`__Host-`プレフィックスと`Secure`属性を必須とすることで、機能を[Secure Contexts](https://w3c.github.io/webappsec-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レコードを使って[サブドメインをサードパーティに移譲している](https://qiita.com/rana_kualu/items/456935e051d2e0cf6f78)ところもあります。
たとえば`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](https://github.com/cfredric/sameparty)
[Chromium Blog: Building a more private web: A path towards making third party cookies obsolete](https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html)
[Clear-Site-Data for partitioned storage can be used for cross-site tracking · Issue #11 · privacycg/storage-partitioning](https://github.com/privacycg/storage-partitioning/issues/11)
[Cookie Store API Explainer | cookie-store](https://wicg.github.io/cookie-store/explainer.html)
[cookie_monster.h - Chromium Code Search](https://source.chromium.org/chromium/chromium/src/+/master:net/cookies/cookie_monster.h;l=104;drc=da465ccade3a693e1deac3bf01b1c83d12dbf553)
[draft-ietf-httpbis-rfc6265bis-07 - Cookies: HTTP State Management Mechanism](https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07)
[[Dynamic FPI] The user and password for Facebook did not transfer to messenger.com](https://bugzilla.mozilla.org/show_bug.cgi?id=1629062)
[Firefox 86 Introduces Total Cookie Protection - Mozilla Security Blog](https://blog.mozilla.org/security/2021/02/23/total-cookie-protection/)
[[FirstPartyIsolation] Failed to sign in to the pixnet.net](https://bugzilla.mozilla.org/show_bug.cgi?id=1316019)
[Fx with FPI feature wrongly displays that sign-in on youtube has failed even though it did not](https://bugzilla.mozilla.org/show_bug.cgi?id=1319728)
[Googleusercontent.com can trip you up, if you disable third-party cookies · Kerika](https://blog.kerika.com/googleusercontent-com-can-trip-you-up-if-you-disable-third-party-cookies/)
[Headless CMS Github Gist · LOGIN-issues.md](https://gist.github.com/rexxars/42d870946d82a3daa0e35b238e0b7d7a)
[Headless content management system - Wikipedia](https://en.wikipedia.org/wiki/Headless_content_management_system)
[HTML Standard](https://html.spec.whatwg.org/)
[Intelligent Tracking Prevention 2.1 | WebKit](https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/)
[Isolate service workers and DOM cache by first party domain](https://bugzilla.mozilla.org/show_bug.cgi?id=1495241)
[Let embedees optionally request access to partitioned cookies and storage · Issue #75 · privacycg/storage-access](https://github.com/privacycg/storage-access/issues/75)
[michaelkleber/privacy-model: A Potential Privacy Model for the Web: Sharding Web Identity](https://github.com/michaelkleber/privacy-model)
[mikewest/http-state-tokens: Incrementally better HTTP state management.](https://github.com/mikewest/http-state-tokens)
[Principle of least privilege - Wikipedia](https://en.wikipedia.org/wiki/Principle_of_least_privilege)
[privacycg/first-party-sets](https://github.com/privacycg/first-party-sets)
[privacycg/storage-partitioning: Client-Side Storage Partitioning](https://github.com/privacycg/storage-partitioning)
[SameSite=None: Known Incompatible Clients - The Chromium Projects](https://www.chromium.org/updates/same-site/incompatible-clients)
[sbingler/Origin-Bound-Cookies](https://github.com/sbingler/Origin-Bound-Cookies)
[Secure Contexts](https://w3c.github.io/webappsec-secure-contexts)
[Software as a service use case for FPS · Issue #33 · privacycg/first-party-sets](https://github.com/privacycg/first-party-sets/issues/33)
[State Partitioning - Mozilla | MDN](https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/State_Partitioning)
[View Source shows source code of login page instead of current webpage on local django server](https://bugzilla.mozilla.org/show_bug.cgi?id=1651134)
[Workers at Your Service | WebKit](https://webkit.org/blog/8090/workers-at-your-service/)
[[Working] Fix Google Drive Downloads Not Working in Microsoft Edge – Gadgets To Use](https://gadgetstouse.com/blog/2020/12/11/fix-google-drive-downloads-not-working-in-microsoft-edge/)



# 感想

なんてこった、これで万事解決めでたしめでたしじゃないか。
[FLoC](https://qiita.com/rana_kualu/items/e470f0303e6b3a429c09)やら[First-Party Sets](https://qiita.com/rana_kualu/items/13a77f76257767a23643)みたいなゴミより、こっちのほうをもっと推進するべきじゃないですかね？

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

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


あとどうでもいいけど、CHIPS関連情報を調べようとすると[Google Original Chips](https://gourmet.watch.impress.co.jp/docs/news/1351688.html)が引っかかってきてめっちゃ検索妨害される。