First-Party Sets と SameParty 属性

公開日 更新日

翻訳先言語: English

Caution

First-Party Sets の提案は、ユースケース別の定義と Storage Access API を基に、新しいデザインに更新されています。レポジトリで議論をご覧頂くこともできますし、進捗があればこちらの内容も更新していきます。

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

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

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

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

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

たとえば、 video.sitetheme=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 となります。

video.site からの Cookie を 2 つのコンテキストで示す図。トップレベルのコンテキストも video.site である場合は same-site Cookie であり、トップレベルのコンテキストが my-blog.site で、iframe のコンテキストが video.site である場合は cross-site となる。

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

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

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

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

First-Party Sets には、cross-site コンテキストがそれでも first-party である状況を定義する方法があります。Cookie は、First-Party Set に含めることも、サードパーティのコンテキストで除外することも可能です。

サイトが同じ First-Party Set の一部であれば cross-site コンテキストに Cookie が含まれる可能性があるが、そのセット外の cross-site コンテキストでは拒否されることを示す図。

First-Party Sets ポリシー

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

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

複数の cross-site コンテキストで同じサードパーティ Cookie にアクセスできる未分割の状態と、各トップレベルコンテキストが cross-site Cookie の個別のインスタンスを持ち、それらのサイト間のリンクアクティビティを防止する分割モデルを示す図。

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

すべてのサイトが同じセットの一部である場合に、1 つのセットの Cookie の同じインスタンスが cross-site コンテキストにどのように含まれるかを示す図。

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

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

新しい First-Party Set の承認プロセスについては W3C と協議中であり、検討されているオプションの 1 つに、検証をブラウザ会社ではなく、独立したエンティティが処理することが挙げられています。

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

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

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

First-Party Sets に提案されたポリシーの詳細をご覧ください。

First-Party Set の定義方法

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

Caution

First-Party Set は、同じ組織に属するサイトの完全なリストを意図したものではありません。サイト間で cross-site Cookie を明示的に許可する必要がある場合にのみ、サイトのセットを作成する必要があります。以下の「First-Party Sets オリジントライアルに適したユースケース」をご覧ください。

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 つのセットにのみ属することができ、重複や混合はできません。
  • メンバーリストは、比較的人間が判読でき、大きすぎないように意図されています。

同じアカウント管理バックエンドを共有するサイトを Digital Asset Link でリンクしている場合、既に同様のファイルをホストしている可能性があります。これは特に、関連サイト全体で Chrome パスワードマネージャーが同じ資格情報を提案できるようにするためです。

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 は含められません。

説明のとおり、cross-site コンテキストで許可またはブロックされる brandx.site Cookie を示す図。

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

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

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

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

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

Gotchas

SameParty 属性は、Cookie が送信されるコンテキストにのみ影響を与えます。共通の Cookieジャーは作成されませんbrandx.site からの Cookie は、brandx.site のリクエストまたはドキュメントに対してのみ使用できます。Cookie が fly-brandx.site直接利用できるようになることは絶対にありません 。これは共有 ID として参照されているため、混乱を招く可能性がありますが、これは、サイト間の境界が緩和されているため、same-party の cross-site コンテキストで Cookie を設定または送信できることを意味します。Cookie が直接共有されるということではありません。

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

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

これらのユースケースは、関連するすべてのサイトを所有する cross-site コンテキストのみの場合であっても、既に Cookie を SameSite=None としてマークしているインスタンスになるため、これらのユース ケースの候補を特定できます。

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

  • アプリ用ドメイン: office.comlive.commicrosoft.com
  • ブランド別ドメイン: amazon.comaudible.com / disney.compixar.com
  • ローカリゼーションを有効にするための国固有のドメイン: google.co.ingoogle.co.uk
  • ユーザーが直接操作することはないが、同じ組織のサイト全体でサービスを提供するサービス用ドメイン: gstatic.comgithubassets.comfbcdn.net
  • ユーザーが直接操作することはないが、セキュリティ上の理由から存在するサンドボックスドメイン: googleusercontent.comgithubusercontent.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 属性を追加して、First-Party Set が Cookie にどのように影響するかを確認したい場合に役立ちます。

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

Key Term

オリジントライアルは、外部の開発者が初期の提案を実際のシナリオでテストして、ウェブプラットフォームのニーズを満たすものになるように進化させ、イテレーションを行うために必要なフィードバックを提供できるようにする Chrome の手法です。詳細については、Chrome のオリジン トライアルを開始するをご覧ください。

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

更新日 記事を改善する

We serve cookies on this site to analyze traffic, remember your preferences, and optimize your experience.