[OUTDATED] ファーストパーティ セットと SameParty 属性

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

ブラウザはサードパーティ Cookie の作成にシフトしている 廃止 ウェブのプライバシーを強化しています。こうしたサイトでは、Cookie を ドメイン全体で状態の維持とアクセスを必要とする機能 (シングル サインオン、同意管理など)。

ファーストパーティ セットでは、 ファーストパーティと 処理方法が異なりますクラスタ内のドメイン名は、 ファーストパーティ セットは同一パーティと見なされ、どの Cookie に 同じパーティのコンテキストで設定または送信されることを想定しています。目的は サードパーティによるクロスサイト トラッキングを防止しつつ、 有効なユースケースを損なわない道筋を維持します。

ファーストパーティ セットのプロポーザルは現在テスト中です。 その仕組みについては以下をご覧ください。 詳しく見ていきましょう。

ファーストパーティの Cookie とサードパーティ Cookie の違いは何ですか?

Cookie は本質的にファースト パーティでもサードパーティでもなく、 コンテキストを指定します。リクエストまたは cookie ヘッダー、または JavaScript の document.cookie を介して使用します。

たとえば、ブラウジング中に video.sitetheme=dark Cookie が保存されている場合、 video.sitevideo.site にリクエストが送信された(同じサイト) コンテキストと、 含まれる Cookie はファーストパーティです。

ただし、my-blog.site を使用していて、Google に iframe プレーヤーが埋め込まれている場合は、 video.sitemy-blog.site から video.site へのリクエストが行われた場合) これはクロスサイト コンテキストであり、theme Cookie はサードパーティ製です。

2 つのコンテキストで video.site の Cookie が使用されている図。トップレベル コンテキストが video.site でもある場合、この Cookie は同じサイトです。この Cookie は、最上位のコンテキストが my-blog.site で iframe に video.site が含まれている場合、クロスサイトになります。

Cookie を含めるかどうかは、Cookie の SameSite 属性によって決まります。

  • 同一サイト コンテキストを使用できます。 SameSite=LaxStrict、または None は、Cookie をファースト パーティにします。
  • SameSite=None を指定したクロスサイト コンテキストにより、Cookie はサードパーティになります。

ただし、必ずしも明確ではありません。brandx.site が旅行の場合を考えてみましょう 予約サイトでも fly-brandx.sitedrive-brandx.site を使用して フライトとレンタカーを分けることができます1 つの旅程を予約する過程で さまざまなオプションを選択する際、 「ショッピング カート」サイト間で保持されるようにします。brandx.site SameSite=None の Cookie を使用してユーザーのセッションを管理し、 クロスサイト コンテキストです。ただし この方法の短所は Cookie にクロスサイトがないため リクエスト フォージェリ(CSRF)evil.site に次のリクエストが含まれている場合: brandx.site とすると、その Cookie が含まれます。

この Cookie はクロスサイトですが、それらのサイトはすべて同じによって所有、運営されています。 できます。サイト訪問者も同じ組織であることを つまり、組織全体で ID が共有されます。

複数のサイトが同じファーストパーティ セットに含まれている場合、クロスサイト コンテキストでは Cookie が引き続き含まれるが、セット外のクロスサイト コンテキストでは拒否される仕組みを示す図。

ファーストパーティ セットに関するポリシー

ファーストパーティ セットは を使用して複数のサイト間のこの関係を 同じ当事者によって所有および運営されているもの。これにより、brandx.site で以下を行えるようになります。 fly-brandx.site とのファーストパーティの関係を定義する。 drive-brandx.site など

プライバシー モデル プライバシー サンドボックスのさまざまな提案は、パーティショニングという クロスサイト トラッキングを防止できます。たとえば、サイト間に境界線を引くことで、 ユーザーの識別に使用できる情報へのアクセスを制限する。

複数のクロスサイト コンテキストで同じサードパーティ Cookie にアクセスできるパーティション分割されていない状態を示す図

デフォルトのオプションはサイトによるパーティション分割です。これにより、多くのファーストパーティ データを brandx.site の例で示しているのは、ファースト パーティの方が 1 つのサイトだけではありません

すべてのサイトが同じセットに含まれている場合、あるセットの Cookie の同じインスタンスがクロスサイト コンテキストに含まれる仕組みを示す図。

ファーストパーティ セットに関するプロポーザルで重要なのは、 悪用や誤用を防止できますたとえば、ファーストパーティ セットを 無関係なサイト間、またはグループ間でユーザー情報を交換できるようにする 重複しています意図したとおり、 ファーストパーティ セットは、ユーザーがファーストパーティとして理解しているものにマッピングされ、 異なる関係者間で 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.xyzbrandx.site にリクエストを送信すると、Cookie は含まれません。

説明するように、クロスサイト コンテキストで brandx.site Cookie が許可またはブロックされることを示す図。

SameParty が広くサポートされるまでは、SameSite 属性と一緒に使用することで、 Cookie のフォールバック動作を定義します。SameParty は、 SameSite=LaxSameSite=None

  • SameSite=Lax; SameParty は、Lax 機能を拡張します。 サポートされている場合は同一パーティ コンテキストを含みますが、Lax にフォールバックします。 制限が適用されます。
  • SameSite=None; SameParty は、以下に対する None 機能を制限します。 サポートされている場合は同一ユーザーのコンテキストに限らず、 付与されていない場合は None 権限。

追加の要件は次のとおりです。

  • SameParty Cookie には Secure が含まれている必要があります
  • SameParty Cookie に SameSite=Strict を含めることはできません

Secure は依然としてクロスサイトであり、軽減する必要があるため必須です。 セキュアな(HTTPS)接続を確保することで、セキュリティ リスクが軽減されます。同様に、これは クロスサイト関係があるため、SameSite=Strict は引き続き許可されているため、無効です サイトベースの CSRF 保護をセットで保護します。

ファーストパーティ セットに適したユースケース

ファーストパーティ セットは、次のような 異なる最上位サイト間での ID の共有。この場合の共有 ID 完全なシングルサインオンソリューションから 表示設定を管理できます。

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

  • アプリのドメイン: office.comlive.commicrosoft.com
  • ブランド関連ドメイン: amazon.comaudible.com / disney.compixar.com
  • ローカライズを有効にする国別のドメイン: google.co.in google.co.uk
  • サービス ドメイン: ユーザーが直接やり取りすることはないものの、 同じ組織のサイト(gstatic.comfbcdn.net githubassets.com
  • サンドボックス ドメイン: ユーザーが直接やり取りすることはないものの、対象のドメイン セキュリティ上の理由: googleusercontent.comgithubusercontent.com

どのように関わって、

上記の条件に一致するサイトがある場合は、 さまざまな選択肢があります。最も軽い投資は読み取りと結合 ディスカッションに参加します

テストフェーズでは、 --use-first-party-set コマンドライン フラグ(カンマ区切りのリストを指定) できます。

デモサイト( 開始後 https://fps-member1.glitch.me/ 次のフラグを指定して Chrome を実行します。

--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 を更新する方法

オリジン トライアルに参加して 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 つ目の方法では手間がかかりますが、オリジン オブジェクトを 1 つずつ し、Google Cloud のオペレーション スイートでの 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、サービスなどの埋め込み、リソース、API、サービスを保護すると同時に、 管理することもできます。

サイトの掲載順位が上がる前であっても、 セット:

  • 異なるサイトではなく、異なるオリジンでホストしている。上記の例では brandx.sitefly.brandx.sitedrive.brandx.site があった場合、それらは すべて同じサイト内の異なるサブドメインである。Cookie は SameSite=Lax であり、セットは必要ありません。
  • 他のサイトに第三者の埋め込みを提供する。導入部の例では、 my-blog.site に埋め込まれた video.site の動画は、明確な第三者です 割るのです。サイトはさまざまな組織によって運営されており、ユーザーがそれを見ている 個別のエンティティとして 機能しますこれら 2 つのサイトを同じセットに含めることはできません。
  • サードパーティのソーシャル ログイン サービスを提供する。ID プロバイダの使用 OAuth や OpenId Connect などは、サービス拒否攻撃のためにサードパーティ Cookie を ユーザーがスムーズにログインできるようになります妥当なユースケースですが 組織に明確な違いがあるため、ファーストパーティ セットに適しています。 WebID などの初期のプロポーザルでは、 これらのユースケースを実現する方法を模索しています