多くの組織には、brandx.site や fly-brandx.site など、異なるドメイン名の関連サイトや、example.com、example.rs、example.co.uk など、異なる国のドメインがあります。
ブラウザは、ウェブ上のプライバシーを改善するためにサードパーティ Cookie の廃止に向けて動いていますが、このようなサイトでは、ドメイン間での状態の維持とアクセスを必要とする機能（シングル サインオンや同意管理など）に Cookie を依存していることが多いです。
First-Party Sets を使用すると、ファーストパーティとサードパーティが異なる方法で扱われる状況で、同じエンティティにより所有、運営されている複数の関連するドメイン名をファーストパーティとして扱うことができます。ファーストパーティ セット内のドメイン名は自社ドメインと見なされ、自社ドメインのコンテキストで設定または送信される Cookie にラベルを付けることができます。目的は、サードパーティによるクロスサイト トラッキングを防止しつつ、有効なユースケースを損なわないパスを維持することです。
ファースト パーティ セットの提案はテスト段階です。この機能の仕組みと試用方法については、以下をご覧ください。
ファーストパーティ Cookie とサードパーティ Cookie の違いは何ですか？
Cookie は本来、ファーストパーティまたはサードパーティのいずれかではありません。Cookie が含まれる現在のコンテキストによって異なります。cookie ヘッダーのリクエストで、または JavaScript で document.cookie を使用して、指定します。
たとえば、video.site に theme=dark Cookie があり、video.site をブラウジング中に video.site にリクエストが送信された場合、これは同一サイトのコンテキストであり、含まれる Cookie はファースト パーティです。
ただし、video.site の iframe プレーヤーが埋め込まれている my-blog.site で、my-blog.site から video.site にリクエストが送信された場合、これはクロスサイト コンテキストであり、theme Cookie はサードパーティです。
Cookie の包含は、Cookie の SameSite 属性によって決まります。
SameSite=Lax、Strict、またはNoneのSameSite コンテキストでは、Cookie はファーストパーティになります。SameSite=Noneを使用したクロスサイト コンテキストでは、Cookie はサードパーティになります。
ただし、これは必ずしも明確であるとは限りません。brandx.site が旅行予約サイトであり、fly-brandx.site と drive-brandx.site を使用してフライトとレンタカーを区別しているとします。1 回の旅行の予約中に、訪問者はこれらのサイトを行き来してさまざまなオプションを選択します。選択した「ショッピング カート」がこれらのサイト間で保持されることを期待しています。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 の一致する要素は、提案されている SameParty 属性です。SameParty を指定すると、コンテキストがトップレベル コンテキストと同じファーストパーティ セットに属している場合に Cookie を含めるようブラウザに指示します。
つまり、brandx.site がこの Cookie を設定すると、次のように処理されます。
Set-Cookie: session=123; Secure; SameSite=Lax; SameParty
訪問者が fly-brandx.site にいて、リクエストが brandx.site`, then thesession`cookie will be included on that request.
If some other site which is not a part of the first-party set, for examplehotel.xyz, sends a request tobrandx.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）接続を確保して、これらのリスクを軽減する必要があります。同様に、これはクロスサイトの関係であるため、SameSite=Strict は無効です。これは、セット内でサイトベースの CSRF 保護を厳密に許可するためです。
ファーストパーティ セットに適したユースケース
ファーストパーティ セットは、組織がさまざまなトップレベル サイト間で共有 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 にどのように影響するかを確認する場合に役立ちます。
テストとフィードバックに十分な帯域幅がある場合は、ファーストパーティ セットと SameParty のオリジン トライアルに登録することもできます。これは、Chrome バージョン 89 ～ 93 で利用できます。
オリジン トライアルの 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 Having Independent Partitioned State）で提案されている方法です。この方法では、Partitioned 属性を使用してオプトイン ルートをサイトに提供し、サイト間での識別情報の漏洩を防ぎながら、重要なクロスサイト埋め込み、リソース、API、サービスを維持します。
サイトにセットを設定する必要がない可能性があることを示すその他の考慮事項は次のとおりです。
- 異なるサイトではなく、異なるオリジンでホストします。この例では、
brandx.siteにfly.brandx.siteとdrive.brandx.siteがある場合、これらは同じサイト内の異なるサブドメインです。Cookie はSameSite=Laxを使用できます。設定は必要ありません。 - 他のサイトにサードパーティの埋め込みを提供している。冒頭の例では、
my-blog.siteに埋め込まれたvideo.siteの動画は、明確なサードパーティ分割です。サイトは異なる組織によって運営されており、ユーザーは別個のエンティティとして認識しています。これらの 2 つのサイトはセットに含めないでください。 - サードパーティのソーシャル ログイン サービスを提供している。OAuth や OpenId Connect などの ID プロバイダは、多くの場合、ユーザーのログイン エクスペリエンスをスムーズにするためにサードパーティ Cookie に依存しています。これは有効なユースケースですが、組織に明確な違いがあるため、ファーストパーティ セットには適していません。WebID などの初期プロポーザルでは、これらのユースケースを実現する方法が検討されています。