ファーストパーティ セット（FPS）は、Chrome でサードパーティ Cookie が廃止された後も、ユーザーのウェブ ブラウジング エクスペリエンスをサポートするように設計されています。この提案は、FPS のインキュベーション期間中にオープンウェブ フォーラムで大きく進化しました。最初は W3C のプライバシー コミュニティ グループで、さらに現在は Web Incubator Community Group でです。
このブログ投稿では、進化の過程を振り返り、主な変更点に焦点を当て、こうした変更によりウェブのプライバシーを向上させつつ、エコシステムのサポートを続けると Google が考える理由について説明します。
背景
多くのサイトは、ユーザーにシームレスでカスタマイズされたエクスペリエンスを提供するために、サードパーティのコンテキストでの Cookie へのアクセスに依存しています。Chrome チームは、プライバシー保護広告 API（Topics、Protected Audience API、Attribution）の他に、ユーザーのブラウジング エクスペリエンスを向上させるため、広告のパーソナライズや測定にとどまらず、サードパーティ Cookie が使用されるシナリオの範囲を把握することを目指しました。
組織は、ウェブ アーキテクチャが複数のドメインを利用するように設計されているため、サードパーティ Cookie に依存している可能性があることがわかりました。たとえば、ハイキング ブログとキャンプショップ用に 1 つのドメインがあり、これらのサイト間でのユーザー ジャーニーをサポートする場合などです。組織は、ウェブサービス用の共有インフラストラクチャを持つ複数の国コード ドメインを維持することもできます。このようなケースのために、Google はウェブでのプライバシーに対するユーザーの期待に応えながら、そのような組織のニーズに沿ったソリューションの作成に着手しました。
最初
ブラウザは現在、組織が管理する可能性のあるドメインの範囲を考慮して「ファースト パーティ」と「サードパーティ」を解釈するためにサイトレベルの境界を使用しているため、この技術的な境界をよりニュアンスのある定義に置き換えるのが適切と考えられました。
2021 年、Chrome では当初、サイトが「同じ当事者」内のサイトから発信される Cookie を定義できるように、ファーストパーティ セット用の SameParty Cookie 属性を提案しました。何が「同じ当事者」になるかは、ユーザー エージェント ポリシーを使用して定義しました。このポリシー定義は、既存の「当事者」のフレームワーク（W3C DNT 仕様など）を基に構築され、関連するプライバシーに関する議論（2012 年の米国連邦取引委員会のレポート「Protecting Consumer Privacy in the Era of Rapid Change（急速な変化の時代における消費者プライバシーの保護）」など）からの推奨事項を取り入れました。
当時 Google は、サードパーティ Cookie による広範なトラッキングを最小限に抑えるという Google の基本的な目標を守りつつ、さまざまな業種の組織に十分な柔軟性をもたらすと考えていました。
最初の提案に関するフィードバック
ウェブ エコシステムの関係者との多くの会話を通じて、この初期設計には限界があることがわかりました。
SameParty 属性を使用したパッシブな Cookie アクセスに伴うプライバシーの課題
その他のブラウザ ベンダーは、パッシブな Cookie アクセスが維持される境界線を確立するのではなく、明示的な API 呼び出しを必要とするサードパーティ Cookie へのアクセスに対して積極的なアプローチを好みました。Cookie アクセスに対する有効なリクエストにより、ブラウザに対する可視性と制御が提供され、サードパーティ Cookie を介した密かなトラッキングのリスクを軽減できます。さらに、この公開設定により、ブラウザはこのような Cookie へのアクセスを許可するかブロックするかの選択肢をユーザーに提供できます。
Google は、ブラウザ間でのウェブの相互運用性を追求し、プライバシー上のメリットを改善するため、方向性を定めることにしました。
提案されたポリシーの実装上の課題
元のポリシーでは、ドメインを 1 つのセットにするため、「共通の所有権」、「共通のプライバシー ポリシー」、「共通のグループ ID」という 3 つの要件を提案していました。
より幅広いエコシステムから、ポリシーに関するフィードバックは 4 つの主なテーマに沿っていることがわかりました。
一般的な所有権の制限が強すぎる
「共通所有権」の要件に関して、企業所有のみに焦点を当てた FPS の定義により、大企業では中小企業よりも幅広いドメインとユーザー向けのサービスでデータをプールする能力が向上するというフィードバックがありました。Google の目標はエコシステム全体のプライバシー サンドボックスを構築することであるため、Google はこのフィードバックを真摯に受け止め、より包括的なソリューションを優先しました。
単一のポリシーでユースケースへの拡張性が制限される
境界を管理する包括的なポリシーという考え方は、組織の FPS に含める必要があるさまざまな種類のドメインに柔軟性を提供することを目的としていますが、一部の重要なユースケースでは、このポリシー設計を満たしていないことがわかりました。たとえば、サービス ドメイン（ユーザー作成コンテンツをホストするドメインなど）は、ユーザーを認証または識別するために、サードパーティのコンテキストで Cookie にアクセスする必要がある場合があります。このようなドメインにはユーザーがアクセス可能なホームページがあることがほとんどないため、同じ FPS の他のドメインとの「共通グループ ID」または「共通のプライバシー ポリシー」の要件を満たせませんでした。
グループのアイデンティティに対するユーザーの認識や理解は異なる場合がある
当初、1 つのセット内のドメインを共通のグループ ID に簡単に関連付けられるドメインに限定する試みとして、「共通のグループ ID」を定義するガードレールを提案しました。しかし、共通のグループ ID が「ユーザーが簡単に見つけられる」かどうかを測定および評価する技術的な手段を定義できませんでした。そのため、不正使用や違反措置に関する質問が発生する可能性がありました。
また、「共通の所有権」の境界の意味がユーザーによって異なるため、すべてのサイトに適用可能なガイドラインを作成するのは困難というフィードバックをいただきました。
主観的なポリシーを大規模に適用することが困難
特定の要件（「共通グループ ID」など）の主観的な性質上、他の例外またはエッジケース（「共通のプライバシー ポリシー」に関する）をカバーする必要があることから、より詳細なガイドラインのリクエストを多数いただきました。
ポリシーを公平かつ一貫して適用するために、Chrome ではサイト作成者にさらに具体的なガイドラインを提供する必要がありました。Google は、より厳格なガイドラインの作成は、エコシステムに損害を与えるだけの可能性があると判断しました。
Google は当初、独立した執行機関がポリシーの遵守を調査、執行する役割を担うことを提案していましたが、現在のエコシステムでは、これらの責任を公平な方法で遂行するための適切な専門知識を持つ独立した執行機関を見つけることは困難でした。代わりに、実装が一貫して客観的に適用できるように、技術的に適用できるポリシーに軸足を移すよう努めました。
進化
フィードバックを受け、FPS を再設計しました。対処しようとしている特定の問題に立ち返り、解決する特定のユースケースに基づいて提案をより直接的に構成することにしました。
主なユースケースでのソリューション
Chrome は、ウェブの主なユースケースに対応するために、3 つの異なる専用「サブセット」を開発しました。サブセット アプローチは、古いアプローチから改善され、より非公開で具体的になり、一貫性のある適用が容易になります。
- 「ccTLD」（国別コード トップレベル ドメイン） - 組織は、ローカライズされたエクスペリエンスのために異なる ccTLD を持つサイトを維持している場合がありますが、これらのサイトも共有サービスとインフラストラクチャへのアクセスを必要とする場合があります。
- 「サービス」ドメイン - サイトでは、セキュリティやパフォーマンスを目的として個別のドメインを使用する場合があります。このようなサイトでは、機能を実行するためにユーザーの ID へのアクセスが必要になることがあります。
- 「関連」ドメイン - 組織は、関連するさまざまなブランドや商品の複数のサイトを維持できます。たとえば、関連サイト全体のユーザー ジャーニーを分析して、組織のユーザーベースがサイトをどのように利用しているかをより深く理解したり、同じログイン インフラストラクチャを利用している関連サイトでのユーザーのログイン状態を記憶したりするなどのユースケースで、クロスサイト Cookie へのアクセスを必要とする場合があります。
これらの各ユースケースには、個別のポリシー要件、対応する技術的な検証チェック、特定のブラウザ処理動作があります（詳しくは、送信ガイドラインをご覧ください）。これらの変更により、画一的な設計を放棄し、区分けされたユースケース主導のフレームワークを優先することで、元の提案の制限に対処しています。
サードパーティ Cookie へのアクセスに対するアクティブなリクエストによる相互運用性
Chrome では、ウェブ プラットフォームの健全性を維持するために、他のブラウザとの相互運用性を促進することを重視しています。Safari、Firefox、Edge などの他のブラウザでは現在、アクティブな Cookie リクエストを促進するために Storage Access API（SAA）を使用しているため、Google は主要なフィードバックに対応するだけでなく、ウェブの相互運用性をサポートするためにも Chrome で SAA を活用することにしました。
デベロッパーに柔軟性を提供し、SAA の既知の制限事項に対処するために、Google は requestStorageAccessForOrigin API も提案しています。
Storage Access API と FPS を併用する機会
Storage Access API（SAA）を実装する場合、ブラウザは権限を直接ユーザーに要求することもあれば、権限プロンプトを表示せずに限られた数のリクエストを許可することを選択するブラウザもあります。
Chrome では、FPS により、ユーザーの操作を制限し、限定的な主要なユースケースでプロンプト疲れを防ぐことで、SAA の上に透明なレイヤを提供できると考えています。FPS では、ブラウザがユーザーに権限のプロンプトを表示するよう選択した場合に、設定されたメンバーシップに関する追加のコンテキストを柔軟に提供できます。
FPS により、デベロッパーは、主要なユースケースに関し、影響を受ける独自のサイトを特定できます。これにより、政府機関は FPS やサードパーティ Cookie の代替手法を利用して、サイトがユーザーにとってどのように機能するかを予測し、ユーザー エクスペリエンスへの影響を抑える措置を講じることができます。さらに、FPS は、時間の経過とともに変化するヒューリスティックや、ユーザーによって動作が変化する可能性があるヒューリスティックとは対照的に、デベロッパーにプラットフォームの予測可能性をもたらします。
最後に、Chrome で FPS と連携するように SAA を実装するデベロッパーは、FPS に対応していないブラウザも含め、他のブラウザでのサイトのパフォーマンスに SAA を活用できます。
ディスカッション（続き）
Google の最新の提案は、ユーザーとデベロッパーのニーズを考慮した、困難なトレードオフの領域において適切なバランスを取るものと考えています。FPS の提案を進化させるにあたって、ウェブ エコシステムの関係者からのフィードバックは大変貴重なものとなっています。
Google は、ウェブ エコシステムの関係者がまだ新しい提案に精通していることを認識しています。デベロッパーにとってより便利な方法でデザインを改善し、ウェブにおけるプライバシーを継続的に改善していくために、Google にお知らせください。また、Google は、引き続き英国の競争・市場庁（CMA）と連携して、コミットメントの遵守を確保します。
次のリソースをご覧ください。
- WICG でのインキュベーション
- FPS テストの手順
- ファーストパーティ セット: 統合ガイド
- FPS 提出ガイドライン
エコシステムとの連携
Salesforce や CafeMedia のような企業が主要なフィードバックやファーストパーティ セットの開発に取り組んでいることは、非常に嬉しいことです。彼らはテクノロジーの進歩に貢献してきました。他にも、ファーストパーティ セットや、ウェブ エコシステムとの連携に向けた Chrome の取り組みについて、以下のような意見が寄せられています。
「Chrome では、ユーザー ジャーニーの維持など、多くのユースケースに合わせてファーストパーティ セットを開発しています。このことから、Google チームがウェブ全体にわたってサイト所有者のさまざまなニーズを理解しようと努めていることがわかります。」- Mercado Libre
「VWO では、プライバシー基準を高めながら、真のユースケースを確実に処理するための Google の取り組みに感謝しています。チームがデベロッパー エコシステムと連携し、ウェブの関係者からのフィードバックに基づいて、ファースト パーティ セットの提案の実装を継続的に改善しているのは素晴らしいことです。提案のテストに参加できることを嬉しく思い、ブラウザへの組み込みを楽しみにしています。」- VWO、エンジニアリング担当ディレクター Nitish Mittal 氏