Chrome による First-Party Sets 提案の展開

First-Party Sets（FPS）は、Chrome におけるサードパーティ Cookie の廃止以降のユーザーのウェブ閲覧エクスペリエンスをサポートするために設計されています。この提案は FPS インキュベーション中に、W3C の Privacy Community Group と後の Web Incubator Community Group における公開ウェブフォーラムで大幅に進化しました。

このブログ記事では、主な変更点を押さえながら進化の過程を振り返ます。また、この変更によって、エコシステムをサポートし続けながらもプライバシーを向上できると考える理由にについて説明します。

# 背景

多くの場合、サイトは、サードパーティコンテキストで Cookie にアクセスすることで、シームレスでカスタマイズされたエクスペリエンスをユーザーに提供しています。Chrome チームは、Privacy Preserving Ads API（Topics、FLEDGE、および Attribution）のほかに、サードパーティ Cookie が使用されるシナリオの範囲を理解し、広告のパーソナライズや測定の目的を超えて、ユーザーに強化された閲覧エクスペリエンスを提供しようと考えました。

組織のウェブアーキテクチャは複数のドメインを利用するように設計されているため、組織がサードパーティ Cookie に依存している可能性があることがわかりました。たとえば、ある組織がハイキング関連のブログ用に 1 つのドメイン、キャンプ用品ストア用に別のドメインを用意し、それらのサイト間でのユーザージャーニーをサポートしたいと考えているとします。組織は、ウェブサービス用の共有インフラストラクチャを使用して複数の国コードドメインを維持することもできます。そこで、このようなケースで、ウェブ上のプライバシーに対するユーザーの期待を維持しながら、組織のニーズに合わせたソリューションの作成に取り組むことになりました。

# 出発点

ブラウザは現在、サイトレベルの境界に基づいて「ファーストパーティ」と「サードーティ」を解釈しているため、組織が管理する可能性のあるドメインの範囲を説明するには、この技術的な境界をより微妙な定義に置き換えることが適切であると思われました。

2021 年当初、Chrome は、サイトが「同一パーティ」内のサイトから発信された Cookie を定義できるように、First-Party Sets の SameParty Cookie 属性を提案しました。「同一パーティ」を構成するものの定義に使用されたのは、ユーザーエージェントポリシーです。このポリシー定義は、「パーティ」の既存のフレームワーク（W3C DNT 仕様など）に基づく構築を試み、関連するプライバシーに関する議論（2012 年の連邦取引委員会報告書: 「Protecting Consumer Privacy in an Era of Rapid Change（急速な変化の時代における消費者のプライバシーの保護）」など）からの推奨事項が組み込まれました。

当時、このアプローチは、さまざまな業界の多種多様な組織に十分な柔軟性を提供すると同時に、サードパーティ Cookie による広範なトラッキングが最小限に抑えられるという基本的な目標にも準拠していると感じられました。

# 最初の提案に対するフィードバック

ウェブエコシステムの関係者との多くの会話を通じて、この初期設計には限界があることがわかりました。

# SameParty 属性を介した Cookie のパッシブアクセスによるプライバシーの課題

他のブラウザベンダーは、パッシブな Cookie アクセスを維持できる境界を確立するよりも、明示的な API 呼び出しを必要とするサードパーティ Cookie アクセスに対するアクティブなアプローチを好みました。Cookie アクセスのアクティブなリクエストにより、ブラウザの可視性と制御が提供されるため、サードパーティ Cookie を介した隠されたトラッキングのリスクを軽減できます。さらに、この可視性により、ブラウザはユーザーにそのような Cookie アクセスを許可またはブロックする選択肢を提供できます。

ブラウザ間でのウェブ相互運用性を追求し、プライバシーの利点を改善するために、この方向に進むことにしました。

# 提案されたポリシーの実装上の課題

元のポリシーでは、ドメインを 1 つのセットにするための 3 つの要件が提案されていました。それは、「共有権」、「共通プライバシー ポリシー」、および「共通グループアイデンティティ」です。

より広範なエコシステムから、ポリシーに関して受け取ったフィードバックは 4 つの主なテーマに従うことがわかりました。

# 共有権は制限的すぎる

「共有権」の要件に関して、企業の所有権のみに焦点を当てた FPS の定義により、小規模な企業と比較すると、大企業は幅広いドメインとユーザー向けサービスにわたってデータをプールする能力が向上するというフィードバックを受け取りました。私たちの目標は、エコシステム全体のプライバシーサンドボックスを構築することであるため、このフィードバックを真剣に受け止め、より包括的なソリューションを優先しました。

# 単一のポリシーはユースケースの拡張性を制限する

境界を管理する包括的ポリシーの考え方は、組織の FPS に必要なさまざまな種類のドメインに柔軟性を提供することを目的としていましたが、一部の重要なユースケースではこのポリシー設計を満たすことができないことがわかりました。たとえば、サービス ドメイン（ユーザーが生成したコンテンツをホストしているドメインなど）では、ユーザーを認証または識別するために、サードパーティのコンテキストで Cookie へのアクセスが必要になる場合があります。このようなドメインには、ユーザーがアクセスできるホームページがほとんどないため、同じ FPS 内の他のドメインとの「共通グループ ID」または「共通プライバシー ポリシー」の要件を満たすことができませんでした。

# グループアイデンティティに対するユーザーの認識と理解はそれぞれに異なる場合がある

私たちは当初、単一のセット内のドメインを、共通のグループ ID に簡単に関連付けることができるドメインに限定する試みとして、「共通グループ ID」を定義するガードレールを提案しました。ただし、共通グループ ID が「ユーザーが簡単に発見できる」かどうかを測定・評価するための技術的手段を定義することはできませんでした。これにより、悪用の可能性と施行に関する疑問が残りました。

また、「共有権」の境界の意味の理解はユーザーごとに異なり、すべてのサイトに適用できるガイドラインを作成するのが難しいというフィードバックも受け取りました。

# 主観的なポリシーを大規模に実施することは困難

特定の要件の主観的な性質（「共通グループ ID」など）と、他の要件の例外または特殊なケース（「共通プライバシーポリシー」に関して）をカバーする必要があることを考慮して、より詳細なガイドラインを求める多くのリクエストを受け取りました。

ポリシーが公平かつ一貫して適用されるようにするために、Chrome はサイト作成者にもっと具体的なガイドラインを提供する必要がありました。より厳格なガイドラインを作成しようとすると、エコシステムに損害を与える可能性があると判断しました.

当初、独立した施行機関がポリシーの遵守を調査および施行する役割を担うことを提案していましたが、現在のエコシステムでは、これらの責任を公平な方法で実行するための適切な専門知識を持つ独立した施行機関を見つけることは困難でした。代わりに、実装を一貫して客観的に適用できるようにするために、技術的に実施できるポリシーに方向転換するよう努めました。

# 進化

フィードバックに応えて、FPS を再設計しました。私たちは対処しようとしていた特定の問題に戻り、解決しようとしている特定のユース ケースを中心に提案をより直接的に組み立てることにしました。

# 主なユースケースの解決

Chrome は、ウェブでの主要なユースケースに対応するために、3 つの異なる専用の「サブセット」を開発しました。サブセット アプローチは、よりプライベートであり、より具体的であり、一貫して実施しやすいという点において、以前のアプローチから改善されています。

• 「ccTLD」（国別コード トップレベル ドメイン）— 組織はエクスペリエンスをローカライズする目的で、異なる ccTLD を持つサイトを管理する場合があり、これらのサイトは共有サービスとインフラストラクチャへのアクセスを引き続き必要とする場合があります。
• 「サービス」ドメイン — サイトは、セキュリティまたはパフォーマンスの目的で個別のドメインを使用する場合があり、これらのサイトは機能を実行する目的で、ユーザーの ID へのアクセスを必要とする場合があります。
• 「関連」ドメイン — 組織は、さまざまな関連ブランドまたは製品の複数のサイトを管理する場合があります。関連サイト間のユーザージャーニー分析などのユースケースでクロスサイト Cookie アクセスが必要になる場合があります。これにより、組織のユーザーベースがサイトとどのように対話するかをよりよく理解したり、同じログインインフラストラクチャに依存する関連サイトでユーザーのログイン状態を記憶したりできます。

これらのユースケースにはそれぞれ、個別のポリシー要件、対応する技術的な検証チェック、および特定のブラウザ処理動作があります（詳細については、提出ガイドラインをご覧ください）。これらの変更は、「フリーサイズ」の設計を放棄し、区分化されたユースケース主導のフレームワークを優先することで、元の提案の制限を解決しています。

# サードパーティ Cookie へのアクセスに対する積極的なリクエストによる相互運用性の機会

Chrome は、ウェブ プラットフォームの健全性を維持するために、他のブラウザとの相互運用性を促進することに奮って取り組んでいます。現在 Safari、Firefox、Edge などの他のブラウザが Storage Access API（SAA）を使用してアクティブな Cookie リクエストを容易にしていることから、Chrome でも SAA を利用し、受け取った重要なフィードバックに対処するためだけでなく、ウェブの相互運用性をサポートすることにしました。

開発者により多くの柔軟性を提供し、SAA の既知の制限に対処するために、 requestStorageAccessForOrigin API も提案しました。

# Storage Access API と FPS を併用する機会

Storage Access API（SAA）を実装する場合、許可を直接ユーザーに求めることを選択するブラウザもあれば、許可プロンプトなしで限られた数のリクエストを許可することを選択するブラウザもあります。

Chrome は、ユーザー摩擦を抑制し、重要な限定ユースケースに対する急速な疲弊を防止することで、SAA に透過的なレイヤーを提供できると考えています。FPS ではまた、ブラウザがユーザーに許可を求めるプロンプトを表示することを選択した場合に、セットメンバーシップに関する追加のコンテキストをユーザーに提供する柔軟性が得られます。

FPS を使用すると、開発者は、主要なユースケースを提供し、影響を受ける独自のサイトを特定する機会を得ることができます。これにより、開発者は、サイトがユーザーに対してどのように機能するかを予測し、FPS またはサードパーティ Cookie の代替手段を活用して、ユーザーエクスペリエンスへの影響を抑制する手段を講じることができます。さらに FPS では、時間の経過とともに変化するか、ユーザーごとに動作が異なってしまう可能性のあるヒューリスティックとは異なり、プラットフォームの予測可能性を得られます。

最後に、Chrome に SAA を実装して FPS を操作する開発者は、FPS を出荷していないブラウザを含む他のブラウザでのサイトのパフォーマンスに SAA を活用できるようになります。

# ディスカッションの継続

最新の提案は、ユーザーと開発者のニーズを考慮した困難なトレードオフ空間で適切なバランスをとっていると信じています。FPS 提案の進化を支えてくれたウェブエコシステム関係者からのフィードバックに感謝しています。

私たちは、ウェブエコシステムの関係者が最新の提案内容を確認中であると認識しています。開発者にとってより便利な方法で設計を改善し続け、ウェブ上のプライバシーを改善し続けることができるように、皆さんのご協力をお待ちしています。また、Google は英国の競争市場庁（CMA）と引き続き協力して、コミットメントを確実に遵守していく意向です。

ご協力の際は、以下のリソースを確認してください。

• WICG でのインキュベーション
• FPS テスト手順
• First-Party Sets: 統合ガイド
• FPS 提出ガイドライン

# エコシステムとの連携

Salesforce や CafeMedia などの企業が First-Party Sets の主なフィードバックや開発に取り組んでいるのは素晴らしいことです。これらの企業は技術の進歩に貢献してきました。他の数社も、First-Party Sets と、ウェブ エコシステムと連携する Chrome の取り組みについての意見を共有しています。

「Chrome は、ユーザージャーニーを保持するなど、多くのユース ケースに合わせて First-Party Sets を開発しています。これを見れば、Google チームがウェブ全体を視野にサイト所有者の多様なニーズを理解しようと取り組んでいることがわかります。」 - Mercado Libre

「VWO では、真のユース ケースが確実に処理されるようにしながら、プライバシー基準を引き上げる Google の取り組みに感謝しています。チームが開発者のエコシステムと協力し、ウェブ関係者からのフィードバックに基づいて First-Party Sets の提案の実装を絶えず改善していることは素晴らしいことです。私たちは提案のテスト過程に関与できることを嬉しく思っており、その関与がブラウザに組み込まれることを楽しみにしています。 - Nitish Mital、VMO エンジニアリング部門長