ChromeでCookieのSameParty属性の開発が進められている (コミット)。
現在のところ「SameParty cookie attribute explainer」に説明が書かれている。
今回は、CookieのSameParty属性について簡単にメモしていく。
背景
トラッキング対策、プライバシーの観点でサードパーティクッキーは制限する方向に進んでいる。その制限をSame Partyの場合に緩和する仕組みを提供するのがSameParty属性の話である。
例えば、同一主体により運営されているドメインの異なるサイト (例えば、google.co.jp, google.co.uk) 間においては、いわゆる(cross-site contextsで送られる)サードパーティクッキーを許可しようという話です。
もともとは、First-Party Setsを活用しSameSite属性にFirstPartyLax/FirstPartyStrictという２つの値を新しく定義していた。しかし、SameSite属性自体はCSRFなどを防ぐ、セキュリティの目的で導入されたものでした。
このSame Partyでクッキーを取り扱うことはプライバシーの観点の話なので、別途SameParty属性が定義された形のようだ。
First-Party Sets
SameParty属性のまえに、まずFirst-Party Setsの説明をする。
例えば、Webでは、全く異なるドメインが同一主体によって運営されているものがあります。
- https://google.com、https://google.co.uk、https://youtube.com
- https://apple.com、 https://icloud.com
- https://amazon.com、https://amazon.de
こういった、ドメインが "First Party" であるというのを分かるようにするのが「First-Party Sets」です。
各ドメインがお互いに一つのpartyであることを宣言しあう形となる。
詳細については、以前記事を参照
asnokaze.hatenablog.com
CookieのSameParty属性
取り扱い方は、その他の属性と同様である。Set-Cookieやdocument.cookieを介して設定できる。
Set-Cookie: cookie=tasty; SameSite=Lax; Secure; SameParty
さて、次にどのようなときにクッキーが送られ、どのようなときにクッキーが送られないのか見ていく。サードパーティクッキーの制限を緩和する位置づけと見ると分かりやすいかと思う。
「SameParty cookie attribute explainer」にかかれている具体例を拝借する。
(画像が見にくいので、オリジナルを参照: https://github.com/cfredric/sameparty/blob/main/images/same_party_table.png)
owner.exampleと下記のドメインがFirst-Party Setsを用いた同一partyであるとする
- member1.example
- member2.example
このとき
- 同一party間でリソースが埋め込まれている場合はクッキーが飛ぶ。
- other.example のような同一party外のページに埋め込まれた場合はクッキーが飛ばない
という挙動となる
){kind=link}