フィードバックレポート - 2022 年第 4 四半期

プライバシーサンドボックスの提案と Chrome の対応に関して受け取ったエコシステムのフィードバックをまとめた 2022 年第 4 四半期の四半期レポートです。

CMA へのコミットメントの一環として、Google は、プライバシーサンドボックスの提案に対する関係者のエンゲージメントプロセスに関する四半期レポートを公開することに同意しました（コミットメントの第 12 段落および 17(c)(ii) を参照）。これらのプライバシーサンドボックスに関するフィードバック要約レポートは、フィードバックの概要に記載されているさまざまなソースから Chrome が受け取ったフィードバックを集計して生成されます。これには、GitHub のイシュー、privacysandbox.com で利用できるフィードバックフォーム、業界関係者との会議、およびウェブ標準フォーラムが含まれますが、それに限定されていません。Chrome は、エコシステムから受け取ったフィードバックを歓迎し、それから学んだことを設計の決定に統合する方法を積極的に模索しています。

フィードバックのテーマは、API ごとに発生率によってランク付けされます。これは、特定のテーマに関して Chrome チームが受け取ったフィードバックの量を集計し、量の多い順に整理することによって行われます。一般的なフィードバックのテーマは、公開会議（W3C、PatCG、IETF）、直接的なフィードバック、GitHub、および Google の内部チームや公開フォームを通じて浮上したよくある質問からの議論のトピックを確認することによって特定されました。

より具体的には、ウェブ標準化団体の会議の議事録がレビューされ、直接的なフィードバックについては、1 対 1 で行われた Google の関係者会議の記録、個々のエンジニアが受け取ったメール、API メーリングリスト、公開フィードバックフォームが考慮されました。次に、Google はこれらのさまざまなアウトリーチ活動に関与するチーム間で調整を行い、各 API に関連して出現したテーマの相対的な発生率を判断しました。

フィードバックに対する Chrome の対応の説明は、公開されている FAQ、関係者によって提起されたイシューに対する実際の対応、およびこの公開報告の目的に特化した立場の決定に基づいて作成されました。開発とテストの現在の焦点を反映して、特に Topics、Fledge、および Attribution Reporting API に関する質問とフィードバックが寄せられました。

現在のレポート期間の終了後に受け取ったフィードバックには、考慮された Chrome の対応がまだ含まれていない可能性があります。

頭字語の用語集

CHIPS: 独立してパーティション化された状態を持つ Cookie
DSP: デマンドサイドプラットフォーム
FedCM: Federated Credential Management
FPS: First-Party Sets
IAB: インタラクティブ広告協会
IDP: ID プロバイダー
IETF: インターネットエンジニアリングタスクフォース
IP: インターネットプロトコルアドレス
openRTB: リアルタイム入札
OT: オリジントライアル
PatCG: プライベート広告技術コミュニティグループ
RP: 証明書利用者
SSP: サプライサイドプラットフォーム
UA: ユーザーエージェント文字列
UA-CH: User-Agent Client Hints
W3C: ワールド・ワイド・ウェブ・コンソーシアム
WIPB: Willful IP Blindness

一般的なフィードバック、API/テクノロジーの指定なし

フィードバックのテーマ	要約	Chrome の対応
（Q3 にも報告）さまざまなタイプの関係者にとっての有用性	プライバシーサンドボックステクノロジーが大規模なデベロッパーに有利であり、ニッチ（小規模な）サイトが一般的な（大規模な）サイトよりも多くの貢献をしているという懸念。	対応は、Q3 から変更ありません。「Google は CMA に対し、プライバシーサンドボックスの提案を、Google 自身のビジネスを自己優先することによって競争を歪めない方法で設計および実装し、規模に関係なくデジタル広告の競争およびパブリッシャーと広告主への影響を考慮に入れることを約束しました。引き続き CMA と緊密に連携し、取り組みがこれらのコミットメントに準拠していることを確認します。プライバシーサンドボックスのテストが進むにつれて、評価対象となる重要な質問の 1 つは、新しいテクノロジーがさまざまなタイプの関係者に対してどのように機能するかということです。この点で、フィードバックは重要です。特に、技術設計をさらに改善するのに役立つ具体的で実用的なフィードバックが重要です。 CMA と協力して定量的テストへのアプローチを開発しており、市場参加者により多くの情報を提供し、提案されたアプローチについてコメントする機会を提供するために、CMA が実験デザインに関するメモを発行することを支持しています。」
（Q3 にも報告）ドキュメントのリクエスト	テスト、分析、および実装を管理する方法を詳述するリソースのリクエスト	第 4 四半期の更新: 開発者が現在の資料を参考してくれたことに感謝しており、新しいテクノロジーががどのように機能するかを開発者が理解できるように、より多くの資料を提供することに引き続き取り組んでいます。過去 1 四半期にわたって、privacysandbox.com に「新機能と更新」セクションを追加し、プライバシーサンドボックスが広告の関連性の促進に今後どのように役立つかについての広範なレビューを公開しました。また、ベストプラクティスとデモを共有するための公開デベロッパーオフィスアワーセッションや、ライブディスカッション/質疑応答を可能にするプロダクトリーダーやエンジニアリングリーダーとの Q&A セッションも開催しました。
Core Web Vitals	プライバシーサンドボックス API の遅延は、Core Web Vitals にどのように影響しますか？	遅延を最小限に抑えることは、プライバシーサンドボックス API の重要な設計目標です。現在のところ、API のレイテンシがサイトの Core Web Vitals に与える影響は最小限であると予想されます。これは、API の大部分が Web サイトの最初のレンダリング後に呼び出されるためです。各 API のレイテンシをさらに短縮するために、引き続き監視と改善を行い、継続的なテストとフィードバックをお勧めします。リアルタイム入札プロセスの遅延については、「FLEDGE オークションのパフォーマンス」の FLEDGE セクションで説明されています。
相互運用性	他の潜在的なソリューションとの相互運用性に関する懸念	プライバシーサンドボックスの目標は、ウェブエコシステムのニーズをサポートしながら、クロスサイトトラッキングからユーザーを保護することです。これを実現するために、サードパーティ Cookie などのクロスサイトトラッキングを可能にする従来のブラウザテクノロジーから離れ、特定のユースケースをサポートするために専用に構築された新しいテクノロジーを代わりに提供します。プライバシーサンドボックスの提案は、ユーザーのデバイスから出るデータを制限することでプライバシーを改善します。この提案は、ブラウザから収集されたデータを共有またはその他の方法で処理するウェブサイトの機能に技術的な制限を課すものではありません。したがって、これらのテクノロジーは、企業が「データ管理」契約またはその他の類似の契約関係を締結することを妨げるものではありません。同様に、ユーザーが他の手段でデータを共有することに同意する能力を制限するものでもありません。明確にするために、Google はプライバシーサンドボックステクノロジーを、Google の製品やサービスを含むすべてのウェブサイトに同じ方法で適用することを約束しました。Chrome がサードパーティ Cookie のサポートを終了した後、Google がユーザーの同期された Chrome ブラウジング履歴などの他の個人データを使用して、デジタル広告のターゲティングまたは測定のためにユーザーを追跡しないことも、コミットメントで明確にされています。

関連するコンテンツと広告の表示

Topics

フィードバックのテーマ	要約	Chrome の返答
Google 検索ランキングへの影響	ウェブサイトの Topics API サポートが、Google 検索結果のランキングの潜在的なシグナルとして使用されるかどうかについてのお問い合わせ	ウェブサイトによっては、Topics API をオプトアウトすることを選択する場合があります。プライバシーサンドボックスチームは、ウェブサイトが Topics API を採用するインセンティブとしてページランキングを使用するように、検索組織に調整したり要求したりしていません。 Google は CMA に対して、Google 検索が Topics API をオプトアウトするというサイトの決定をランキングシグナルとして使用しないことを確認しました。
トピックの分類子	ホスト名に加えて URL とページコンテンツを追加して、ウェブページのトピックを決定し、さまざまな関係者にとっての有用性を向上させます。	ユーザーの閲覧履歴は現在、ウェブサイトのホスト名を使用して分類されています。Chrome は、トピック分類でページレベルのメタデータ（ページ URL やコンテンツのすべてまたは一部のコンポーネントなど）を考慮するためのオプションを引き続き評価しています。有用性の改善においては、プライバシーと悪用のリスクと比較検討する必要があります。たとえば、特にメタデータに関しては、次のようなリスクがいくつかあります。 - さまざまな（および潜在的に機密性の高い）意味をトピックにエンコードする方法としてサイトがページレベルのメタデータを変更する。 - 金銭的利益のためにトピックを偽ってサイトがページレベルのメタデータを変更する。 - クロスサイトトラッキングの方法としてサイトがページレベルのメタデータを動的に変更する
（Q3にも報告）自社シグナルへの影響	トピックシグナルは非常に価値がある可能性があり、その結果、他のファーストパーティのインタレストベースシグナルの価値が低下してしまいます。	対応は、Q3 から変更ありません。「インタレストベースの広告はウェブにとって重要なユースケースであると考えており、トピックはそのユースケースをサポートするように設計されています。［第 3 四半期のレポートで］説明したように、他のエコシステム関係者は、Topics は価値を提供するには十分に有用ではない可能性があるという懸念を表明しています。いずれの場合も、分類法の改善は継続的な取り組みであり、エコシステムのテストとインプットによって分類法が進化することを期待しています。」
分類法の更新	分類リストはどのように更新されますか？	エコシステムにとって最も有用な分類法に関するフィードバックを積極的に求めています。最初の Topics API 提案に含まれる分類法は、機能テストを可能にするように設計されました。Chrome では、分類法を更新するための複数のアプローチを積極的に検討しています。たとえば、Chrome は各トピックの商業的価値の概念を利用して、将来のインテレーションにどのカテゴリを含めるかを決定する場合があります。
Topics の地域的な分類子のパフォーマンス	地域ドメインでの Topics の分類子のパフォーマンスが低い	分類器の改善は継続的な取り組みです。受け取ったフィードバックに基づいて検討している 1 つの可能性は、トピックの上書きリストを拡張することです。これにより、グローバルなカバレッジが拡大し、精度が向上することが分析で示されています。説明すると、Topics API 分類には、（1）上位 10,000 のサイトとそのトピックを含むオーバーライドリスト、（2）ホスト名をトピックに分類するデバイス上の ML モデルの 2 つの関連コンポーネントがあります。オーバーライドリスト（1）を拡張することで、分類器のパフォーマンスが低下している可能性のある地域の分類パフォーマンスを向上させることができます。
1 週間のエポック	1 週間のエポックは、短期間で決定を下そうとするユーザーにとって長すぎます。	エポックの適切な長さについては積極的に検討を進めており、エコシステムにとってより適したエポックに関するさらなるフィードバックを歓迎しています。
HTTP ヘッダーの取得	トピックの HTTP ヘッダー取得に関する十分な情報がないことへの懸念	ヘッダーと fetch() の作業が進行中です。こちらにも情報を提供しています。また、Explainer に skipObservation 情報を追加しました。
Topics は、ユーザーではなく、広告主のみを支援することを目的としている	Topics/プライバシーサンドボックスは、業界に焦点を当てたアプローチのようです。ユーザーにとってのメリットは、業界にとってのメリットほど明確ではありません。	ユーザーにとってのメリットは、ウェブを自由でオープンな状態に保つインタレストベースの広告をトピックがサポートしていることであり、サードパーティ Cookie と比較してプライバシーが大幅に改善されると考えています。実行可能な代替手段なしにサードパーティ Cookie を削除すると、サイト運営者に悪影響を与える可能性があり、より悪いアプローチにつながる可能性があります。それではプライベート性が低く、透過的ではなく、ユーザーが現実的にリセットしたり制御したりできません。多くの企業が Topics とサンドボックス API を積極的にテストする一方で、私たちはプライバシーを向上させ、ウェブをサポートするためのツールを提供することに取り組んでいます。 W3C テクニカルアーキテクチャグループは最近、Topics API に関する最初の見解を公開しました。この段階では、Google はこのレビューが Topics API の開発とリリースに何を意味するかについてエコシステムから質問を受けているため、年内に Chrome 安定版で利用できるようにする計画を再確認したいと思います。 Google は、W3C テクニカルアーキテクチャグループの意見を高く評価していますが、CMA およびエコシステムと協議して Topics を開発およびテストする努力を継続することが最も重要であると考えています。
データ漏洩	トピックが無断で他サイトに流出する懸念	Topics API の設計により、単一のサイト運営者（および少数のサイト運営者グループ）から何らかの方法でデータが漏洩する可能性はほとんどありません。サイト運営者のウェブサイトも Topics API を完全に制御し、アクセス許可ポリシーを介してこの API へのアクセスを禁止できます。
テスト用の広告主の不足	サイト運営者は、現在トピックの価値を広告主に示すことができないことに懸念を抱いています。	2023 年後半には、すべての広告関連 API を統合テストに使用できるようにし、広告主にとっての Topics の価値に関するエコシステム分析を可能にする予定です。テストと結果の公開は、データ、分析、および方法論をレビューする CMA によって管理されます。エコシステムは、Google と CMA にフィードバックを提供することをお勧めします。
Topics と FLEDGE	FLEDGE の入札ロジック内での Topics の使用方法に関する詳細情報のリクエスト	FLEDGE の入札ロジック内でトピックを利用することは可能です。統合ガイドも作成中であり、実装に関する追加の詳細が含まれます。
トピックの呼び出し元のカスタムランキング	呼び出し元ごとにランキングを調整できるようにする	各アドテックのカスタムトピックのランキングまたは価値における課題は、これが、返されるトピックにアドテックが影響を与える仕組み、つまりフィンガープリンティングのベクトルになる可能性があることです。
トピック呼び出し元の優先リスト	Topics API が適性に基づいて返すトピックのランク付けされた優先度リストを呼び出し元が提供できるようにする	現在、このアイデアについてさらに議論しており、追加の意見を歓迎しています。

FLEDGE

フィードバックのテーマ	要約	Chrome の返答
Google アドマネージャー	Google アドマネージャーが FLEDGE オークションの最終決定者であり、Google パブリッシャータグと Google アドマネージャーを優先するのではないかという懸念。	FLEDGE では、各サイト運営者が、トップレベルおよびコンポーネントのセラーの選択を含め、オークションの構造を選択できます。コンポーネントオークションの各バイヤーとセラーは、トップレベルのセラーが誰であるかを知っており、入札するかどうかを選択できます。
FLEDGE をテストするのに十分な参加者がいない	API の機能を改善し、フィンガープリンティングなどのプライバシーを侵害する代替手段を阻止するなど、より多くの企業に FLEDGE をテストするよう奨励してほしいという要求	プライバシーサンドボックスは、CMA および ICO のガイダンスと緊密に連携して段階的に進行しており、FLEDGE の機能テストは必要な安定性と機能を実証しています。 Google は、エコシステムがサンドボックス API をテストすることを引き続き奨励しており、最近、サードパーティ Cookie の廃止後、FLEDGE やその他の API が広告業界の重要なユースケースをサポートするのにどのように役立つかを示す「広告の関連性の最大化」ドキュメントを公開しました。プライバシーサンドボックスの他の部分は、トラッキングをカバーするための軽減策を既にサポートしており（UA-CH、IP 保護、およびバウンス追跡の軽減策を参照）、時間の経過とともに改善され続けます。Google の目標は、FLEDGE を唯一の実行可能なターゲティングソリューションにすることではなく、業界や規制当局と協力して、Chrome ブラウザで最高のプライバシーを保護する広告テクノロジーを推進することに引き続き取り組んでいます。
機械学習のユースケース	オークション入札アルゴリズムをトレーニングするための機械学習のユースケースが、FLEDGE と Attribution Reporting でどのようにサポートされるかに関するガイダンスの増加	テスト担当者がプライバシーサンドボックステクノロジーを適用するのに最も有用な方法を見つけだせるように支援することが必要であると認識しています。機械学習への入力としてのプライバシーサンドボックス API のさまざまな側面の使用に特に関連するガイダンスの公開を開始しました。最新の記事「広告の関連性の最大化」では、広告業界がこれらのシグナルを機械学習にどのように活用できるかについて説明しており、今後もそのようなガイダンスを公開し続ける予定です。
FLEDGE キー値 (K/V) サーバーのクエリ	K/V サーバーがパブリックにクエリ可能であるのはなぜですか？	K/V サーバーは、FLEDGE オークションにリアルタイムのシグナルを提供することを目的としています。そのため、K/V サーバーは、FLEDGE オークションが実行される場所（ユーザーデバイス上）からアクセスできる必要があり、公開されている必要があります。K/V サーバーに保存された値は、既にキーを持っている当事者のみが取得できます。つまり、アドテックがインタレストグループ内のブラウザにのみキーを提供し、ランダムに推測できるキーを使用しない場合の場合、オークションを実行するために値を必要とするブラウザのみが値を取得できます。
日付/時間ターゲティングの方法	入札ロジック関数での日付オブジェクトのサポート。	これを行うには複数の方法があります。バイヤーはセラーに現在の日付と時刻を提供するように依頼できます。セラーはこの情報をすべてのバイヤーに簡単に提供できるはずです。バイヤーは、リアルタイムの Key-Value レスポンスで日付と時刻を提供することもできます。最後に、バイヤーは、per-buyer-signals のコンテキストレスポンスの一部として日時を提供できます。セラーは、これをバイヤーの generateBid スクリプトに渡すことができます。
ユーザー設定	FLEDGE または代替ソリューションを介して提供される場合、広告主によってクリエイティブをブロックすることをユーザーが選択できる機能。	ユーザーは、Chrome で広告 API をオプトアウトできます。特定の広告については、関連するアドテックが、表示されるクリエイティブや選択方法を制御するのに最適な立場にあります。
より明確なタイムライン	Fenced Frame の要求など、FLEDGE でのプライバシー保護の可用性に関する詳細情報のリクエスト。	第 1 四半期には、より詳細なタイムラインを公開する予定です。
レポーティングに関する混乱	FLEDGE レポートが Fenced Frames や Private Aggregation API などの他の API とどのように連携するかについての明確な説明	今後数週間以内に、Private Aggregation API、FLEDGE、および Fenced Frame 間の相互作用に関する Explainer を公開する予定です。
リアルタイム入札とFLEDGE	FLEDGE が標準のリアルタイム入札とどのように統合されるかについてのガイダンス。	リアルタイム入札を行うアドテックの機能を複雑にする 2 つの主な要因は、イベントレベルのデータへのアクセスと、ARA への統合の容易さです。第 1 四半期には、これらの両方に関する最新情報と Explainer を提供する予定です。
FLEDGE オークションのパフォーマンス	FLEDGE オークションのレイテンシが高いというテスターからの報告	テスターからの結果とユースケースを共有するレポートに感謝しています。FLEDGE のパフォーマンスを改善する方法についていくつかの提案を共有しました。同時に、開発者がオークションを遅くしている原因をより正確に診断できるツールをブラウザに追加し、観察された遅延の主な原因に体系的に対処してきました。最近の改善点には、スローオークションのタイムアウト、高速ビッダーフィルタリング技術、 FLEDGE ワークレットを再利用して初期費用の支払いを回避する方法、コンテキスト広告リクエストを FLEDGE の起動時間およびネットワークフェッチと並行して実行できるようにする進行中の作業が含まれます。 API を使用した実世界での経験に基づいて、Chrome 開発者と FLEDGE テスターの間で進行中の会話として、レイテンシの最適化が続くことを期待しています。
インタレストグループサイズのメモリ制限	1 つのインタレストグループのサイズ制限を 50kB から引き上げるリクエスト。	リクエストを積極的に検討しており、どの制限値が役立つかについてフィードバックを求めています。
FLEDGE が提供するデータをファーストパーティ Cookie と組み合わせる	FLEDGE は、広告主のファーストパーティデータとの統合をサポートしますか？	FLEDGE は、広告主が既に持っているファーストパーティデータを使用して広告をサポートするために構築されました。ただし、FLEDGE は、広告主が自身のサイト以外のウェブサイトである人のブラウジング行動を学習することをサポートする意図はありません。オフサイトのブラウジング動作をファーストパーティデータに関連付けることは、プライバシーサンドボックスの目標に反します。今後数週間のうちに、FLEDGE がファーストパーティデータとの統合をどのようにサポートするかについての詳細を含む統合ガイドを共有する予定です。
K-匿名値	「K」から「k-anon」の値はどのように決まり、公開されるのでしょうか？	「K」値はまだ最終決定中であり、計画が進展するにつれて、より多くの情報が共有される予定です。不明な k 値がどのように FLEDGE の準備と ML モデルトレーニングの範囲設定を妨げる可能性があるかについてさらに学ぶことに関心を置いており、この件に関する追加のフィードバックを歓迎しています。
複数の SSP のサポート	複数の SSP は FLEDGE でどのようにサポートされますか？	FLEDGE は、この提案に記載されているように、マルチセラーオークションをサポートしています。
入札ロジックの可視化	DSP 入札ロジックが JavaScript で公開されることへの懸念	現在の設計では、入札ロジック JavaScript に他のユーザーがアクセスできますが、これが DSP の懸念の原因となる理由について、より多くのフィードバックをお待ちしております。
prebid.js	FLEDGE で prebid.js をサポートする予定はありますか？	FLEDGE モジュールをサポートするのは、Prebid.js のバージョン 7.14 以降のみです。テストに関心のあるサイト運営者は、FLEDGE モジュールを追加し、Prebid インスタンスをアップグレードする必要があります。
FLEDGE のユーザー定義関数	ユーザー定義関数 (UDF) は FLEDGE でどのようにサポートされますか?これらは、API の機能を拡張するためにエンドユーザーがプログラムできる関数です。	Explainer はこちらで提供されています。これはまだ具体化されている途中であるため、ユースケースに関する追加のフィードバックを歓迎しています。
インタレストグループリソースに対する同一オリジン制約の緩和	特定のアドテックのユースケースを可能にするために、インタレストグループのリソースに対する同一オリジンの制約を緩和するようにする要求	FLEDGE の現在の実装では、 `biddingLogicUrl`、`biddingWasmHelperUrl`、`dailyUpdateUrl`、`trustedBiddingSignalsUrl` は、インタレストグループのオーナーと同じオリジンを持つ必要があります。こちらで説明されているように、攻撃者による特定のエクスプロイトを防止するために制約が存在します。
InterestGroup の所有権	アドテックがサイト間で同じインタレストグループに対して joinInterestGroup を使用できるかどうかを制限するリクエスト	オーディエンスがどのように構築されるかではなく、どのように使用されるかに焦点を当てています。考えられるアプローチについてはこちらで議論しており、追加の意見を歓迎しています。
キー値サーバーキーの有効期限	対応するインタレストグループの有効期限が切れた後にサーバーキーを削除することに関するディスカッション	キーの有効期限を処理する方法を検討しており、こちらでフィードバックを求めています。

デジタル広告の測定

Attribution Reporting（およびその他の API）

フィードバックのテーマ	要約	Chrome の返答
オリジントライアルトラフィック	現在のオリジントライアルトラフィックは、実用性をテストするには不十分です。	現在のオリジントライアルは、API が意図したとおりに機能することを確認するために、エコシステムプレイヤーが機能テストを実施することを目的としています。さまざまなプライバシーサンドボックス API の開発が成熟すると、ユーティリティテストを実行するために大量のトラフィックが必要になることを理解しています。現在のテストタイムラインでは、2023 年第 3 四半期の一般提供（つまり、ユースケースのテクノロジーが開始され、Chrome トラフィックの 100% で利用可能になるとき）までにこれが行われることを想定しています（privacysandbox.com で最新のタイムラインをご覧ください）。追加のトラフィックを必要とするユースケースのテストについて、追加のフィードバックを歓迎しています。
異なるプライバシーサンドボックス測定 API 間での機能の重複	たとえば Attribution Reporting API と Private Aggregation API など、プライバシーサンドボックスの間で複数の測定アプローチが重複することで複雑さが増すことへの懸念	API のさまざまなユースケースを明確にするために、ドキュメントを改善することに取り組んでおり、説明が不足しているエリアに関する追加のフィードバックを歓迎しています。たとえば、Attribution Reporting API は特にコンバージョン測定をサポートすることを目的としていますが、Private Aggregation API と Shared Storage は、より広範なクロスサイト測定のユースケースをサポートすることを目的とした汎用 API です。
失敗したレポートリクエストの再試行	レポートリクエストが失敗した場合に何回試行されるかについての明確化。	これに関するガイダンスを公開しています。要約すると、レポートはブラウザが実行中またはオンラインの場合にのみ送信されます。最初の送信失敗の後、レポートは 5 分後に再試行されます。 2 回目の失敗の後、レポートは 15 分後に再試行されます。その後、レポートは送信されません。
レポーティングの遅延	レポートの遅延はどのくらい期待されていますか？	エコシステムで発生しているレポートの遅延を並行してさらに評価できるようにデータを収集しているため、これらの遅延について、より多くのフィードバックを期待しています。
ページの事前レンダリング	ARA 属性はプリレンダリングページで機能しますか？	プレレンダリングページでは、アトリビューションの登録は、アクティベーション（実際のクリックまたは表示が行われる）まで延期されます。これは、`attributionsrc` リクエストの ping を延期することを意味します。
コンバージョンリフトの測定	同じドメインで AB テストを使用してコンバージョンリフトを測定する方法	ウェブサイトは、アトリビューションレポートを介して同じドメインで A/B テストを行い、コンバージョンリフトを測定できます。 Aggregate API を使用して A/B パラメータをキーとしてエンコードし、それらのキーバケットごとにコンバージョン値の概要レポートを受け取ることができます。
（Q3 にも報告）クロスドメインコンバージョン	2 つ以上のリンク先など、クロスドメインのコンバージョンを追跡する方法	第 4 四半期の更新: クロスドメインのコンバージョンを追跡できるようにするランディングページの宛先制限を削除する提案を公開しました。この提案は実装済みです。
（Q3にも報告）コンバージョンレポートの有効期限設定	24 時間以内のレポートフィルター/有効期限のサポートのリクエスト	第 4 四半期の更新: レポートの遅延とコンバージョンの有効期限のトレードオフを軽減するために、有効期限とレポートウィンドウを分離するこのプルリクエストを共有しました。これは現在、M110 でローンチされています。
不正と悪用	広告が配信されるサイト運営者のサイトに基づいてデータをスライスおよび集計できるようにするという、広告主やマーケティング担当者からのリクエスト。これにより、潜在的な不正広告行為についてより多くのインサイトを得られる可能性がある	このフィードバックはこちらで活発に議論されており、追加の情報提供を歓迎します。
（Q3 にも報告）イベントレベルレポートの遅延	イベントレベルレポートの 2 ～ 30 日の遅延は、特定のユースケースでは長すぎる場合があります。	イベントレベルのレポートには、2、7、および 30 日のデフォルトのレポートウィンドウがあります。これは、「expiry」パラメーターを使用して変更できます。アドテックは、2 日以内に潜在的なレポートを取得するために、有効期限を最低 1 日で構成できます。プライバシー保護メカニズムとして、有効期限の粒度を 1 日に制限しています。より詳細なレポートはタイミング攻撃につながる可能性があるためです。さらに、イベントレベルレポートと集計レポートに独立した「有効期限」パラメータを設定できます。こちらを参照してください。さらに、Google 広告は、他のアドテックが Attribution Reporting API を介して取得しない特別なレポートウィンドウを取得しません。
同一レポートオリジンの要件	ソース登録オリジンがコンバージョン登録オリジンと同じであるという要件を削除する要求	このユースケースを解決するために、HTTP リダイレクトを使用して登録を委任することを提案します。新しいガイダンスに関する追加のフィードバックを歓迎します。
コンバージョントラッキング	広告主が設定した特定の時間の前後にコンバージョンが発生したかどうかを区別する必要がある	Attribution Reporting API は、ソースアトリビューションの有効期限と優先度の設定をサポートしています。両方を使用することで、技術的には、X 日以内に発生したコンバージョンと、X 日後に発生したコンバージョンを区別することが可能になります。
ノイズシミュレーション	コンバージョン数の少ない広告主への影響を理解するために、バケットごとのさまざまな量のコンバージョンをシミュレートできるようにするリクエスト	Noise Lab の将来のバージョンで、これをシミュレーションする方法を追加する予定です。追加のフィードバックを歓迎します。
モバイルでのレポート	Chrome がモバイルのバックグラウンドで実行されている場合でも、レポートは送信されますか？	現時点では、モバイルでも、Chrome がバックグラウンドにある場合、レポートは送信されません。これは、API が Android Privacy Sandbox と統合されれば変更される可能性があります。こちらを参照してください。Android プライバシーサンドボックスは、CMA が承認したコミットメントの一部ではないことに注意してください。
データの可用性	Google がプライバシーサンドボックス API を介してデータに追加でアクセスできるようになるという懸念	まず、Google 広告は、Attribution Reporting API やその他のプライバシーサンドボックス API からのデータへの優先的なアクセスを受け取りません。この問題は、Google のコミットメントの詳細を含む「相互運用性」の下の一般的なフィードバックセクションでも取り上げられています。次に、大規模なサイトと小規模なサイトの違いについて、Google はノイズベースのプライバシー保護が小さなデータスライスに大きな影響を与える可能性があることを認識しています。ただし、いくつかの緩和策が考えられます。たとえば、長期間にわたる集計などの方法でこの問題を解決できます。とはいえ、非常に小さなデータスライス（1 回または 2 回の購入など）に基づく結論が広告主にとって意味があるかどうかは不明のままです。オリジントライアル期間中、Google は、この問題に関するより具体的なフィードバックを提供できるように、さまざまなプライバシーおよびノイズパラメータを試す機能を利用することをテスターに推奨しました。

隠されたトラッキングの制限

User-Agent の情報量削減

フィードバックのテーマ	要約	Chrome の返答
ウェブエコシステムの準備が整うまで、ユーザーエージェントの削減を遅らせる	今後の User-Agent Reduction の変更に適応するための十分な時間がありません。	このフィードバックは、「Google と CMA とのやり取り」というセクションの「関係者の懸念」にある完全なレポートで対応します。
ウェブエコシステムの準備が整うまで、ユーザーエージェントの削減を遅らせる	構造化ユーザーエージェント（SUA）が展開されるまで、ユーザーエージェント削減のロールアウトを延期するリクエスト	Google 広告チームは、2021 年 10 月に OpenRTB に構造化されたユーザーエージェントの追加（仕様を参照）を提案し、この提案は 2022 年 4 月にリリースされた 2.6 仕様の更新に組み込まれました。 UA-CH と WURFL API を使用して SUA を作成する方法を示した Scientia Mobile のブログ記事で示されているように、SUA が現在展開され、利用可能であることが確認されています。

###

User-Agent Client Hints

フィードバックのテーマ	要約	Chrome の返答
他の隠されたトラッキング防止技術による UA-CH のテスト	包括的アプローチで一緒に提案されたすべてのプライバシーサンドボックス API とフィンガープリンティング手法をテストする方法に関するガイダンス	テスト計画は、残りのサンドボックス提案とは対照的に、フィンガープリンティング防止対策の一部を開発するための非同期タイムラインを反映するために設計されました。これは、一部のフィンガープリント防止対策（プライバシー予算、IP 保護、バウンストラッキングの緩和など）が完全に開発され、サードパーティ Cookie が廃止された後にのみ一般提供を開始する準備が整うという現実に対応しています。これらのフィンガープリンティング防止対策は、定量的なテストには含まれませんが、Standstill の時点で入手可能な事実に基づく定性的な評価の対象となります。
（Q2にも報告）パフォーマンス	Critical-CH（最初のページ読み込み時）を介してヒントを取得する際の遅延についての懸念	以下の専用の UA-CH セクションを参照してください
不十分なフィードバック	UA-CH の変更に関するエコシステムからのフィードバックは不十分であり、エコシステムからの認識不足に関する懸念につながる可能性があります。	混乱を最小限に抑える慎重な展開を確実にするために、計画を積極的に共有してきました。 User-Agent Reduction と UA-CH API の計画は、2022 年 3 月 18 日に W3C Anti-Fraud Community Group に提示され、2022 年 1 月 20 日に Web Payments Working Group と Web Payments Security Interest Group の両方に提示されました。プレゼンテーション中またはプレゼンテーション後に重大な懸念が提起されました。 Google は 100 を超えるサイト運営者と積極的に協力してフィードバックを得ています。さらに、Google は Blink-Dev チャネルを使用して、エコシステムの関係者からのフィードバックに基づいて、ユーザーエージェント削減のロールアウトを公に伝えています。
タイミング	ロールアウトのタイミングと業界の準備状況に関する懸念	以下の専用の UA-CH セクションを参照してください
Chrome プラットフォームのステータス	UA-CH のchromestatus ページの更新を要求	chromestatus エントリは 12 月 19 日に「混合シグナル」に更新されました。

IP 保護（旧 Gnatcatcher）

フィードバックのテーマ	要約	Chrome の返答
オプトインまたはオプトアウト	IP アドレスのプライバシーはオプトインまたはオプトアウトですか？	すべてのユーザーに IP 保護を提供することを目標としています。その目標を念頭に置いて、現在、IP 保護のユーザー選択オプションを評価しています。
ファーストパーティデータの IP アドレスのユースケース	IP アドレスを使用して、IP 保護後のファーストパーティドメイン全体のユーザージャーニーをつなぎ合わせることができますか？	以前に公開されたように、IP 保護は最初はサードパーティのコンテキストでのトラッキングに焦点が当てられます。つまり、ファーストパーティのドメインへの影響はありません。
アドテックのユースケース	企業は IP 保護を使用してどのように不正防止対策を設定できますか？	今日のウェブにおける詐欺対策のシグナルとしての IP アドレスの重要性を認識しています。CMA へのコミットメント（第 20 項）の一環として、スパム対策および詐欺対策の取り組みを実施するウェブサイトの能力をサポートするための合理的な努力を行わない限り、IP 保護を実装しないと述べています。私たちの最優先事項の 1 つは、IP 保護が不正防止のユースケースと検出機能にどのように影響するかを理解することです。これにより、企業がウェブの安全性を維持するのに役立つプライバシー保護テクノロジーにさらに投資できるようになります。時間の経過とともにシグナルが変化した場合でも、セキュリティおよび詐欺防止企業のニーズをサポートすることを目的とした新しい提案に対するフィードバックと意見をお送りください。
不正と悪用	IP 保護にはサービス拒否（DoS）保護が含まれますか？	ウェブを安全に保ちながらプライバシーを改善することに取り組んでおり、サービス拒否攻撃からの保護は、設計の対象となる重要な不正使用防止のユースケースです。私たちは、IP 保護自体の設計と新しい不正使用防止ソリューションの両方を通じて、DoS 保護への影響を最小限に抑えたいと考えています。IP 保護は基本的にサードパーティの組み込みサービスに重点を置いているため、一部の関係者は、ファーストパーティサイトの DoS 保護への影響は限定的であるべきだと指摘しています。DoS のユースケース、特にサードパーティの組み込みサービスに対するリスクを評価するために、引き続きパブリックフィードバックを求めています。同時に、ユーザーを特定せずにサイトまたはサービスがスパムユーザーをブロックできるようにする、悪用フィードバックおよびクライアントブロックメカニズムを調査しています。
コンテンツフィルタリング	IP 保護によるコンテンツフィルタリング	コンテンツのフィルタリングとユーザーエクスペリエンスのカスタマイズに関しては、企業によってニーズが異なります。このようなユースケースの多くは、現在 IP アドレスに依存していないため、IP 保護の影響を受けません。たとえば、コンテンツを調整してより多くのエンゲージメントを促進しようとしているサイト運営者は、ファーストパーティ Cookie またはサードパーティのパーティション化された Cookie（CHIP）を使用して、ユーザーの興味やサイト運営者との以前のやり取りを理解することがあります。または、適切な広告を適切なユーザーに配信することに重点を置いているアドテックパートナーは、たとえば、FLEDGE と Topics を組み込んで、サードパーティ Cookie やその他のクロスサイトトラッキングテクノロジーを使用して現在行っているのと同様の広告結果を配信できます。また、既存のメカニズムでは不十分なコンテンツフィルタリングをさらにサポートするために、大まかな地理位置情報などの新しいプライバシー保護機能を IP 保護に組み込むことも検討しています。IP 保護の影響を受ける可能性のあるコンテンツフィルタリングのユースケースについて、追加のフィードバックをお待ちしております。
（Q3にも報告）ジオロケーションのユースケース	IP 保護によって、ジオロケーションに基づくコンテンツのパーソナル化など、正当なジオロケーションのユースケースを機能させなくなる可能性があります。	第 4 四半期の更新: Google は、Chrome が引き続き IP アドレスの正当なユースケースをサポートできるように、関係者と協力して取り組んでいます。IP ジオロケーションの粒度に関するエコシステムのフィードバックをこちらで受け付けています。

プライバシー予算

フィードバックのテーマ	要約	Chrome の返答
より明確なドキュメント	プライバシー予算が実装されたときにどのような制限が起きるかを予測できる例の追加	プライバシー予算の提案は現在も活発に議論されており、どのブラウザも実装していません。拡張された可用性の最も早い日付が、プライバシー予算が施行される可能性がある最も早い日付です。これは、2024 年にサードパーティ Cookie が削除されるまでは発生しません。現時点で共有できる追加のドキュメントはありません。提案がより確定された時点で、提案に関する追加の詳細を共有します。それまでの間、関係者が提案の開発に役立つフィードバックを共有することを歓迎します。

サイト間プライバシー境界の強化

First-Party Sets

フィードバックのテーマ	要約	Chrome の返答
（Q3 にも報告）ドメイン制限	関連ドメインの数を増やすリクエスト	第 4 四半期の更新: ローカルテスト用の FPS をリリースしました。これには、GitHub でのモックセットの送信プロセスと、rSA および rSAFor をローカルでテストするためのフラグが含まれます。また、関連するサブセットのユースケースに関する質問に引き続き対応するために、FPS の開発者向けに 2 つの公開ミーティングを開催しました。開発者には、関連するサブセットのドメイン制限がユースケースでの FPS の使いやすさにどのように影響するかについてフィードバックを提供できるよう、FPS 機能をテストすることをお勧めします。 Google は WICG の電話会議で、Chrome がユーザーのプライバシーのメリットも考慮した使用可能なソリューションを提供することを約束していることを明確にしました。その意味で、ドメイン制限の影響を受ける可能性のある特定のユースケースに関するコミュニティからのフィードバックをお待ちしております。これにより、チームはユーザーのプライバシーを保護しながらこれらのユースケースに対処する方法を検討できます。
悪用緩和対策の詳細についてのリクエスト	同意していないセットにドメインが追加された場合はどうなりますか？	2022 年 12 月 2 日に、こちらで First-Party Sets の提出ガイドラインを公開しました。提出ガイドラインで説明されているように、一連の変更管理は、所有権の検証を含む GitHub の検証プロセスに従って、これを尊重します。これにより、このリスクが軽減されます。
不正使用の軽減	First-Party Sets の形成が悪用される可能性があるという懸念	サブセットタイプの技術的なチェックを拡張する方法を検討しており、ここでコミュニティからの追加の情報を積極的に求めています。
広告のユースケース	広告ターゲティングをサポートするために First-Party Sets を使用する必要があるかどうかに関する質問	First-Party Sets の広告ターゲティングのユースケースをサポートしようとしているわけではないため、そのようなユースケースで利用可能な広告 API を使用することをお勧めします。
（Q3 にも報告）ポリシー	FPS が「適用されるデータ保護法」に関する CMA コミットメントと一致していないという懸念。これは、FPS が 3 つの制限を想定しているのに対し、GDPR はセット内のサイト数に制限を課していないことに基づいています。	対応は Q3から変更ありません。「Google は、Google 自身のビジネスを自己優先することによって競争を歪めない方法でプライバシーサンドボックスの提案を設計および実装し、デジタル広告、サイト運営者、および広告主における競争への影響、および適用されるデータ保護法に定められていプライバシーの結果およびデータ保護原則の遵守への影響を考慮に入れることを CMA に引き続きコミットしています。表明された懸念は、GDPRとの非互換性を開示するものではありません。私たちは、私たちの仕事がこれらのコミットメントに準拠していることを確認するために、CMAと緊密に協力し続けます。」
代替案	GDPR Validated Sets	「GDPR Validated Sets」を採用するという提案に関してエコシステムから提供されたフィードバックに加え、Chrome はこの代替提案の次の制限について懸念しています。「GDPR Validated Sets」は、GDPR に「準拠する」と主張しています（ただし、それが何を意味するのかは明確ではありません）。対照的に、Google のコミットメントでは、「プライバシーの結果への影響」をより一般的に考慮する必要があります。CMA は、コミットメントを受け入れる決定において、これは「該当するデータ保護法に規定されているデータ保護原則の遵守」を考慮する Google の義務とは異なると指摘しています。これは、CMA が説明しているように、Google がコミットメントに適用される場合と、より一般的に適用される場合の両方で、適用されるデータ保護法に拘束されます。ドメインが複数のセットに表示されることを許可するという提案について、プライバシー上の懸念があります。First-Party Sets は、広範なクロスサイトトラッキングを有効にすることなく、現在サードパーティ Cookie に依存している特定のユースケースをサポートすることを目的としています。ドメインが複数のセットに参加できるようにすると、他の意味のある制限を導入することなく、First-Party Sets の提案に組み込まれている主要なプライバシー保護が打ち消されます。 GDPR Validated Sets は、「共通の使用ポリシーを共有するデータ管理者と処理者のグループとしてセットを定義する」ことも提案しています。これは、セット内のすべての当事者が共通のプライバシーポリシーを共有する必要があるという、最初の First-Party Sets 提案の要件に似ています。その後、プライバシーポリシーに基づく要件に関する懸念を提起するエコシステムからの強いフィードバックに基づいて、その要件を削除しました。たとえば、共通のプライバシーポリシーを維持することは、W3C コミュニティのメンバーによって提起された他の課題の中でも特に、製品や地理的な違いのために実行不可能であると、サイト運営者は述べています（1、 2、3）。私たちは、この提案にも同じ課題が当てはまると考えています。この代替案が提起されて以来、Chrome は First-Party Sets の提案を更新し、新しいセットを作成するための提出ガイドラインを公開しました。

Fenced Frames API

フィードバックのテーマ	要約	Chrome の返答
OT 中の Fenced Frames の制限	オリジントライアル期間中の Fenced Frames に関する現在の制限は何ですか？	制限と実装状況に関するドキュメントの作成に取り組んでおり、2023 年第 1 四半期中に共有する予定です。
1 つの Fenced Frame 内の複数の広告	1 つのオークションで 1 つの Fenced Frame に複数の広告主を表示するリクエスト	現在、このリクエストは積極的に開発されていませんが、エコシステムプレーヤーが機能を重要と考える場合は、追加のフィードバックを歓迎します。
ウェブバンドル	Fenced Frames を使用したウェブバンドルの要件とサポート予定は？	これが将来的に要件となるかどうかについての最新情報は現在ありません。変更は事前に発表されますが、サードパーティ Cookie の廃止前に適用されることはありません。現在の状況については、こちらの Explainer をご覧ください。

Shared Storage API

フィードバックのテーマ	要約	Chrome の返答
アドテック向けの共有ストレージ	アドテック向けの共有ストレージの使用ユースケースに関する不確実性	Shared Storage および Private Aggregation API は、クロスサイトストレージの測定が必要なさまざまな種類の測定目的に使用できます。こちらにいくつかの例を示しています。私たちは、DSP および測定ソリューションプロバイダーが広告のユースケースの主要なインテグレーターになると予測しています。

CHIPS

フィードバックのテーマ	要約	Chrome の返答
（Q3 にも報告）パーティション化の要件	ファーストパーティ Cookie の「Partitioned」属性に明示的な動作要件を追加してください。	第 4 四半期の更新: GitHub と PrivacyCG の呼び出しに関する議論の後、私たちが調整した動作は、ファーストパーティ Cookie に設定されたパーティション化された Cookie がパーティションキー (A,A) を使用するというもので、"A" は最上位サイトです。この動作は、Explainer と仕様で文書化されます。
Cookie 管理	ファーストパーティまたはサードパーティ Cookie を管理するためのツールはありますか？	Chrome DevTools と NetLog を使用して、サードパーティ Cookie のブロックが有効になっているサイトをテストできます。どちらのツールも、ユーザー構成が原因で Cookie がブロックされた場合にレポーティングします。どのような種類の監査ウェブサイトに興味があるか、フィードバックを歓迎します。

FedCM

フィードバックのテーマ	要約	Chrome の返答
IdP では、セッションを許可するために RP の知識が必要	ユーザーが 2 つの異なる RP から Feide IdP にログインしようとしている場合のイシュー	このイシューの潜在的な解決策については、こちらで議論しています。
相互運用性	ユーザーと FedCM を使用してログインするウェブサイトとの関係に対する FedCM の影響、およびウェブサイト間の「相互運用性」に関する懸念	FedCM は、サードパーティ Cookie が Chrome から削除された後も、現在サードパーティ Cookie に依存している ID フェデレーションサービスを引き続きサポートすることを目指しています。 FedCM は、そのようなサービスで利用できるオプションの 1 つにすぎないと考えています。ID プロバイダー（IdP）と証明書利用者（RP）は、ニーズにより適した他のテクノロジーを自由に使用できます。ユーザーと RP の関係と「相互運用性」に関する懸念は、FedCM 提案の誤解によるものと思われます。FedCM は、ユーザーがその RP のサイトにサインインすることを選択した後、どの情報を RP とどのような形式で共有するかを IdP に決定させます。 FedCM では、IdP が「ユーザーが認証する [RP] ごとに一意の仮名識別子を作成する」必要はありません。むしろ、FedCM は各 IdP に対して、ユーザーの実際の識別子、その識別子のサイトごとのバージョン、またはこの情報の他のバージョンを共有するかどうかを選択できるようになっています。（FedCM 仕様では、クロスサイト相関を API に関連するプライバシーリスクとして特定しており、可能性のある軽減策として有向（サイトごと）識別子について説明しています。ただし、有向識別子を使用するかどうかの決定は IdP に委ねられており、ブラウザが管理するものではありません。） FedCM は、ID に関するユーザーの選択も既に提供しています。たとえば、ユーザーが同じ IdP を持つ複数の ID（仕事用プロファイルと個人用プロファイルなど）を持っている場合、FedCM はユーザーが RP のサイトへのログインに使用する ID を選択する方法を提供します。さらに、各 RP は、そのサイトでサポートする IdP を独自に決定します。その決定の 1 つの側面は、IdP が依存するメカニズム（FedCM か別のテクノロジーかに関係なく）を考慮することです。繰り返しますが、ブラウザは RP または IdP のこれらの選択を指示しません。

スパムや詐欺への対抗

Private State Token API

フィードバックのテーマ	要約	Chrome の返答
ボットの処理	プライベートステートトークンがボットに発行されていることを発行者が発見した場合はどうなりますか？	ボットに発行されたトークンがエコシステムに長期間留まらないようにするために、発行者は定期的にトークンの署名に使用するキーをローテーションして、発行ロジックが壊れている可能性がある状態で発行された古いトークンを期限切れにし、サイトが更新された発行ロジックで新しいトークンを引き換えるようにする必要があります。
同一サイトのフォーム送信	プライベートステートトークンは、fetch/XMLHttpRequest API からのリクエストではなく、フルページナビゲーション（Content-Type: application/x-www-form-urlencoded）を含む同じサイトのフォーム送信に使用できますか？	これは現在、Private State Tokens の最初のバージョンではサポートされていません。このユースケースに強い需要がある場合は、エコシステムからのフィードバックを歓迎します。
サーバー側の検証	プライベートステートトークンをサーバー側で検証できるかどうかに関する質問	トークンは発行者に対して引き換えられ、発行者はトークン自体またはトークンから派生した署名付きの値を含む可能性のある引き換え記録を作成し、サーバーはその引き換え記録を使用してトークンの信頼性を検証できます。引き換え記録をどのように解釈するかについて、さまざまな基準が考え出される予定です。

フィードバック レポート - 2022 年第 4 四半期