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

プライバシー サンドボックスの提案と Chrome の対応について、エコシステムから寄せられたフィードバックをまとめた 2022 年第 4 四半期の四半期レポート。

Google は CMA へのコミットメントの一環として、プライバシー サンドボックスの提案に関するステークホルダーのエンゲージメント プロセスについて、四半期ごとに公開レポートを提供することに同意しています（コミットメントの第 12 項と第 17 項（c）（ii）を参照）。これらのプライバシー サンドボックスのフィードバック概要レポートは、フィードバックの概要に記載されているさまざまなソース（GitHub の問題、privacysandbox.com で公開されているフィードバック フォーム、業界関係者とのミーティング、ウェブ標準フォーラムなど）から Chrome が受け取ったフィードバックを集計して生成されます。Chrome はエコシステムから寄せられたフィードバックを歓迎し、学んだことを設計上の意思決定に統合する方法を積極的に模索しています。

フィードバック テーマは、API ごとの発生頻度でランク付けされます。これは、特定のテーマについて Chrome チームが受け取ったフィードバックの量を集計し、量の降順で整理することで行われます。一般公開のミーティング（W3C、PatCG、IETF）、直接のフィードバック、GitHub、Google の社内チームと公開フォームから寄せられたよくある質問の議論のトピックを確認することで、一般的なフィードバック テーマを特定しました。

具体的には、ウェブ標準団体の会議の議事録が確認され、直接的なフィードバックについては、Google のステークホルダーとの 1 対 1 の会議の記録、個々のエンジニアが受け取ったメール、API メーリング リスト、一般公開のフィードバック フォームが検討されました。Google は、これらのさまざまなアウトリーチ アクティビティに関与するチーム間で調整を行い、各 API に関連して浮上したテーマの相対的な普及度を判断しました。

Chrome のフィードバックへの対応に関する説明は、公開されているよくある質問、関係者から寄せられた問題に対する実際の回答、およびこの公開レポートの目的のために特別に決定された立場に基づいて作成されています。現在の開発とテストの重点を反映して、特に Topics、Fledge、Attribution Reporting API に関する質問とフィードバックが寄せられました。

現在のレポート期間の終了後に受信したフィードバックには、Chrome の回答がまだ考慮されていない場合があります。

CHIPS
Cookies Having Independent Partitioned State
DSP
デマンドサイド プラットフォーム
FedCM
Federated Credential Management
FPS
ファーストパーティ セット
IAB
Interactive Advertising Bureau
IDP
ID プロバイダ
IETF
インターネット技術特別調査委員会
IP
インターネット プロトコル アドレス
openRTB
リアルタイム ビッダー
延長
オリジン トライアル
PatCG
プライベート広告テクノロジー コミュニティ グループ
RP
証明書利用者
SSP
サプライサイド プラットフォーム
TEE
高信頼実行環境
UA
ユーザー エージェント文字列
UA-CH
User-Agent Client Hints
W3C
World Wide Web Consortium
WIPB
IP の故意の無視

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

フィードバックのテーマ 概要 Chrome の対応
（第 3 四半期にも報告）

さまざまなタイプの関係者にとっての有用性		 プライバシー サンドボックス テクノロジーが大規模なデベロッパーに有利であり、ニッチな（小規模な）サイトが一般的な（大規模な）サイトよりも貢献するという懸念 回答は質問 3 と変わりません。

「Google は、Google 自身のビジネスを優先することで競争を歪めない方法でプライバシー サンドボックスの提案を設計し、実装し、デジタル広告における競争と、規模にかかわらずパブリッシャーと広告主に及ぼす影響を考慮することを CMA に約束しています。Google は、これらの取り組みがこれらのコミットメントに準拠していることを確認するため、引き続き CMA と緊密に連携していきます。

プライバシー サンドボックスのテストが進むにつれ、Google は、さまざまなタイプの関係者にとって新しい技術がどのように機能するかを評価する重要な課題に取り組んでいます。この点において、フィードバックは非常に重要です。特に、技術的な設計をさらに改善するために役立つ、具体的で実用的なフィードバックは重要です。

Google は CMA と協力して定量テストのアプローチを開発してきました。CMA がテスト設計に関するメモを公開し、市場参加者に詳細な情報を提供して提案されたアプローチについてコメントする機会を提供することを支持しています。」
（第 3 四半期にも報告）
ドキュメントのリクエスト		 テスト、分析、実装を管理する方法について詳しく説明しているリソースの追加リクエスト 第 4 四半期の更新:

デベロッパーの皆様から、現在の資料が役に立ったというご意見を多数いただき、ありがとうございます。Google は、デベロッパーの皆様が新しいテクノロジーを活用できるよう、引き続き資料の提供に取り組んでまいります。過去 3 か月間に、privacysandbox.com に「ニュースと最新情報」セクションを追加し、プライバシー サンドボックスが今後の広告の関連性を高めるのにどのように役立つかについて、詳細なレビューを公開しました。

また、ベスト プラクティスとデモを共有する公開デベロッパー オフィスアワー セッションや、プロダクト リードとエンジニアリング リードとの Q&A セッションも開催し、ライブでのディスカッションや質問を可能にしました。
Core Web Vitals プライバシー サンドボックス API のレイテンシは Core Web Vitals にどのように影響しますか？ レイテンシを最小限に抑えることは、プライバシー サンドボックス API の重要な設計目標です。現時点では、ほとんどの API がウェブサイトの最初のレンダリング後に呼び出されるため、API レイテンシがサイトのコアウェブ バイタルズに与える影響は最小限に抑えられると想定しています。Google は、各 API のレイテンシをさらに低減するために、引き続きモニタリングと改善に取り組んでおります。引き続きテストとフィードバックの提供をお願いいたします。

リアルタイム ビッダー プロセスのレイテンシについては、FLEDGE セクションの「FLEDGE オークションのパフォーマンス」をご覧ください。
相互運用性 他のソリューションとの相互運用に関する懸念 プライバシー サンドボックスの目標は、ウェブ エコシステムのニーズをサポートしながら、クロスサイト トラッキングからユーザーを保護することです。Google は、サードパーティ Cookie などのクロスサイト トラッキングを可能にするレガシー ブラウザ テクノロジーから移行し、特定のユースケースをサポートするために構築された新しいテクノロジーを代わりに提供することで、この目標を達成することを目指しています。

プライバシー サンドボックスの提案では、ユーザーのデバイスから送信されるデータを制限することでプライバシーを強化します。提案では、ブラウザから収集されたデータをウェブサイトが共有したり、その他の方法で処理したりする機能に技術的な制限を課すことはありません。したがって、これらの技術は、企業が「データ管理」契約やその他の類似の契約関係を締結することを妨げるものではありません。同様に、ユーザーが他の手段でデータの共有に同意する能力を制限するものではありません。

なお、Google は、Google のプロダクトやサービスを含むすべてのウェブサイトに、プライバシー サンドボックスのテクノロジーを同様に適用することを約束しています。Chrome でサードパーティ Cookie のサポートが終了した後も、Google はユーザーの同期された Chrome 閲覧履歴などの他の個人データを使用せず、デジタル広告のターゲティングや測定のためにユーザーをトラッキングしないことを明確に約束しています。

関連性の高いコンテンツと広告を表示する

トピック

フィードバックのテーマ 概要 Chrome の対応
Google 検索のランキングへの影響 ウェブサイトの Topics API サポートが Google 検索結果のランキングの潜在的なシグナルとして使用されるかどうかに関するお問い合わせ 一部のウェブサイトでは、Topics API をオプトアウトすることもできます。プライバシー サンドボックス チームは、ウェブサイトが Topics API を採用するインセンティブとしてページ ランキングを使用するよう、検索チームと調整したり、検索チームにリクエストしたりしていません。Google は CMA に対し、Google 検索では、サイトが Topics API をオプトアウトする決定をランキング シグナルとして使用しないことを確認しました。
トピック分類器 さまざまな関係者にとって有用性を高めるために、ホスト名に加えて URL とページ コンテンツを追加してウェブページのトピックを特定します。 現在、ユーザーの閲覧履歴はウェブサイトのホスト名を使用して分類されています。Chrome では、トピック分類でページレベルのメタデータ（ページ URL やコンテンツの一部またはすべてなど）を考慮するオプションの評価を継続しています。ユーティリティの改善は、プライバシーと不正使用のリスクと比較検討する必要があります。

たとえば、メタデータに関して、次のようなリスクがあります。
- サイトがページレベルのメタデータを変更して、さまざまな（機密性の高い）意味をトピックにエンコードする。
- サイトがページレベルのメタデータを変更して、金銭的な利益を得るためにトピックを偽装する。
- サイトがページレベルのメタデータを動的に変更して、クロスサイト トラッキングを行う。
（第 3 四半期にも報告）
ファーストパーティ シグナルへの影響		 トピック シグナルは非常に価値が高いため、他のファーストパーティのインタレスト ベースのシグナルの価値が低下する可能性があります。 回答は Q3 から変更ありません。

「インタレスト ベース広告はウェブの重要なユースケースであり、Topics はそうしたユースケースをサポートするように設計されています。[第 3 四半期レポート] で説明したとおり、他のエコシステム関係者は、トピックが価値を提供するには十分に有用ではない可能性があるという懸念を表明しています。いずれの場合も、分類の改善は継続的な取り組みであり、エコシステムのテストとフィードバックに基づいて分類が進化していくことが予想されます。」
分類の更新 分類リストはどのように更新されますか？ Google は、エコシステムにとって最も有用な分類について、積極的にフィードバックを求めています。最初の Topics API の提案に含まれる分類は、機能テストを可能にするように設計されています。Chrome では、分類を更新するための複数のアプローチを積極的に検討しています。たとえば、Chrome はトピックごとに商業的価値の概念を利用して、今後のイテレーションに含めるカテゴリを決定する場合があります。
トピックのリージョン分類器のパフォーマンス 地域ドメインでトピック分類器のパフォーマンスが低い 分類システムの改善は継続的に行われており、寄せられたフィードバックに基づき、現在検討されている可能性の一つとして、トピックのオーバーライド リストの拡大があります。分析によると、これによりグローバルな対象範囲が拡大し、精度が向上する見込みです。

Topics API の分類には、関連する 2 つのコンポーネントがあります。1 つは、上位 1 万個のサイトとそのトピックを含むオーバーライド リストです。もう 1 つは、ホスト名をトピックに分類するデバイス上の ML モデルです。オーバーライド リストを拡張（1）することで、分類システムのパフォーマンスが低下している可能性のある領域の分類のパフォーマンスを改善できます。
1 週間のエポック 1 週間のエポックは、短期的な意思決定を希望するユーザーには長すぎます。 Google では、エポックの適切な長さを積極的に検討しています。エコシステムに適したエポックについて、 フィードバックをお待ちしております。
HTTP ヘッダーの取得 トピックの HTTP ヘッダーの取得に関する情報が不十分であるという懸念 ヘッダーと fetch() の対応は現在進行中です。こちらでも情報をご確認いただけます。また、説明に skipObservation に関する情報も追加しました。
Topics は、ユーザーではなく広告主様をサポートすることを目的としています Topics/プライバシー サンドボックスは、業界に焦点を当てたアプローチのように見えます。ユーザーにとってのメリットは、業界にとってのメリットほど明確ではない。 Google は、Topics はウェブを自由でオープンな状態に保つインタレスト ベース広告をサポートし、サードパーティ Cookie と比較してプライバシーを大幅に改善できると考えています。サードパーティ Cookie を削除する際に代替手段を用意しないと、パブリッシャーに悪影響を及ぼす可能性があります。また、プライバシー保護が低く、透明性が欠如し、ユーザーが実際にリセットまたは管理できない
代替手段につながる可能性があります。多くの企業が Topics と Sandbox API を積極的にテストしています。Google は、プライバシーを強化し、ウェブをサポートするツールを提供することに取り組んでいます。


W3C 技術アーキテクチャ グループは最近、Topics API に関する最初の見解を公開しました。Google は、この見解に公開で回答する予定です。この段階で、この審査が Topics API の開発とリリースにどのような影響を与えるかについて、エコシステムから質問を受けましたので、今年中に Chrome Stable で利用できるようにする予定であることを改めてお知らせいたします。Google は W3C 技術アーキテクチャ グループからの意見を重視していますが、CMA とエコシステムと協議しながらトピックの開発とテストに継続的に取り組むことを最優先事項と考えています。
データ漏洩 トピックが許可なく他のサイトに漏洩する可能性があるという懸念 Topics API の設計により、単一のパブリッシャー（または少数のグループのパブリッシャー）のデータがなんらかの方法で漏洩する可能性は非常に低くなっています。パブリッシャーのウェブサイトでも Topics API を完全に管理できます。また、権限ポリシーを使用してこの API へのアクセスを禁止することもできます。
テスト用の広告主が不足している パブリッシャーは、現在のところトピックの価値を広告主に示すことができないのではないかと懸念しています。 2023 年後半には、すべての広告関連 API を統合テストに使用できるようにし、広告主様向けの Topics の価値に関するエコシステム分析を可能にすることを予定しています。テストと結果の公開は CMA が監督し、データ、分析、手法を確認します。エコシステムは、Google と CMA とフィードバックを共有することをおすすめします。
Topics と FLEDGE FLEDGE の入札ロジック内で Topics を使用する方法について詳しくお聞かせください FLEDGE の入札ロジック内で Topics を使用できます。統合ガイドも作成中です。実装に関する詳細情報が含まれます。
トピック呼び出し元のカスタム ランキング 呼び出し元によるランキングの調整を許可する 各広告テクノロジーに対してカスタム トピックのランキングや値を設定すると、広告テクノロジーが返されるトピックに影響を与えるメカニズムとなり、指紋ベクトルになる可能性があります。
トピックの発信者の優先リスト 呼び出し元が、Topics API が返すトピックの優先度順のリストを提供できるようにします。このリストは、トピックの適格性に基づいて返されます。 現在、このアイデアについてさらに検討 しており、皆様からの追加の意見をお待ちしております。

FLEDGE

フィードバックのテーマ 概要 Chrome の対応
Google アド マネージャー FLEDGE オークションの最終的な決定者が Google アド マネージャーであり、Google パブリッシャー タグと Google アド マネージャーが優遇されるのではないかという懸念。 FLEDGE では、各パブリッシャーがオークションの構造（最上位販売者とコンポーネント販売者の選択など）を選択できます。コンポーネント オークションの各購入者と販売者は、最上位の販売者を知っており、入札するかどうかを選択できます。
FLEDGE をテストする参加者が不足している API の機能の改善や、指紋照合などのプライバシー侵害の代替手段の抑制などにより、より多くの企業が FLEDGE をテストするよう促すリクエスト プライバシー サンドボックスは、CMA と ICO のガイダンスに基づき、緊密なパートナーシップで段階的に進められており、FLEDGE の機能テストでは必要な安定性と機能が実証されています。Google は、エコシステムがサンドボックス API をテストすることを引き続き推奨しています。最近、Google は「広告の関連性を最大化する」ドキュメントを公開し、サードパーティ Cookie のサポート終了後、FLEDGE などの API が広告業界の重要なユースケースをどのようにサポートできるかを示しました。

プライバシー サンドボックスの他の部分では、トラッキングをカバーする緩和策がすでにサポートされています（UA-CH、IP 保護、離脱トラッキング緩和策をご覧ください）。今後も改善が進む予定です。Google の目標は、FLEDGE を唯一の有効なターゲティング ソリューションにすることではなく、業界や規制当局と連携して、Chrome ブラウザで最高のプライバシー保護広告テクノロジーを推進することです。
機械学習のユースケース FLEDGE とアトリビューション レポートでオークション入札アルゴリズムのトレーニングに機械学習のユースケースがどのようにサポートされるかに関する詳細なガイダンス Google は、プライバシー サンドボックス テクノロジーを最も効果的に適用する方法を見つけられるよう、テスターをサポートする必要があることを認識しています。Google は、機械学習への入力としてプライバシー サンドボックス API のさまざまな要素を使用することと関連するガイダンスの公開を開始しました。最新の広告の関連性を最大化するでは、広告業界がこれらのシグナルを機械学習にどのように活用できるかについて説明しています。今後もこのようなガイダンスを公開していく予定です。
FLEDGE Key-Value（K/V）サーバーをクエリする K/V サーバーが一般公開でクエリ可能なのはなぜですか？ K/V サーバーは、FLEDGE オークションにリアルタイム シグナルを提供することを目的としています。そのため、K/V サーバーは、FLEDGE オークションが実行される場所（ユーザーのデバイス）からアクセス可能である必要があります。つまり、公開されている必要があります。K/V サーバーに保存された値は、すでにキーを持っているパーティのみが取得できます。そのため、広告テクノロジーがインタレスト グループ内のブラウザにのみキーを提供し、ランダムに推測できるキーを使用しない場合、オークションの実行に値を必要とするブラウザのみが値を取得できます。
日時ターゲティングを行う方法 入札ロジック関数で日付オブジェクトをサポート。 これを行う方法は複数あり、購入者は販売者に現在の日時を提供するよう依頼できます。販売者はすべての購入者にこの情報を簡単に提供できる必要があります。購入者は、リアルタイムの Key-Value レスポンスで日時を指定することもできます。最後に、購入者は購入者ごとのシグナルのコンテキスト レスポンスの一部として日時を提供できます。この日時は、販売者が購入者の generateBid スクリプトに渡すことができます。
ユーザー設定 FLEDGE 経由で配信されるクリエイティブや代替ソリューションを、広告主別にブロックするかどうかをユーザーが選択できる機能。 ユーザーは Chrome で Ads API をオプトアウトできます。特定の広告については、表示されるクリエイティブやその選択方法を管理するうえで、関連する広告テクノロジーが最適な立場にあります。
より明確なタイムライン FLEDGE で利用可能なプライバシー保護機能（フェンスド フレームの要件など）について詳しくリクエストする。 詳細なタイムラインについては、第 1 四半期に公開する予定です。
報告に関する混乱 FLEDGE レポートが Fenced Frames API や Private Aggregation API などの他の API とどのように連携するかについて、より明確な説明を求める。 Private Aggregation API、FLEDGE、Fenced Frames の相互作用については、今後数週間以内に説明を公開する予定です。
リアルタイム ビッダーと FLEDGE FLEDGE を標準のリアルタイム ビッダーと統合する方法に関するガイダンス。 広告テクノロジーがリアルタイム入札を行う能力を複雑にしている主な要因は、イベントレベルのデータへのアクセスと ARA への簡単な統合です。これらの両方に関する最新情報と説明は、第 1 四半期に送信する予定です。
FLEDGE オークションのパフォーマンス FLEDGE オークションのレイテンシが高いという報告がテスターから寄せられた テストの結果とユースケースを共有していただいたテスターの皆様に感謝申し上げます。FLEDGE のパフォーマンスを改善する方法に関する提案も共有させていただきました。

また、デベロッパーがオークションの遅延の原因をより正確に診断できるように、ブラウザにツールを追加し、検出された主なレイテンシの原因に体系的に取り組んできました。最近の改善点には、遅いオークションのタイムアウト、高速なビッダー フィルタリング手法、FLEDGE ワークレットを再利用して起動コストを回避する方法、FLEDGE の起動時間とネットワーク取得と同時にコンテキスト広告リクエストを実行できるようにするための継続的な作業などがあります。レイテンシの最適化は、API の実際の使用状況に基づいて、Chrome デベロッパーと FLEDGE テスターとの間で継続的に議論される予定です。
インタレスト グループのサイズのメモリ上限 1 つのインタレスト グループのサイズの上限を 50 KB から引き上げるリクエスト。 Google では、このリクエストを積極的に検討しており、適切な上限値に関するフィードバックをお待ちしております。
FLEDGE で配信されたデータとファーストパーティ Cookie を組み合わせる FLEDGE は広告主様のファーストパーティ データとの統合をサポートしますか？ FLEDGE は、広告主様がすでに保有しているファーストパーティ データを使用して広告を配信できるように構築されています。ただし、FLEDGE は、広告主が自社のサイト以外のウェブサイトでユーザーのブラウジング アクティビティを把握することを目的としたものではありません。オフサイトのブラウジング アクティビティをファーストパーティ データに関連付けることは、プライバシー サンドボックスの目標に反しています。

FLEDGE がファーストパーティ データとの統合をサポートする方法について詳しく説明した統合ガイドを、今後数週間以内に公開する予定です。
k-匿名性の値 値「K」から「k-anon」への変更はどのように決定され、公開されますか？ 「K」値はまだ確定しておりません。計画が進展するにつれて、詳細をお知らせいたします。不明な k 値が FLEDGE への準備と ML モデル トレーニングのスコーピングにどのように影響するかについて、詳しくお聞かせください。この件に関する追加のフィードバックをお待ちしております。
複数の SSP のサポート FLEDGE では複数の SSP がどのようにサポートされますか？ FLEDGE は、この提案に記載されているように、複数販売者オークションをサポートしています。
入札ロジックの公開設定 DSP 入札ロジックが JavaScript で公開されるという懸念 現在の設計では、入札ロジックの JavaScript に他者がアクセスできますが、DSP にとって懸念の種となる理由について、フィードバックをお寄せください。
prebid.js FLEDGE で prebid.js のサポートが開始されるまでのタイムラインを教えてください。 FLEDGE モジュールは、Prebid.js バージョン 7.14 以降でのみサポートされています。テストにご興味をお持ちのパブリッシャー様は、FLEDGE モジュールを追加し、Prebid インスタンスをアップグレードする必要があります。
FLEDGE のユーザー定義関数 FLEDGE ではユーザー定義関数（UDF）がどのようにサポートされますか？これらは、エンドユーザーがプログラムして API の機能を拡張できる関数です。 詳しくは、こちらをご覧ください。この機能は現在も開発中です。ユースケースに関する追加のフィードバックをお待ちしております。
インタレスト グループ リソースの同じオリジンの制約を緩和 特定の広告テクノロジーのユースケースを可能にするため、インタレスト グループ リソースの同一オリジン制約を緩和するようリクエスト FLEDGE の現在の実装では、biddingLogicUrl、biddingWasmHelperUrl、dailyUpdateUrl、trustedBiddingSignalsUrl のオリジンはインタレスト グループのオーナーと同じである必要があります。

この制約は、こちらで説明されているように、攻撃者による特定の悪用を防ぐために存在します。
interestGroup の所有権 広告テクノロジーがサイト間で同じインタレスト グループに対して joinInterestGroup を使用できるかどうかを制限するリクエスト Google は、オーディエンスの構築方法ではなく、オーディエンスの使用方法に重点を置いています。考えられるアプローチについて検討しており、皆様からの追加の意見をお待ちしております。
Key-Value サーバーキーの有効期限 対応するインタレスト グループの有効期限が切れた後のサーバーキーの削除に関するディスカッション Google は鍵の有効期限の処理方法を検討しており、フィードバックをお待ちしています。

デジタル広告の測定

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

フィードバックのテーマ 概要 Chrome の対応
オリジン トライアル トラフィック 現在のオリジン トライアルのトラフィックでは、ユーティリティ テストを実施するのに十分ではありません。 現在のオリジン トライアルは、エコシステムのプレーヤーが機能テストを実施して、API が想定どおりに動作することを確認することを目的としています。さまざまなプライバシー サンドボックス API の開発が成熟すると、ユーティリティ テストを実施するためにより多くのトラフィックが必要なことは認識しております。現在のテストのタイムラインでは、2023 年第 3 四半期の一般提供（ユースケース向けのテクノロジーがリリースされ、100% の Chrome トラフィックで利用可能になる時期）までに完了する予定です（最新のprivacysandbox.com のタイムラインをご覧ください）。トラフィックの増加を必要とするユースケースのテストについては、フィードバックをお寄せください。
さまざまなプライバシー サンドボックス測定 API の機能の重複 プライバシー サンドボックスで複数の測定方法が重複すると、複雑さが増す可能性があります（Attribution Reporting API や Private Aggregation API など）。 Google は、API のさまざまなユースケースを明確にするためにドキュメントの改善に取り組んでおります。説明が不足している点については、追加のフィードバックをお待ちしております。たとえば、Attribution Reporting API はコンバージョン測定をサポートすることを目的としていますが、Private Aggregation API と Shared Storage は、クロスサイト測定の幅広いユースケースをサポートすることを目的とした汎用 API です。
失敗したレポート リクエストを再試行する 報告リクエストが失敗した場合に、リクエストが試行される回数を明確にしました。 この件に関するガイダンスを公開しています。まとめると、レポートはブラウザが実行中またはオンラインの場合にのみ送信されます。最初の送信に失敗すると、5 分後にレポートが再試行されます。2 回目の失敗後、レポートは 15 分後に再試行されます。その後、レポートは送信されません。
レポートの遅延 レポートの遅延はどのくらいですか？ 報告の遅延について、エコシステムからフィードバックを募集し、遅延のさらなる評価のためにデータを収集しています。
ページをプリレンダリングする ARA アトリビューションはプリレンダリング ページで機能しますか？ 事前レンダリング ページでは、有効化（実際のクリックまたは視聴が発生する）までアトリビューション登録が延期されます。つまり、attributionsrc リクエストの ping は延期されます。
コンバージョン リフト測定 同じドメインで A/B テストを実施してコンバージョン リフト測定を行う方法 ウェブサイトでは、アトリビューション レポートを使用して、同じドメインで A/B テストを実施し、コンバージョン数の増加を測定できます。Aggregate API を使用して A/B パラメータをキーとしてエンコードし、それらのキーバケット別にコンバージョン値のサマリー レポートを受け取ることができます。
（第 3 四半期にも報告）クロスドメイン コンバージョン 2 つ以上のリンク先など、クロスドメインのコンバージョンをトラッキングする方法 第 4 四半期の更新:

クロスドメインの会話をトラッキングできるように、ランディング ページのリンク先に関する制限を削除する提案を公開しました。この提案は実装されました。
（Q3 でも報告）
コンバージョン レポートの有効期限の設定		 レポートのフィルタ / 有効期限を 24 時間未満に設定できるようにするリクエスト 第 4 四半期の更新:

このプルリクエスト では、有効期限とレポート期間を切り離し、レポートの遅延とコンバージョンの有効期限のトレードオフを軽減します。M110 でリリースされました。
不正行為と不正使用 広告主とマーケティング担当者から、広告が配信されるパブリッシャーのサイトに基づいてデータを分割して集計できるようにし、不正な広告行為の可能性に関する分析情報を提供できるようにしてほしいというリクエスト このフィードバックは こちら で積極的に議論されており、追加の意見をお待ちしております。
（第 3 四半期にも報告）イベントレベルのレポートの遅延 イベントレベルのレポートの遅延が 2 ～ 30 日間と長すぎる場合、特定のユースケースでは適切でない可能性があります。 イベントレベルのレポートのデフォルトのレポート期間は 2 日間、7 日間、30 日間です。これは、expiry パラメータを使用して変更できます。広告テクノロジーは、2 日以内に潜在的なレポートを取得できるように、有効期限を 1 日以上で設定できます。よりきめ細かいレポートはタイミング攻撃につながる可能性があるため、Google はプライバシー保護メカニズムとして有効期限の粒度を 1 日に制限しています。また、イベント単位レポートと集計レポートに独立した「有効期限」パラメータを設定することもできます。詳しくは、こちらをご覧ください。また、Google 広告では、他の広告テクノロジーが Attribution Reporting API 経由で取得できない特別なレポート期間は提供されません。
同じ報告元の要件 参照元の登録元がコンバージョンの登録元と同じであるという要件を削除するようリクエスト このユースケースを解決するには、HTTP リダイレクトを使用して登録を委任することをおすすめします。新しいガイダンスについて、追加のフィードバックをお待ちしております。
コンバージョン トラッキング 広告主が設定した特定の時間帯の前後にコンバージョンが発生したかどうかを区別する必要がある Attribution Reporting API は、ソース アトリビューションの有効期限と優先度の設定をサポートしています。両方を使用すると、X 日以内に発生したコンバージョンと X 日以降に発生したコンバージョンを別々にアトリビューションできます。
ノイズ シミュレーション バケットごとに異なるコンバージョン数をシミュレートして、コンバージョン数が少ない広告主への影響を把握できるようにリクエスト 今後の Noise Lab のバージョンでは、このシミュレーション方法を追加する予定です。他にご意見がございましたら、ぜひお寄せください。
モバイルでのレポート モバイルで Chrome がバックグラウンドで実行されている場合、報告は送信されますか？ 現時点では、モバイルでも Chrome がバックグラウンドにある場合は報告は送信されません。これは、API が Android プライバシー サンドボックスと統合されたときに変更される可能性があります。詳しくは、こちらをご覧ください。Android プライバシー サンドボックスは、CMA が承認したコミットメントの一部ではありません。
データの可用性 Google がプライバシー サンドボックス API を介してデータにさらにアクセスできるようになるという懸念 まず、Google 広告は、Attribution Reporting API やその他のプライバシー サンドボックス API からデータに優先的にアクセスする権限を付与されていません。この問題については、[一般的なフィードバック] セクションの [相互運用性] でも説明しています。このセクションには、Google の取り組みの詳細も記載されています。

次に、大規模なサイトと小規模なサイトの違いについて説明します。Google は、ノイズベースのプライバシー保護が小規模なデータスライスに大きな影響を与える可能性があることを認識しています。ただし、緩和策はいくつかあります。たとえば、長い期間にわたる集計などの方法でこの問題を解決できます。ただし、非常に小さなデータスライス（1 回または 2 回の購入など）に基づく結論が広告主にとって有意義であるかどうかは不明です。オリジン トライアルでは、テスト参加者に、プライバシーとノイズに関する幅広いパラメータをテストして、この問題に関するより具体的なフィードバックを送信するよう依頼しました。

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

User-Agent の情報量削減

フィードバックのテーマ 概要 Chrome の対応
ウェブ エコシステムの準備が整うまでユーザー エージェントの情報量削減を延期 ユーザー エージェントの削減に関する今後の変更に対応するための十分な時間がない。 このフィードバックについては、レポート全文の「ステークホルダーの懸念」の「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 とフィンガープリント手法を包括的なアプローチでテストする方法に関するガイダンス Google のテスト計画は、サンドボックス プロポーザルの他の部分とは対照的に、一部の指紋防止対策の開発の非同期タイムラインを反映するように設計されています。これは、一部のフィンガープリント対策（プライバシー バジェット、IP 保護、バウンス トラッキング緩和策）が、サードパーティ Cookie のサポート終了後に完全に開発され、一般提供の準備が整うという現実に対応しています。

これらの指紋防止対策は定量テストには含まれませんが、停止時に利用可能な事実に基づいて定性的な評価を受けます。
（第 2 四半期にも報告）
パフォーマンス		 Critical-CH を介したヒントの取得の遅延に関する懸念（最初のページ読み込み時） 下記の UA-CH 専用のセクションをご覧ください
フィードバックが不十分 UA-CH の変更に関するエコシステムからのフィードバックが十分でない場合、エコシステムの認識不足が懸念されます。 Google は、中断を最小限に抑えながら慎重にロールアウトを行うため、計画を事前に共有してきました。

ユーザー エージェントの削減と UA-CH API の計画は、2022 年 3 月 18 日に W3C 不正行為防止コミュニティ グループに、2022 年 1 月 20 日にウェブ決済ワーキング グループとウェブ決済セキュリティ インタレスト グループの両方に提示されました。プレゼンテーション中やプレゼンテーション後に、重大な懸念は提起されませんでした。

Google は、100 を超えるサイト運営者と積極的に連携してフィードバックを得ています。さらに、Google は Blink-Dev チャンネルを使用して、エコシステムのステークホルダーからのフィードバックに基づいて、ユーザー エージェントの削減のロールアウトを一般に公開しました。
タイミング ロールアウトのタイミングと業界の準備状況に関する懸念 下記の UA-CH 専用のセクションをご覧ください。
Chrome プラットフォームのステータス UA-CH の chromestatus ページの更新をリクエストしました chromestatus のエントリは 12 月 19 日に「Mixed signals（混合シグナル）」に更新されました。

IP 保護（旧 Gnatcatcher）

フィードバックのテーマ 概要 Chrome の対応
オプトインまたはオプトアウト IP アドレスのプライバシーはオプトインですか？オプトアウトですか？ YouTube は、すべてのユーザーに IP 保護を提供することを目標としています。Google は、その目標を念頭に置いて、IP 保護に関するユーザー選択オプションを現在検討しています。
ファーストパーティ データの IP アドレスのユースケース IP 保護後に、IP アドレスを使用してファーストパーティ ドメイン全体のユーザー ジャーニーをつなぎ合わせることはできますか？ 以前にお知らせしたとおり、IP 保護は最初はサードパーティ コンテキストでのトラッキングに重点を置きます。つまり、ファーストパーティ ドメインには影響しません。
広告テクノロジーのユースケース IP 保護で不正行為対策を設定するにはどうすればよいですか？ Google は、今日のウェブにおける不正行為防止の取り組みにおいて、IP アドレスが重要なシグナルであることを認識しています。Google は CMA へのコミットメント（第 20 項）の一環として、ウェブサイトがスパム対策と不正行為対策を実施できるように合理的な努力を払わない限り、IP 保護を実装しないことを表明しています。Google は、IP 保護が不正行為防止のユースケースと検出機能にどのように影響するかを理解し、企業がウェブの安全性を維持するのに役立つプライバシー保護技術にさらに投資することを最優先事項としています。シグナルが時間とともに変化しても、セキュリティ企業や不正行為防止企業のニーズをサポートすることを目的としたフィードバックと新しい提案に関するご意見をお寄せください。
不正行為と不正使用 IP 保護にはサービス拒否（DoS）攻撃に対する保護が含まれていますか？ Google は、ウェブの安全性を維持しながらプライバシーを強化することに取り組んでいます。サービス拒否攻撃からの保護は、不正使用防止の重要なユースケースであり、設計時に考慮する必要があります。Google は、IP 保護自体の設計と新しい不正使用防止ソリューションの両方を通じて、DoS 防御への影響を最小限に抑えることを目指しています。IP 保護は当初、サードパーティの埋め込みサービスに重点を置いているため、一部の関係者は、ファーストパーティ サイトの DoS 保護への影響は限定的であるべきだと指摘しています。ただし、DoS のユースケース（特にサードパーティの埋め込みサービス）に対するリスクを評価するため、引き続き一般からのフィードバックをお願いしています。

また、サイトやサービスがスパム行為を行うユーザーを特定することなくブロックできるようにする、不正行為に関するフィードバックとクライアント ブロックのメカニズムも併行して調査しています。
コンテンツ フィルタ IP 保護によるコンテンツ フィルタリング コンテンツのフィルタリングやユーザー エクスペリエンスのカスタマイズに関して、企業によってニーズは異なります。このようなユースケースの多くは現在 IP アドレスに依存していないため、IP Protection の影響を受けません。たとえば、コンテンツをカスタマイズしてエンゲージメントを高めようとしているニュース メディアは、ファーストパーティ Cookie またはサードパーティのパーティショニング Cookie（CHIP）を使用して、ユーザーの興味 / 関心やニュース メディアとの過去のインタラクションを把握できます。または、適切なユーザーに適切な広告を配信することに重点を置く広告テクノロジー パートナーは、FLEDGE と Topics を組み込んで、サードパーティ Cookie やその他のクロスサイト トラッキング技術で実現しているような広告成果を実現できます。

また、既存のメカニズムが不十分な場合にコンテンツ フィルタリングをさらにサポートできるよう、IP 保護に新しいプライバシー保護機能（大まかな位置情報など）を組み込むことも検討しています。IP 保護の影響を受ける可能性があるコンテンツ フィルタリング ユースケースについて、追加のフィードバックをお寄せください。
（第 3 四半期にも報告）
位置情報のユースケース		 IP 保護により、位置情報に基づくコンテンツのパーソナライズなど、正当な位置情報のユースケースが今後機能しなくなる可能性があります。 第 4 四半期の更新:

Google は、IP アドレスの正当なユースケースを Chrome で引き続きサポートできるよう、関係者と連携して取り組んでいます。IP 位置情報の粒度に関するエコシステムからのフィードバックは、こちらからお寄せください。

プライバシー バジェット

フィードバックのテーマ 概要 Chrome の対応
より明確なドキュメント プライバシー バジェットが実装された後の制限事項を関係者が予測できるように、例を追加しました プライバシー バジェットの提案はまだ議論中であり、どのブラウザにも実装されていません。スケーリングされた可用性の開始日は、プライバシー バジェットを適用できる最短日付を表します。2024 年にサードパーティ Cookie が廃止されるまでは、この機能は使用できません。現時点では、お知らせできる追加のドキュメントはありません。

提案が確定しましたら、詳細をお知らせいたします。提案書の作成に役立つフィードバックをお寄せください。

クロスサイト プライバシー境界の強化

ファーストパーティ セット

フィードバックのテーマ 概要 Chrome の対応
（第 3 四半期にも報告）ドメインの上限 関連付けられたドメイン数の増加をリクエストする 第 4 四半期の更新:

ローカルテスト用の FPS をリリースしました。これには、GitHub でのモックセット送信プロセスと、rSA と rSAFor をローカルでテストするためのフラグが含まれます。また、FPS に関するデベロッパー向けの公開ミーティングを 2 回開催し、関連するサブセットのユースケースに関する質問に引き続き対応しました。デベロッパーの皆様には、FPS 機能をテストして、関連するサブセットのドメインの上限がユースケースでの FPS のユーザビリティにどのように影響するかについてフィードバックを提供することをおすすめします。

WICG のコールでは、Chrome はユーザーのプライバシー保護にも配慮した実用的なソリューションを提供することに取り組んでいることを明確にしました。そのため、ドメイン数の上限の影響を受ける可能性があるユースケースについて、コミュニティからのフィードバックをお寄せいただければ幸いです。これにより、ユーザーのプライバシーを保護しながら、こうしたユースケースに対処する方法を検討できます。
不正行為の軽減対策の詳細をリクエストする 同意していないセットにドメインが追加された場合、どうなりますか？ ファースト パーティ セットの送信ガイドラインは、2022 年 12 月 2 日に こちらで公開されています。

送信ガイドラインで説明されているように、セットの変更管理では、所有権の検証など、GitHub の検証プロセスに従い、このリスクを軽減します。
不正行為の軽減 ファーストパーティ セットの作成が悪用される可能性があるという懸念 YouTube は、サブセット タイプの技術的なチェックを拡大する方法を検討しており、こちらでコミュニティからの追加の意見を積極的に求めています。
広告のユースケース 広告ターゲティングをサポートするためにファーストパーティ セットを使用するかどうかに関する質問 ファーストパーティ セットの広告ターゲティングのユースケースはサポートされていません。このようなユースケースには、広告 API を使用することをおすすめします。
（第 3 四半期にも報告）ポリシー GDPR ではセット内のサイト数に上限が設けられていないのに対し、FPS では 3 件の上限が設けられていることを根拠に、FPS が「適用されるデータ保護法」に関する CMA のコミットメントに準拠していないという懸念 回答は質問 3 と変わりません。

「Google は、Google 自身のビジネスを優先することで競争を歪めない方法でプライバシー サンドボックスの提案を設計し、実装し、デジタル広告、パブリッシャー、広告主の競争への影響、プライバシーの結果への影響、適用されるデータ保護法に規定されているデータ保護原則への準拠を考慮することを CMA に引き続き約束します。懸念事項には、GDPR との非互換性が示唆されていません。Google は、これらの取り組みがこれらのコミットメントに準拠していることを確認するため、CMA と引き続き緊密に連携していきます。」
代替案 GDPR 検証済みセット 「GDPR 検証済みセット」を採用する提案についてエコシステムから寄せられたフィードバックに加えて、Chrome では、この代替案の次の制限事項について懸念しています。

  • 「GDPR 検証済みセット」は、GDPR に「準拠」していると主張しています（ただし、その意味は明確ではありません）。一方、Google のコミットメントでは、より一般的な「プライバシーへの影響」を考慮することが求められています。コミットメントを承認する決定の中で、CMA は、これは「適用されるデータ保護法に定められたデータ保護原則への準拠」を考慮する Google の義務とは異なると指摘しています。CMA は、これは Google が適用されるデータ保護法に拘束されているという事実を反映していると説明しています。これは、コミットメントに適用される場合と、より一般的な場合の両方に該当します。
  • ドメインを複数のセットに表示できるようにする提案について、プライバシーに関する懸念があります。ファーストパーティ セットは、現在サードパーティ Cookie に依存している特定のユースケースをサポートすることを目的としています。ただし、広範なクロスサイト トラッキングを有効にする必要はありません。ドメインが複数のセットに参加できるようにすると、ファーストパーティ セットの提案に組み込まれている重要なプライバシー保護が削除され、他の有意な制限が導入されることもありません。
  • GDPR 検証済みセットでは、「共通の使用ポリシーを共有するデータ管理者と処理者のグループとしてセットを定義する」ことも提案されています。これは、セット内のすべての関係者が共通のプライバシー ポリシーを共有する必要があるという、元のファースト パーティ セットの提案の要件に似ています。その後、プライバシー ポリシーに基づく要件について懸念が提起されたことを受け、エコシステムからの強いフィードバックに基づいて、その要件を削除しました。たとえば、サイト パブリッシャーからは、商品や地域の違いなど、W3C コミュニティのメンバー（1、 2、3）から提起されたその他の課題により、共通のプライバシー ポリシーを維持することは現実的ではないという意見が寄せられています。同じ問題がこの提案にも当てはまると考えています。

この代替案が提案されてから、Chrome はファーストパーティ セットの提案を更新し、新しいセットを作成する送信ガイドラインを公開しました。

Fenced Frames API

フィードバックのテーマ 概要 Chrome の対応
残業中のフェンス付きフレームの制限 オリジン トライアル期間中の Fenced Frames に関する現在の制限事項は何ですか？ 制限と実装ステータスに関するドキュメントを作成中です。2023 年第 1 四半期に公開する予定です。
1 つのフェンス付きフレーム内の複数の広告 1 つのオークションで 1 つのフェンス付きフレームに複数の広告主を表示するリクエスト 現在、このリクエストは積極的に開発されていません。しかし、エコシステムのプレーヤーがこの機能を重要と考えている場合は、追加のフィードバックをお寄せください。
ウェブバンドル フェンスド フレームを使用したウェブバンドルの要件とサポート予定について教えてください。 今後この要件が適用されるかどうかについては、現時点では未定です。変更がある場合は事前にお知らせします。また、サードパーティ Cookie のサポート終了前に適用されることはありません。現在の状況については、こちらの説明をご覧ください。

Shared Storage API

フィードバックのテーマ 概要 Chrome の対応
広告テクノロジー向けの共有ストレージ 広告テクノロジーのユースケースでの共有ストレージの使用に関する不確実性 Shared Storage API と Private Aggregation API は、クロスサイト ストレージ測定が必要なさまざまな測定目的に使用できます。例については、こちらをご覧ください。

Google は、DSP と測定ソリューション プロバイダが広告のユースケースの主要な統合プロバイダになると予想しています。

CHIPs

フィードバックのテーマ 概要 Chrome の対応
（Q3 でも報告）パーティション分割の要件 ファーストパーティ Cookie の「パーティショニング」属性に明示的な動作要件を追加しました。 第 4 四半期の更新:

GitHub と PrivacyCG のコールでの議論の結果、ファーストパーティ Cookie に設定されたパーティショニング Cookie は、パーティション キー（A,A）を使用します（A はトップレベル サイト）。この動作は、説明と仕様で文書化されます。
Cookie の管理 ファーストパーティ 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] ごとに一意の匿名 ID を作成」する必要はありません。むしろ、FedCM では、各 IdP がユーザーの実際の ID、その ID のサイトごとのバージョン、またはこの情報の他のバージョンを共有するかどうかを選択できます。

（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）を含む同一サイトのフォーム送信に使用できますか？ これは現在、プライベート ステート トークンの最初のバージョンではサポートされていません。このユースケースに対する需要が強い場合は、エコシステムからのフィードバックをお待ちしています。
サーバーサイド認証 プライベート ステート トークンをサーバーサイドで検証できるかどうかに関する質問 トークンは発行元に対して利用され、発行元はトークン自体またはトークンから派生した署名付き値を含む利用履歴レコードを作成します。サーバーは、その利用履歴レコードを使用してトークンの真正性を確認できます。発行元のエコシステムによって、利用履歴レコードの解釈方法が異なる標準が出てくることが予想されます。