多くの組織には、ドメイン名（brandx.site や fly-brandx.site など）の異なるサイトや、国の異なるドメイン（example.com、example.rs、example.co.uk など）を持つサイトがあります。
ブラウザはウェブでのプライバシー保護を強化するため、サードパーティ Cookie を廃止する方向に移行しつつあります。このようなサイトでは、ドメイン間で状態を維持、アクセスする必要がある機能（シングル サインオンや同意管理など）で Cookie を使用することがよくあります。
ファーストパーティ セットを使用すると、ファースト パーティとサードパーティが異なる方法で扱われる場合に、同じエンティティが所有および運営する関連ドメイン名をファースト パーティとして扱うことができます。ファーストパーティ セット内のドメイン名は「同一パーティ」と見なされ、同じパーティのコンテキストで設定または送信する Cookie をラベル付けできます。目的は、サードパーティによるクロスサイト トラッキングを防止しつつ、有効なユースケースを損なわない道筋を維持することです。
ファーストパーティ セットの提案は現在テスト段階です。その仕組みと試してみる方法については、以下をご覧ください。
ファーストパーティの Cookie とサードパーティ Cookie の違いは何ですか？
Cookie は本質的にファーストパーティやサードパーティではありません。Cookie が含まれている状況によって異なります。これは、cookie ヘッダー内のリクエスト、または JavaScript の document.cookie によって行われます。
たとえば、video.site に theme=dark Cookie が設定されている場合、video.site の閲覧中に video.site にリクエストが行われた場合、それは同一サイト コンテキストであり、含まれる Cookie はファーストパーティです。
ただし、my-blog.site を使用していて、video.site 用の iframe プレーヤーを埋め込んでいる場合、my-blog.site から video.site へのリクエストがクロスサイト コンテキストとなり、theme Cookie はサードパーティになります。
Cookie を含めるかどうかは、Cookie の SameSite 属性によって決まります。
SameSite=Lax、Strict、またはNoneを持つ同一サイト コンテキストは、Cookie を「ファースト パーティ」と見なします。SameSite=Noneを使用してクロスサイト コンテキストを使用すると、Cookie はサードパーティになります。
ただし、これは必ずしも明確であるとは限りません。brandx.site が旅行予約サイトで、fly-brandx.site と drive-brandx.site を使用してフライトとレンタカーを分けているとします。ユーザーは、ジャーニーを予約する過程で、これらのサイト間を移動してさまざまなオプションを選択します。ユーザーは、これらのサイト間でショッピング カートの内容が維持されることを期待しています。brandx.site はユーザーのセッションを SameSite=None Cookie で管理し、クロスサイト コンテキストでセッションを許可します。ただし、この方法の欠点は、Cookie にクロスサイト リクエスト フォージェリ（CSRF）による保護がないことです。evil.site に brandx.site へのリクエストが含まれている場合、その Cookie も含まれることになります。
この Cookie はクロスサイトですが、それらのサイトはすべて同じ組織によって所有、運営されています。また、ビジターは、それが同じ組織であることを理解し、同じセッション、つまり共有 ID を求めています。
ファーストパーティ セットに関するポリシー
ファーストパーティ セットでは、同じ当事者が所有および運営する複数のサイト間でこの関係を明示的に定義する方法が提案されています。これにより、brandx.site は fly-brandx.site、drive-brandx.site などとのファーストパーティの関係を定義できます。
プライバシー サンドボックスのさまざまな提案を推進するプライバシー モデルは、クロスサイト トラッキングを防ぐために ID をパーティショニングする、つまりサイト間に境界線を設けて、ユーザーの識別に使用できる情報へのアクセスを制限するというコンセプトに基づいています。
デフォルトのオプションはサイトごとに分割することで多くのファーストパーティのユースケースを解決できますが、brandx.site の例では、ファーストパーティを 1 つのサイトよりも大きくできることを示しています。
ファーストパーティ セットの提案の重要な部分は、各種ブラウザでポリシーを使用して不正使用や不正使用を防ぐことです。たとえば、ファーストパーティ セットでは、無関係なサイト間でユーザー情報を交換することや、同じエンティティが所有していないサイトのグループ化を行うことはできません。これは、ファーストパーティ セットを、ユーザーがファーストパーティとして理解できるものにマッピングし、異なるパーティ間で ID を共有する手段として使用しないようにするためです。
サイトでファーストパーティ セットを登録する方法の一つとして、ブラウザ ポリシーに準拠するために必要な情報とともに、提案したドメイン グループを公開トラッカー（専用の GitHub リポジトリなど）に送信するという方法があります。
ファーストパーティ セット アサーションがポリシーに従って検証されると、ブラウザは更新プロセスを通じてセットのリストを取得できます。
オリジン トライアルには確定的なポリシーがありますが、原則は同じである可能性が高いです。
- ファーストパーティ セットのドメインは、同じ組織によって所有および運営されている必要があります。
- ドメインは、ユーザーがグループとして認識できるものでなければなりません。
- ドメインは共通のプライバシー ポリシーを共有する必要があります。
ファーストパーティ セットを定義する方法
組織のファーストパーティ セットのメンバーとオーナーを特定したら、提案されたセットを承認のために提出することが重要なステップとなります。正確なプロセスは検討中です。
ファーストパーティ セットを宣言するには、メンバーとオーナーを一覧表示する静的 JSON リソースを、含まれる各ドメインの最上位の /.well-known/first-party-set でホストする必要があります。
brandx のファーストパーティ セットの例では、オーナー ドメインが 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" }
ファーストパーティ セットには次のような制約があります。
- セットの所有者は 1 人だけです。
- メンバーは 1 つのセットにのみ属し、重複したり混在させたりすることはできません。
- メンバーリストは、比較的人が読める形式に保たれ、過度に大きくならないようにしています。
ファーストパーティ セットが Cookie に与える影響
Cookie に対応する材料は、提案された SameParty 属性です。SameParty を指定すると、コンテキストがトップレベル コンテキストと同じファーストパーティ セットの一部である場合に Cookie を含めるようにブラウザに指示します。
つまり、brandx.site がこの Cookie を設定すると、次のようになります。
Set-Cookie: session=123; Secure; SameSite=Lax; SameParty
そして、訪問者が fly-brandx.site でリクエストが brandx.site に送信されると、そのリクエストに session Cookie が含まれます。ファーストパーティ セットに含まれない他のサイト（hotel.xyz など）が brandx.site にリクエストを送信した場合、Cookie は含まれません。
SameParty が広くサポートされるまでは、SameSite 属性とともに Cookie のフォールバック動作を定義します。SameParty 属性は、SameSite=Lax～SameSite=None の範囲で設定すると考えることができます。
SameSite=Lax; SamePartyは、サポートされている場合は同一パーティ コンテキストを含めるようにLax機能を拡張しますが、サポートされていない場合はLax制限にフォールバックします。SameSite=None; SamePartyは、サポートされている場合は同じパーティのコンテキストのみにNone機能を制限しますが、そうでない場合は、より広範なNone権限にフォールバックします。
追加の要件は次のとおりです。
SamePartyCookie にはSecureを含める必要があります。SamePartyCookie にSameSite=Strictを含めることはできません。
Secure は依然としてクロスサイトであるため、必須であり、安全な（HTTPS）接続を確保してこのリスクを軽減する必要があります。同様に、これはクロスサイト関係であるため、セット内で厳密なサイトベースの CSRF 保護が可能なため、SameSite=Strict は無効です。
ファーストパーティ セットに適したユースケース
ファーストパーティ セットは、組織が複数のトップレベル サイト間で共有 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 つの提案に関する 議論を読んで参加することです
テストフェーズでは、--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 属性を追加して、ファーストパーティ セットが Cookie に与える影響を確認する場合に役立ちます。
テストとフィードバックのための帯域幅がある場合は、Chrome バージョン 89 ～ 93 で利用可能な First Party Sets と SameParty のオリジン トライアルに登録することもできます。
オリジン トライアルの Cookie を更新する方法
オリジン トライアルに参加し、Cookie の SameParty 属性をテストする場合は、次の 2 つのパターンを考慮してください。
オプション 1
まず、SameSite=None とラベル付けした Cookie をファーストパーティ コンテキストに制限する場合は、SameParty 属性を追加します。オリジン トライアルが有効なブラウザでは、セット外のクロスサイト コンテキストで Cookie が送信されることはありません。
ただし、オリジン トライアル以外のほとんどのブラウザでは、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 が表示されるのは、関係するサイトがセットに含まれ、ブラウザがオリジン トライアル期間中である場合に限ります。このアプローチは、以前のバージョンを廃止する前に、更新された機能を同時にリリースするようなものです。
ファーストパーティ セットが不要な理由
大半のサイトでは、サイト境界がパーティションまたはプライバシーの境界線を引く場所として許容されます。これは CHIPS（Cookies Written Independent Partitioned State）で提案されているルートです。サイト間での識別情報の漏洩を防ぎながら、重要なクロスサイト埋め込み、リソース、API、サービスを引き続き利用するためのオプトイン ルートを Partitioned 属性を介してサイトに与えます。
他にも、サイトにセットがなくてもサイトが適切に動作する可能性があることを、いくつか考慮すべき点があります。
- 異なるサイトではなく、異なるオリジンでホストします。上記の例で、
brandx.siteにfly.brandx.siteとdrive.brandx.siteがある場合、これらは同じサイト内にある異なるサブドメインです。Cookie はSameSite=Laxを使用でき、設定は必要ありません。 - 他のサイトにサードパーティの埋め込みを提供する。イントロでは、
my-blog.siteに埋め込まれたvideo.site動画の例が、明らかなサードパーティによる分割です。各サイトは異なる組織によって運営されており、ユーザーには個別のエンティティとして表示されます。これら 2 つのサイトをセットで設定することはできません。 - サードパーティのソーシャル ログイン サービスを提供している。OAuth や OpenId Connect などを使用する ID プロバイダは、ユーザーが簡単にログインできるようサードパーティ Cookie に依存しています。有効なユースケースですが、組織に明確な違いがあるため、ファーストパーティ セットには適していません。WebID などの初期の提案では、こうしたユースケースを可能にする方法を模索しています。