[OUTDATED] First-Party Sets と SameParty 属性

多くの組織には、brandx.site や fly-brandx.site などの異なるドメイン名に関連するサイト、または example.com、example.rs、example.co.uk のように異なる国のドメインに関連するサイトがあります。

ブラウザは、ウェブ上のプライバシーを改善するためにサードパーティの Cookie を廃止する方向に進んでいますが、このようなサイトは、多くの場合 Cookie に依存して、ドメイン全体で状態を維持し、それにアクセスする必要のある機能（シングル・サインオンや同意管理機能）を備えています。

First-Party Sets では、ファーストパーティとサードパーティが別の物として処理される場合に、同一のエンティティが所有して運営している関連ドメイン名をファースト パーティとして扱えるようにすることができます。First-Party Sets 内のドメイン名は same-party と見なされるため、same-party のコンテキストで設定または送信されることを意図している Cookie にラベルを付けることができます。有効なユースケースを壊さない方法を維持しながら、サードパーティによるクロスサイトトラッキングを防止するバランスを見つけることが目的です。

First-Party Sets の提案は現在テスト段階にあります。その仕組みとそれを試す方法については、続きをご覧ください。

# ファーストパーティ Cookie とサードパーティ Cookie の違いは？

Cookie は本質的にファーストパーティまたはサードパーティではなく、Cookie が含まれる現在のコンテキストに依存します。これは、cookie ヘッダー内、または JavaScript の document.cookie を介したリクエストのいずれかです。

たとえば、 video.site に theme=dark Cookie がある場合、video.site を閲覧中にリクエストが video.site に対して行われると、これは same-site コンテキストであり、含まれる Cookie は first-party となります。

ただし、video.site の iframe プレーヤーを埋め込んだ my-blog.site を閲覧している場合に my-blog.site から video.site にリクエストが送信されると、これはクロスサイトコンテキストであり、theme Cookie は third-party となります。

Cookie の組み込みは、Cookie の SameSite 属性によって決定されます。

• SameSite=Lax、Strict、または None を指定した same-site コンテキストでは、Cookie はファーストパーティになります。
• SameSite=None を指定した cross-site コンテキストでは、Cookie はサードパーティになります。

ただし、必ずしも明確ではありません。brandx.site が旅行予約サイトで、fly-brandx.site と drive-brandx.site も併用してフライトとレンタカーのサービスを分けているとします。1 つの旅行を予約する過程で、訪問者はこれらのサイト間を移動してさまざまなオプションを選択し、これらのサイト間で、「ショッピングカート」の中身が維持されることを期待しています。brandx.siteは、SameSite=None Cookie を使用して、cross-site コンテキストを許可することでユーザーのセッションを管理します。ただし欠点があり、Cookie にクロスサイトリクエストフォージェリ（CSRF）保護がありません。evil.site が brandx.site へのリクエストを含めると、その Cookie が含まれてしまうことになります！

Cookie はクロスサイトですが、これらのサイトはすべて同じ組織が所有し、運営しています。訪問者も同じ組織であると認識しており、それらのサイト間で同じセッション、つまり共通のアイデンティティが使用されることを望んでいます。

# First-Party Sets ポリシー

First-Party Setsは、同じパーティが所有し、運営している複数のサイト間でこの関係を明示的に定義する方法を提案しています。これにより、 brandx.site は fly-brandx.site や drive-brandx.site などとのファーストパーティの関係を定義できるようになります。

さまざまなプライバシーサンドボックスの提案を推進するプライバシーモデルは、ID を分割してクロスサイトトラッキングを防ぐという概念に基づいています。つまり、ユーザーの識別に使用できる情報へのアクセスを制限する境界線をサイト間に引くということです。

デフォルトのオプションはサイトごとに分割することであり、これによって多くのファーストパーティのユース ケースは解決されますが、brandx.site の例では、ファーストパーティが 1 つ以上のサイトで構成される可能性があることを示しています。

First-Party Sets の提案で重要となる部分は、ブラウザ全体のポリシーが乱用や誤用を防止することを保証するというところです。たとえば、First-Party Sets を使って、無関係なサイト間でのユーザー情報の交換、または同じエンティティによって所有されていないサイトのグループ化を有効にしてはなりません。First-Party Set がファーストパーティとして人が理解するものにマッピングされ、さまざまなパーティ間でアイデンティティを共有する方法として使用されないようにすることが、この構想としてあります。

サイトが First-Party Set を登録するには、提案されたドメイングループを、ブラウザポリシーを満たすために必要な情報と共に公開トラッカー（専用の GitHub リポジトリなど）に送信することが 1 つの方法として挙げられます。

First-Party Set のアサーションがポリシーに従って検証されると、ブラウザは更新プロセスを通じてセットのリストを取得することが可能です。

オリジントライアルには定義済みのポリシーがあります。これは最終版ではありませんが、原則は同じままである可能性があります。

• First-Party Set 内のドメインは、同じ組織が所有し、運営しているものである必要があります。
• これらのドメインは、ユーザーが 1 つのグループとして認識できるものである必要があります。
• ドメイン間で共通のプライバシーポリシーが共有されている必要があります。

# First-Party Set の定義方法

組織の First-Party Set のメンバーと所有者を特定したら、提案されたセットを送信して承認を受けることが重要です。実際のプロセスについてはまだ議論中です。

First-Party Set を宣言するには、メンバーと所有者をリストする静的 JSON リソースを、セットに含まれる各ドメインのトップレベルにある /.well-known/first-party-set にホストする必要があります。

brandx の First-Party Set の例では、所有者ドメインは以下のコードを次の場所にホストしています。
https://brandx.site/.well-known/first-party-set:

{
  "owner": "brandx.site",
  "version": 1,
  "members": ["fly-brandx.site", "drive-brandx.site"]
}

このセットの各メンバーは、セットの所有者を指す静的 JSON リソースもホストします。
https://fly-brandx.site/.well-known/first-party-set には以下のコードがあります。

{ "owner": "brandx.site" }

そして https://drive-brandx.site/.well-known/first-party-set には、以下のコードがあります。

{ "owner": "brandx.site" }

First-Party Sets には以下のようないくつかの制約があります。

• セット は 1 人しか所有できません。
• メンバーは 1 つのセットにのみ属することができ、重複や混合はできません。
• メンバーリストは、比較的人間が判読でき、大きすぎないように意図されています。

# First-Party Sets による Cookie への影響

Cookie の照合に必要なのは、提案された SameParty属性です。SameParty を指定すると、Cookie のコンテキストがトップレベルのコンテキストと同じ First-Party Set の一部であれば、その Cookie を含めるようにブラウザに指示します。

つまり、brandx.site が以下の Cookie を設定している場合:

Set-Cookie: session=123; Secure; SameSite=Lax; SameParty

訪問者が fly-brandx.site を閲覧中に、リクエストが brandx.site に送信されると、session Cookie がそのリクエストに含まれるようになります。
例えば hotel.xyz など、First-Party Set の一部ではない他のサイトが brandx.site にリクエストを送信すると、この Cookie は含められません。

SameParty が広くサポートされるまでは、それと一緒に SameSite 属性を使用して、Cookie のフォールバック動作を定義してください。SameParty属性は、SameSite=Lax と SameSite=None の間の設定を提供するものと考えることができます。

• SameSite=Lax; SameParty は Lax 機能を拡張して、サポートされている場合は same-party コンテキストを含めますが、サポートされていない場合は Lax 制限にフォールバックします。
• SameSite=None; SameParty は、サポートされている場合は same-party コンテキストのみに None 機能を制限しますが、サポートされていない場合はより広い None 権限にフォールバックします。

以下のような追加の要件がいくつかあります。

• SameParty Cookie には Secure を含める必要があります。
• SameParty Cookie に SameSite=Strictを含めてはいけません。

これは依然として cross-site であるため、Secure は必須です。安全な（HTTPS）接続を確保することでこれらのリスクを軽減する必要があります。同様に、これはクロスサイトの関係であるため、SameSite=Strict は無効です。これは、セット内で厳密にサイトベースの CSRF 保護を引き続き許可してしまうためです。

# First-Party Sets に適したユースケース

First-Party Sets は、組織が異なるトップレベルサイト間でなんらかの 共有 ID 形態が必要となる場合に適しています。この場合の共有 ID とは、完全なシングルサインオンソリューションから、サイト間で共有された設定が必要なだけの場合まで、あらゆるものを指しています。

組織では、以下の項目に対して異なるトップレベルドメインを使用している可能性があります。

• アプリ用ドメイン: office.com、live.com、microsoft.com
• ブランド別ドメイン: amazon.com、audible.com / disney.com、pixar.com
• ローカリゼーションを有効にするための国固有のドメイン: google.co.in、google.co.uk
• ユーザーが直接操作することはないが、同じ組織のサイト全体でサービスを提供するサービス用ドメイン: gstatic.com、githubassets.com、fbcdn.net
• ユーザーが直接操作することはないが、セキュリティ上の理由から存在するサンドボックスドメイン: googleusercontent.com、githubusercontent.com

# 貢献方法

上記の条件に一致する一連のサイトをお持ちの場合は、参加オプションが多数あります。最も簡単なのは、以下の 2 つの提案に関するディスカッションを読んで参加することです。

• First-Party Sets Privacy Community Group のディスカッション
• SameParty Cookie 属性に関するディスカッション

テスト段階では、--use-first-party-set コマンドラインフラグを使用し、カンマ区切りのサイトリストを指定することで、機能を試すことができます。

以下のフラグを使って Chrome を起動すると、https://fps-member1.glitch.me/ のデモ サイトでこれを試すことができます。

--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me

これは、開発環境でテストしたい場合、またはライブ環境で SameParty 属性を追加して、First-Party Set が Cookie にどのように影響するかを確認したい場合に役立ちます。

実験とフィードバックに使用できる帯域幅がある場合は、バージョン 89 から 93 までの Chrome で利用できる First Party Sets と SameParty のオリジントライアルにサインアップすることもできます。

# オリジントライアルの Cookie を更新する方法

オリジン トライアルに参加し、Cookie の SameParty 属性をテストする場合は、以下の 2 つのパターンを検討してください。

# オプション 1

まず、SameSite=None のラベルを付けた Cookie があるが、ファーストパーティのコンテキストに制限したい場合は、それらに SameParty 属性を追加できます。オリジントライアルがアクティブなブラウザでは、Cookie はセット外の cross-site コンテキストで送信されません。

ただし、オリジントライアル以外の大半のブラウザでは、Cookie は通常どおりクロスサイトで送信され続けます。これは漸進的な強化アプローチと考えてください。

前: set-cookie: cname=cval; SameSite=None; Secure

後: set-cookie: cname=cval; SameSite=None; Secure; SameParty

# オプション 2

2 番目のオプションは手間がかかりますが、オリジントライアルを既存の機能から完全に分離し、SameSite=Lax; SameParty の組み合わせに特定してテストすることができます。

前: set-cookie: cname=cval; SameSite=None; Secure

後:

set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty

送られてくるリクエストの Cookie をチェックする際に、関連するサイトがセット内に含まれており、ブラウザがオリジントライアルを有効にしている場合は、クロスサイトリクエストの cname-fps Cookie のみを期待できます。このアプローチは、以前のバージョンを停止する前に、新しい機能を同時に起動するようなものと考えてください。

# First-Party Set が不要なケースとは？

ほとんどのサイトでは、パーティションまたはプライバシーの境界を引くのに適した場所はサイトの境界です。これは CHIPS（パーティション化された独立した状態を持つ Cookie）で提案されているルートであり、Partitioned 属性を介してサイトにオプトインルートを提供し、重要なクロスサイトの埋め込み、リソース、API、およびサービスを保持しながら、サイト間でのデータの漏洩を防ぐ提案です。

サイトがセットを必要としなくても問題でないことを示す、その他のいくつかの考慮事項:

• 異なるサイトではなく、異なるオリジンでホストしている。上記の例において、brandx.site に fly.brandx.site と drive.brandx.site がある場合、それらはすべて同じサイト内の異なるサブドメインとなります。Cookie は SameSite=Lax を使用できるため、セットは必要ありません。
• サードパーティの埋め込みを他のサイトに提供している。導入で紹介した、my-blog.site に埋め込まれた video.site の動画は、明確なサードパーティ分離の例です。これらのサイトは異なる組織によって運営されており、ユーザーはそれらを個別のエンティティとして認識します。これらの 2 つのサイトを 1 つのセットとすることはできません。
• サードパーティのソーシャルサインインサービスを提供している。OAuth や OpenId Connect などを使用する ID プロバイダーは、多くの場合、ユーザーにスムーズなサインインエクスペリエンスを提供するためにサードパーティの Cookie に依存しています。これは有効なユースケースではありますが、組織が明確に異なるため、First-Party Sets には適していません。WebID などの早期提案では、これらのユースケースを実現する方法を模索しています。