Related Website Sets - Chrome 117 で First-Party Sets の名前を変更

公開日

翻訳先言語: English

2024 年に開始されるサードパーティ Cookie の廃止に向け、Chrome 安定版では多数のプライバシーサンドボックス API が正式版(GA)へと強化されています。これらの API の中には、重要なクロスサイト Cookie のユースケースを保持する CHIPS や、現在 First-Party Sets(FPS)として知られている API も含まれています。この記事では、FPS の用途をさらによく反映して名前が変更された Related Website Sets(RWS)を紹介し、重要なユースケースと関連サブセットドメイン制限に関するアップデートについて説明します。

重要なユーザージャーニーの保持

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

  • ccTLD のユースケースは、公開トラッカーに記録されているログイン例などの破損に対処します。このようなケースは、通常ヒューリスティックベースの例外によってエコシステムで対処されます(参照 1 を参照)。
  • サービスドメインのユースケースは、機密性を伴う機能(認証フローのサポートなど)をユーザー向けのドメインから分離する開発者の一般的な実践に対処します。このようなケースは、ターゲット例外によってエコシステムで対処されます(参照 2 を参照)。
  • 関連ドメインのユースケースは、重要なユーザージャーニーに関するサードパーティ Cookie アクセスが必要となるドメインのタイプにより高い柔軟性を提供します(参照 3 を参照)。ccTLD とサービスドメインのユースケースでは、ドメインの特徴に基づいて乱用を最小限に抑えるための厳しい技術チェックが採用されますが、関連ドメインでは、ドメイン数制限が使用されます。この詳細については、次のセクションをお読みください。

関連ドメインの制限が 5 ドメインに増加

Chrome は以前、Associated Subset(と 1 プライマリードメイン)に対して 3 ドメインの数制限を提案しました。これは、蔓延するトラッキングの乱用を防止することを目的に提案されたものでしたが、様々なユースケースに対応するにはこの数が少なすぎるというウェブ標準参加団体からのフィードバックを聞きいれることとしました。

他の主要ブラウザが提供する最も比較可能な実装に最も一致するように、関連ドメインの数制限を 5 に引き上げることに決定shしました(参照 4 を参照)。これは、Chrome 117 より適用されます。

RWS は広告ソリューションとしての機能を意図としていないため、広告ユースケースに役立つように RWS を改善する方法についてのフィードバックは考慮されていません。広告ユースケースにおいては、開発者は Topics、Protected Audience、および Attribution Reporting API の使用を詳しく調べ、それらに関するフィードバックを適宜提供してください。

5 関連ドメインの枠を超えた拡張ユースケースのオプション

ユーザーに影響する、この制限でサポートされないエクスペリエンスについて、Chrome は、Storage Access API(SAA)という他のブラウザが採用した標準も利用するユーザープロンプトフローに取り組んでいます。5 関連ドメイン以上の数が必要なユースケースについては、RWS 以外のコンテキストで SAA がどのようにサポートできるかを評価するように開発者に勧めています。この機能については、別途 Blink のリリースプロセスに従っています。Blink は Chrome 117 よりデスクトップ版 Chrome で公開される予定です。

次のステップ

これまでこの API の形成に貢献していただいたエコシステムからのフィードバックに感謝しています。開発者が構築するウェブサイトのエンドユーザーエクスペリエンスを維持するための予測可能性、制御性、および主体性を提供する方法として RWS に取り組んできました。RWS をリリースするに当たり、開発者がそれを採用して使用する要するを目の当たりにし、感激しています。提出プロセスは現在公開中であり、提出を支援するための出発点としては RWS JSON ジェネレーターツールを使用するのが最適です。

進捗は、Intent to Ship スレッドで追跡できます。また、実装ガイドについては、こちらの資料をご覧ください。

リファレンス

  1. ブラウザ間で、これらのクロスサイト Cookie のユースケースは必要であるという一般的な合意がありますが、それぞれに異なる方法で有効にされます。Firefoxコード)と Safariコード)はいずれもポップアップヒューリスティックの実装によって、Nintendo ログインフローなどで観察された破損に対処しています。
  2. また、ブラウザが例外をハードコーディングしてユーザーの中断を最小限に抑えた例も複数あります。Firefox は Microsoft Teams と login.microsoftonline.us の間のリダイレクトフローでのストレージアクセスを許可しています。
  3. Firefox は、ユーザーが instagram.com でログインすると facebook.com に代わって requestStorageAccessForOrigin を呼び出す「shim」を提供しています。サイトのグループ化の例は、複数のドメインに対してストレージアクセスのプロンプトをグループ化する Safari のハードコーディングされた例外でも見られます。
  4. Firefox は、ユーザーが過去にアクセスしたことのあるサードパーティサイトが発行する最初の 5 つの requestStorageAccess 呼び出しを自動許可コード)します。 Chrome では、同一サイトのプライマリードメインのほかに、関連サブセットにリストされている最初の 5 ドメインに、RWS を介して自動付与されたサードパーティ Cookie アクセスが与えられます。

公開日 記事を改善する

Back

DevTools Tips: Snippets and live expressions

Next

Astro View Transitions

This site uses cookies to deliver and enhance the quality of its services and to analyze traffic. If you agree, cookies are also used to serve advertising and to personalize the content and advertisements that you see. Learn more about our use of cookies.