多くの組織には、次のような異なるドメイン名の関連サイトがあります。
brandx.site
と fly-brandx.site
、または次のような国々のドメイン
example.com
、example.rs
、example.co.uk
など
ブラウザはサードパーティ Cookie の作成にシフトしている 廃止 ウェブのプライバシーを強化しています。こうしたサイトでは、Cookie を ドメイン全体で状態の維持とアクセスを必要とする機能 (シングル サインオン、同意管理など)。

ファーストパーティ セットでは、 ファーストパーティと 処理方法が異なりますクラスタ内のドメイン名は、 ファーストパーティ セットは同一パーティと見なされ、どの Cookie に 同じパーティのコンテキストで設定または送信されることを想定しています。目的は サードパーティによるクロスサイト トラッキングを防止しつつ、 有効なユースケースを損なわない道筋を維持します。
ファーストパーティ セットのプロポーザルは現在テスト中です。 その仕組みについては以下をご覧ください。 詳しく見ていきましょう。
ファーストパーティの Cookie とサードパーティ Cookie の違いは何ですか?
Cookie は本質的にファースト パーティでもサードパーティでもなく、
コンテキストを指定します。リクエストまたは
cookie
ヘッダー、または JavaScript の document.cookie
を介して使用します。
たとえば、ブラウジング中に video.site
に theme=dark
Cookie が保存されている場合、
video.site
と video.site
にリクエストが送信された(同じサイト)
コンテキストと、
含まれる Cookie はファーストパーティです。
ただし、my-blog.site
を使用していて、Google に iframe プレーヤーが埋め込まれている場合は、
video.site
(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
を使用して
フライトとレンタカーを分けることができます1 つの旅程を予約する過程で
さまざまなオプションを選択する際、
「ショッピング カート」サイト間で保持されるようにします。brandx.site
SameSite=None
の Cookie を使用してユーザーのセッションを管理し、
クロスサイト コンテキストです。ただし この方法の短所は
Cookie にクロスサイトがないため
リクエスト フォージェリ(CSRF)evil.site
に次のリクエストが含まれている場合:
brandx.site
とすると、その Cookie が含まれます。
この Cookie はクロスサイトですが、それらのサイトはすべて同じによって所有、運営されています。 できます。サイト訪問者も同じ組織であることを つまり、組織全体で ID が共有されます。

ファーストパーティ セットに関するポリシー
ファーストパーティ セットは
を使用して複数のサイト間のこの関係を
同じ当事者によって所有および運営されているもの。これにより、brandx.site
で以下を行えるようになります。
fly-brandx.site
とのファーストパーティの関係を定義する。
drive-brandx.site
など
プライバシー モデル プライバシー サンドボックスのさまざまな提案は、パーティショニングという クロスサイト トラッキングを防止できます。たとえば、サイト間に境界線を引くことで、 ユーザーの識別に使用できる情報へのアクセスを制限する。

デフォルトのオプションはサイトによるパーティション分割です。これにより、多くのファーストパーティ データを
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
権限。
追加の要件は次のとおりです。
SameParty
Cookie にはSecure
が含まれている必要があります。SameParty
Cookie に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
、fbcdn.net
githubassets.com
- サンドボックス ドメイン: ユーザーが直接やり取りすることはないものの、対象のドメイン
セキュリティ上の理由:
googleusercontent.com
、githubusercontent.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.site
にfly.brandx.site
とdrive.brandx.site
があった場合、それらは すべて同じサイト内の異なるサブドメインである。Cookie はSameSite=Lax
であり、セットは必要ありません。 - 他のサイトに第三者の埋め込みを提供する。導入部の例では、
my-blog.site
に埋め込まれたvideo.site
の動画は、明確な第三者です 割るのです。サイトはさまざまな組織によって運営されており、ユーザーがそれを見ている 個別のエンティティとして 機能しますこれら 2 つのサイトを同じセットに含めることはできません。 - サードパーティのソーシャル ログイン サービスを提供する。ID プロバイダの使用 OAuth や OpenId Connect などは、サービス拒否攻撃のためにサードパーティ Cookie を ユーザーがスムーズにログインできるようになります妥当なユースケースですが 組織に明確な違いがあるため、ファーストパーティ セットに適しています。 WebID などの初期のプロポーザルでは、 これらのユースケースを実現する方法を模索しています