関連ウェブサイト セット - ファーストパーティ セットの新しい名前（Chrome 117）

2024 年から予定されているサードパーティ Cookie の廃止に備え、多くのプライバシー サンドボックス API が Chrome の安定版で一般提供（GA）される予定です。一部の API は、CHIPS や現在ファーストパーティ セット（FPS）として知られている API など、重要なクロスサイト Cookie のユースケースを保持するのに役立ちます。この投稿では、関連ウェブサイト セット（RWS）をご紹介します。RWS は、その目的をより的確に反映した新しい FPS の名称です。また、関連するサブセット ドメインの上限に関する更新とともに、主なユースケースについて説明します。

クリティカル ユーザー ジャーニーの維持

RWS は、Chrome がデフォルトでサードパーティ Cookie へのアクセスを制限し始めたときに、ユーザー向けの特定の機能が中断されることを最小限に抑えるように設計されています。Google の目標は、プライバシー サンドボックスのプライバシー目標を維持しながら、ユーザーが中断を最小限に抑えながらウェブをブラウジングできるようにすることです。このバランスをとるために、RWS はウェブサイトの機能に関連する具体的なユースケースを対象としている。

  • ccTLD ユースケースは、Google の公開トラッカーに提出されたログインの例のような不具合に対処するものです。このようなケースは、エコシステムではヒューリスティック ベースの例外によって解決されることがよくあります（参照 1 を参照）。
  • サービス ドメインのユースケースは、機密性の高い機能（認証フローのサポートなど）をユーザー向けのドメインから分離する一般的なデベロッパー プラクティスに対応しています。このようなケースには、ターゲットを絞った例外を設けてエコシステム内で対処できます（参照 2 を参照）。
  • 関連ドメインのユースケース（英語）では、クリティカル ユーザー ジャーニーでサードパーティ Cookie へのアクセスを必要とするドメインの種類について、より柔軟な対応が可能です（参照 3 を参照）。ccTLD とサービス ドメインのユースケースでは、不正使用を最小限に抑えるために、ドメインの特性に基づいて厳格な技術的チェックを行っていますが、関連するドメインでは数値制限を使用しています。これについては次のセクションで説明します。

関連付けられたドメインの上限が 5 つに引き上げられました

Chrome では以前、広範なトラッキングの不正利用を防止するための目的に沿って、関連するサブセットについて 3 つのドメイン（および 1 つのプライマリ ドメイン）という数値制限を提案しました。ウェブ標準参加者から、さまざまなタイプのユースケースに対してこの上限が低すぎるというフィードバックをいただきました。

関連するドメインの上限を、他の主要なブラウザが提供する最も同等の実装に最も適した 5 つのドメイン（および 1 つのプライマリ ドメイン）に増やすことにいたしました（参照 4 をご覧ください）。これは Chrome 117 以降に適用されます。

RWS は広告ソリューションとしての使用を意図したものではないため、広告のユースケースを改善するために RWS を改善する方法に関するフィードバックは考慮されていません。広告のユースケースでは、Topics API、Protected Audience API、Attribution Reporting API の使用を検討し、それぞれの API に関するフィードバックを提供する必要があります。

ユーザーは 5 つの関連ドメインだけではなく、より広範なユースケースを選択可能

Chrome では、この制限に対応していないユーザーに影響を与えるエクスペリエンスについて、ユーザー プロンプト フローの開発に取り組んでいます。このフローでは、他のブラウザで採用されている標準である Storage Access API（SAA）も活用しています。5 つ以上の関連ドメインが必要なユースケースでは、RWS 以外のコンテキストで SAA がどのようにサポートされるかを評価することをおすすめします。この機能については、Blink のリリース プロセスを個別に実施しています。この機能は Chrome 117 より、パソコン版 Chrome でリリースされる予定です。

次のステップ

これまでのところ、API の形成に役立ったエコシステムからのフィードバックに感謝します。Google は、開発者が構築するウェブサイトのエンドユーザー エクスペリエンスを保持するための予測可能性、管理性、主体性を実現する手段として、RWS に投資してきました。今後、開発者がどのように RWS を導入し、活用するかを楽しみにしています。送信プロセスは現在進行中です。RWS JSON 生成ツールを最初の送信からご利用ください。

通知の意図のスレッドに沿って進捗状況を追跡し、こちらの資料で実装のガイダンスを確認してください。

参照

  1. ブラウザ全体で、このようなクロスサイト Cookie のユースケースが必要であるという意見は一般にありますが、ブラウザによって実現するアプローチはさまざまです。Firefox（コード）と Safari（コード）はどちらも、任天堂のログインフローなどで検出された破損に対処するポップアップ ヒューリスティックを実装しています。
  2. また、ユーザーの混乱を最小限に抑えるために、ブラウザが例外をハードコードする例は複数あります。Firefox は、Microsoft Teams と login.microsoftonline.us 間のリダイレクト フローでストレージ アクセスを許可します。
  3. Firefox では、ユーザーが instagram.com にログインしたときに、facebook.com に代わって requestStorageAccessForOrigin を呼び出す「shim」が提供されます。サイトのグループ化の例については、Safari のハードコード例外（複数のドメインのストレージ アクセス プロンプトをグループ化する）をご覧ください。
  4. Firefox では、ユーザーが以前にアクセスしたサードパーティのサイトから行われた最初の 5 つの requestStorageAccess 呼び出し（コード）が自動的に許可されます。Chrome では、関連するサブセットに示されている最初の 5 つのドメインと、同じセットのプライマリ ドメインに対して、RWS を通じてサードパーティ Cookie へのアクセスが自動的に付与されます。