多くの組織には、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 に送信されると、そのリクエストに 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）接続を確保して、これらのリスクを軽減する必要があります。同様に、これはクロスサイトの関係であるため、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（独立したパーティショニングされた状態を持つ Cookie）で提案されているルートです。このルートでは、Partitioned 属性を介してオプトイン ルートをサイトに提供し、サイト間での識別情報の漏洩を防ぎながら、重要なクロスサイト埋め込み、リソース、API、サービスを維持します。
サイトにセットを設定する必要がない可能性があることを示すその他の考慮事項は次のとおりです。
- 異なるサイトではなく、異なるオリジンでホストします。上記の例で、
brandx.siteにfly.brandx.siteとdrive.brandx.siteが含まれている場合、これらは同じサイト内の異なるサブドメインです。Cookie はSameSite=Laxを使用できます。設定は必要ありません。 - 他のサイトにサードパーティの埋め込みを提供している。冒頭の
my-blog.siteに埋め込まれたvideo.siteの動画の例は、明確なサードパーティ分割です。サイトは異なる組織によって運営されており、ユーザーは別個のエンティティとして認識しています。これらの 2 つのサイトをセットにすることはできません。 - サードパーティのソーシャル ログイン サービスを提供している。OAuth や OpenId Connect などの ID プロバイダは、多くの場合、ユーザーのログイン エクスペリエンスをスムーズにするためにサードパーティ Cookie に依存しています。これは有効なユースケースですが、組織に明確な違いがあるため、First-Party Sets には適していません。WebID などの初期プロポーザルでは、これらのユースケースを実現する方法が検討されています。