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

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

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 API、Protected Audience API、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 の対応
エコシステムの準備状況 SSP は、パブリッシャーが準備ができておらず、必要なデプロイ作業を行っていないことを懸念しています。 プライバシー サンドボックスでは、パブリッシャー向けの教育に特に重点を置いたアウトリーチを行っています。これには、パブリッシャーと SSP の両方に参加してデプロイ作業を促進する専用のウェビナーやミーティングが含まれます。
サードパーティ Cookie のサポート終了 業界のテクノロジー ブラックアウトにより、2023 年第 4 四半期にサードパーティ Cookie の廃止（3PCD）に関する懸念が高まっています。 プライバシー サンドボックスのタイムラインは CMA と協議され、2024 年後半の準備に向けて順序付けられています。プライバシー サンドボックスでは、3PCD の段階的な導入の順序に関する詳細情報を公開します。コミットメントに基づき、3PCD は CMA の競争に関する懸念に対処する必要があります。
Google アド マネージャー Google アド マネージャーは API サーフェスを公開しないため、テストが困難です。 Google アド マネージャーから提供された回答: Google アド マネージャーからのこの回答で説明されている理由により、Google アド マネージャーの Protected Audience API 統合の計画では、最上位オークションを制御しない Google のパブリッシャー広告サーバーのサポートは含まれていません。
Google アド マネージャー Google アド マネージャーには、AdX または Open Bidding SSP にのみ公開される秘密の最小価格があります。 Google アド マネージャーの公開ドキュメントでは、コンテキスト オークションの落札者は、AdX や Open Bidding などのコンポーネント オークションではなく、最上位のスコアリング ロジックに渡されると記載されています。
さらに、そのドキュメントでは、トップレベルのスコアリング ロジックについて次のように説明しています。「アド マネージャーは、各コンポーネント オークションの落札入札単価（アド マネージャー独自のコンポーネント オークションによる購入者のインタレスト グループ入札単価や、最適なコンテキスト広告（ダイナミック アロケーションで選択）など）を比較し、最も高い入札単価の広告を配信します。」
Google アド マネージャー Google 広告サービスは、サードパーティの広告サービスと同じルールが適用される必要があります。 Google 広告サービスには、すでに第三者と同じルールが適用されています。
Chrome 主導のテスト A または B にないブラウザのラベルを追加します。 調査の結果、テスト以外のラベルを追加すると、シークレット モードでのトラフィックに関するプライバシーに関する懸念が複雑になる可能性があることが判明したため、現時点ではそうした対応は検討していません。
広告代理店 ウェブサイトに JavaScript がない代理店や企業は、プライバシー サンドボックス API を使用できますか？ プライバシー サンドボックス API は誰でも呼び出すことができます。代理店やその他のユーザーが API に直接技術を構築したい場合は、構築できます。クライアントサイド API は、Cookie と同様にクライアントとの統合が必要です。多くの API には、Cookie と同様に HTTP ヘッダー インターフェースもあります。すでに、広告業界のフレームワークである Prebid が、API とのクライアントサイド統合を構築しています。他の組織も同様に行うことができます。
クライアントサイド ソリューション 2012 年にエンジニアがそのようなソリューションのスケーラビリティについて懸念を表明しているのに、Google がプライバシー サンドボックスにクライアントサイド ソリューションを採用するのはなぜですか？ 研究分野としてのプライバシー強化技術（PET）は 2012 年以降、大幅に進歩し、商業的に利用可能なアプリケーションも進歩しました。プライバシー サンドボックスの中核となるのは、10 年以上前には実現できなかった PET の組み合わせです。また、個人の計算能力は向上し、ブラウザに対する消費者の期待やプライバシーに関する規制の期待も高まっています。
機械学習 Google は、機械学習の目的でプライバシー サンドボックスをどのように使用する予定ですか。 現在、広告テクノロジー エコシステムの多くは機械学習を使用しており、この状況は今後も変わらないと予想されます。プライバシー サンドボックスは、広告テクノロジー企業やその他のユーザーが機械学習を引き続き使用することを妨げるものではありません。また、プライバシー サンドボックスでは、API を統合する企業が機械学習を使用する必要もありません。機械学習が含まれるかどうかにかかわらず、企業は顧客のニーズを満たす方法でプロダクトとサービスを構築し続けることが合理的です。プライバシー サンドボックス インテグレータが構築する機械学習は、明らかにインテグレータに知られているため、インテグレータにとって不明瞭なものではありません。
データ検証 企業は、プライバシー サンドボックスの使用によって受け取ったデータが正確であることをどのように確認できますか？また、Google は Media Ratings Council（MRC）などの機関による審査を受けることができますか？ Privacy Sandbox API は、Chrome を支えるオープンソース プラットフォーム内に構築されています。Trusted Execution Environment で実行することを目的とした API の部分もオープンソースであり、監査可能です。コードを検査したい人なら誰でも、MRC を含むすべての人が検査できます。
（前四半期にも報告）本番環境サポート Chrome で、エコシステムに影響するプライバシー サンドボックスの技術的な問題やエスカレーションをサポートするためのプロセスはどのようなものですか？ Google は、広告テクノロジーが技術的な問題を報告し、問題の解決に必要なエスカレーションを可能にするためのさまざまなチャネルを提供しています。さらに、Chrome では、エコシステムの健全性に影響する技術的な問題やエスカレーションを解決するためのプロセスをさらに構築し、拡大していく予定です。Chrome は、この取り組みに必要なリソースを確保することに取り組んでいます。
フィードバックとエスカレーションについては、公開フォーラムと限定公開フォーラムをご覧ください。
Chrome 主導のテストモード Chrome 主導のテストのタイムラインと正確な実装に関する詳細 テストモードに関するブログ投稿を公開しました。近日中に詳細をお知らせする予定です。
テストモードのラベルのサイズについては、ご意見をお寄せください。
他の業界標準との統合 Privacy Sandbox API は、TCF v2.* と同意モードのどちらか、または両方に接続しますか？ プライバシー サンドボックス API を TCF v2 または同意モードと直接統合する予定はありません。ただし、企業や業界団体は、プライバシー サンドボックス API と連携するようにプロダクトやフレームワークを調整できます。たとえば、TCF などのフレームワークでは、各参加者は、受信した TCF シグナルと関連する TCF ポリシーに基づいて、独自のコンプライアンス アプローチを決定する必要があります。企業は、プライバシー サンドボックスの構成要素が提供するさまざまな機能を、いつ、どのように使用するかを判断する必要があります。

登録と構成証明

フィードバック テーマ 概要 Chrome の対応
制限 登録プロセスとは、エコシステム内のどの企業がプライバシー サンドボックス API の使用を許可されるかを Google が決定できることを意味します。 登録と構成証明のプロセスでは、基本的にエンティティの確認（エンティティに DUNS ナンバーがある、プライバシー ポリシーへのリンクを提供できるなど）が行われ、API の呼び出しには公開構成証明が必要になります。登録要件を満たすことができるエンティティが検証されます。DUNS をお持ちでない企業様向けに、Dun & Bradstreet との提携により、DUN を取得するための迅速な手続きを無料で提供しています。目的は、（前述の対策によって）API のプライバシー保護を強化することと、プライバシー サンドボックス API に透明性を追加することです。これにより、関係者は、どの API がどのユーザーによって使用され、どのような構成証明が行われているかをよりよく把握できます。この問題に関する業界からのフィードバックは引き続き受け付けており、すでにプロセスの策定に活用されています。
再登録のオーバーヘッド 構成証明ファイルは 12 か月ごとに期限切れになり、ウェブサイトは再登録する必要があります。 エコシステムからのフィードバックを参考に、アプローチを修正しました。つまり、ファイルは 12 か月間や一定の期間が経過しても期限切れになることはありません。登録に関するデベロッパー ガイドを更新し、コンテキストを追加しました。
構成証明ファイル 構成証明ファイルはどのように使用されますか？ 関連性と測定 API を呼び出すすべての企業は、適用期限までに証明書ファイルをサイトにアップロードし、API の呼び出しを継続する限り公開状態にする必要があります。

ウェブサイトは、プライバシー サンドボックスから 1 時間あたり約 1 件のリクエストを想定できます。また、他のエンティティがクエリを実行する可能性もあります。これは、登録システム独自のメカニズムを使用して登録済みエンティティのサーバーをクエリし、構成証明ファイルが有効であることを確認することで行われます。

証明書は透明性レポートに含まれ、一般公開されます。Google は、他のエコシステムや関連する規制機関と同様に、企業が表明した証明書に従って行動することを期待しています。
登録 登録はサイトごとですか、参照元ごとですか？ 登録はサイト単位で行います。

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

トピック

フィードバック テーマ 概要 Chrome の対応
パフォーマンス 欧州経済領域におけるトピックのオプトイン率の影響によるパフォーマンスに関する懸念。 関係するステークホルダーには、この問題について関連するデータ保護機関にお問い合わせいただくことをおすすめします。このような懸念に対処し、プライバシー保護技術の適用が法律によって奨励されるか、トラッキングと同様に扱われ、同意に対して同じアプローチが求められるかを決定するには、政府が最適な立場にあります。後者の場合、プライバシー サンドボックスの API などの使用頻度が低下する可能性があります。
登録 ダウンストリームのビッダーは、アップストリームの SSP からの Topics シグナルを使用するには Topics API に登録する必要がありますか？ 最初の Topics API 呼び出し元以外のトピックのダウンストリーム レシーバーは登録する必要はありませんが、多くの場合、他の API の使用のために登録されます。プライバシー サンドボックスの登録者のリストは、プログラムの透明性向上の一環としてプログラムによって提供されます。これにより、Topics API の呼び出し元は、トピックを送信する受信者が登録されているかどうかを確認できます。
トピックのフィルタリング 購入者が取得できるトピックのみを共有するために、別の呼び出し元がページで取得するトピックに別の呼び出し元のフィルタを適用するようリクエストします。 Google はこのリクエストを検討しており、エコシステムからの追加のフィードバックをお待ちしております。
サイトの除外 ユーザーのトピックの作成にウェブサイトを除外する。 トピックはデフォルトでは呼び出されません。トピックの選択時にはページのコンテンツは考慮されず、すべてのトピックはデリケートな内容が含まれていないことを確認してキュレートされます。ウェブサイトは、次の権限ポリシー ヘッダー Permissions-Policy: browsing-topics=() を使用して、サイトがトピックの計算に含まれないように制限することもできます。
トピックのモニタリング ページのコンテンツ（ヘッドや本文など）に基づいてトピックを分類する権限を Chrome に付与することをパブリッシャーが許可できるようにします。 Google は以前、ページのコンテンツに基づいてサイトをトピックに分類する機能を提供することを検討しましたが、プライバシーとセキュリティに関する懸念から、この機能の提供を中止することにしました。この提案により、こうした懸念の一部は軽減される可能性がありますが、どの程度軽減されるかは不明です。今後の CMA テスト期間中は、3PCD より前にこの変更が行われることは想定されません。追加のフィードバックをお待ちしております。
トピックのモニタリング パブリッシャー向けのよりきめ細かい権限ポリシーを提供します。 ニュース メディアによりきめ細かい権限ポリシーを提供することで、ニュース メディアのサイトは、サイト自体の Topics API の有用性に悪影響を及ぼすことなく、エコシステム全体の Topics API の有用性に悪影響を及ぼすことができます。このトピックについて詳しくは、GitHub の問題 Update permissions policy to support separate permissions for retrieve and observe をご覧ください。
医療と健康に関するトピック トピック分類に、医療や健康のカテゴリのトピックが含まれていないのはなぜですか？ 医療と健康のカテゴリはデリケートなトピックと見なされるため、Topics 分類から除外されます。
トピックの取得 DSP がヘッダーを使用して取得することなく Topics を取得するより速い方法。 ヘッダー メソッドは、クロスオリジン iframe を作成してそこから document.browsingTopics() を呼び出すよりも、パフォーマンスが高く、費用もかかりません。（トピックをモニタリングする最上位のコンテキストは、トピックにアクセスするコンテキストと一致している必要があるため、呼び出しにはクロスオリジン iframe を使用する必要があります）。詳しくは、こちらをご覧ください。
トピックの取得 クロスオリジン スクリプトタグ リクエストでヘッダーを介して Topics を渡すことをサポートするためのリクエスト。 セキュリティの観点から、これはできません。各ドキュメントとその実行環境は、ドキュメントの単一のオリジンに関連付けられます。同じ環境内で読み込まれて実行されるサードパーティのサブリソースは、ドキュメントのオリジンによって所有されていると見なされます。これは、同意のないデータがオリジン間で漏洩するのを防ぐためです。

別の方法として、<script> タグに browsingTopics 属性を指定することもできます。これはセキュリティの観点からクリーンであり、追加のレイテンシを追加しない必要があります。ご関心をお持ちの皆様からの フィードバックをお待ちしております。
認知度 Topics API とその使用方法に関する一般の認知度を高める。 このフィードバックを送信したステークホルダーと連携し、この問題は GitHub で解決されました。

今後も、API に関するエコシステムの理解をサポートし、関係者からの意見をお待ちしております。なお、Topics API について詳しく知りたい関係者は、Chrome デベロッパー ガイドのドキュメントをご確認ください。
通知 トピックがウェブサイトによって監視されていることをユーザーに知らせるための通知。 このフィードバックには GitHub で対応しました。トピックの管理について詳しくは、Chrome ヘルプセンターをご覧ください。
機械学習 ML を使用してユーザーのトピックを推測する方法 Google では現在この問題について検討しており、追加のフィードバックをお待ちしております。
さまざまなステークホルダーにとっての有用性 小規模な広告テクノロジー企業は、ブラウザが Topics を計算する方法が原因で、Topics を観測できない場合があります。 トピックを受信できるのは、過去 3 週間以内に該当するトピックに関するページにユーザーがアクセスしたことが確認された広告テクノロジーのみです。広告テクノロジーが、そのトピックに関するサイト上で、そのユーザーに対して過去 3 週間 API を呼び出していない場合、返される値は空になります。

この機能により、より多くのサイト所有者がサービスを使用し、特定のユーザーによるサイト訪問を観察する機会が多い広告テクノロジーは、他の広告テクノロジーよりも多くのトピックを受け取る可能性があります。この機能は、ユーザーに関する情報の利用を、（現在はサードパーティ Cookie を介して）同じ基盤となる情報をすでに確認できる関係者のみに制限するため、API のプライバシー保護に不可欠です。
XHR リクエスト XMLHttpRequest（XHR）リクエストでの Topics のサポートが終了するのはいつですか？ Chrome は 2023 年 8 月に発表したとおり、オリジン トライアルから一般提供に移行する際に XHR のサポートの非推奨を開始しました。

トピックの導入が進むにつれて、XHR のサポートは OT 機能が有効になっているユーザーにのみ含まれるようになり、個々の OT テストグループが統合された時点で完全に非推奨になりました。

XHR で Topics を使用していた場合、サイトは機能しなくなることはありません。トピックは XHR リクエスト ヘッダーに追加されません。リクエストを fetch に移行するか、iframe 属性を使用するか、JavaScript API を使用してトピックを取得することをおすすめします。フェッチはすべての最新ブラウザでサポートされていますが、Internet Explorer や Opera Mini ではサポートされていません。
分類と分類システムの更新プロセス Topics 分類と分類システムのリリース頻度、および企業がこのような更新に備える方法について詳しくは、こちらをご覧ください。 回答は Q2 から変更されていません。

最近のブログ投稿で説明したとおり、分類は時間の経過とともに進化し、最終的には業界全体のステークホルダーを代表する外部関係者に分類のガバナンスが移行される予定です。また、topics-announce グループで段階的な導入計画も共有しました。
不正使用 リダイレクト チェーンによる潜在的な攻撃。 Google はこの問題を検討しており、皆様からのフィードバックをお待ちしております。
パブリッシャーの広告枠の種類 保護されたオーディエンスとトピックのテストでは、どのようなタイプのパブリッシャー広告枠がサポートされますか？ Protected Audience と Topics はどちらも、使用できる広告枠の種類に関して本質的に制限はありません。
立ち上げ時間 新しい分類が 100% に達するまでの調整期間は設けないことをおすすめします。 エコシステムからのフィードバック リクエストと PATCG ミーティングでの議論を受けて、新しい分類のロールアウト計画を発表しました。

Protected Audience API（旧 FLEDGE）

フィードバック テーマ 概要 Chrome の対応
トップレベル オークション Google アド マネージャーにトップレベルの Protected Audience API オークションの制御権限を付与せずに、Google のパブリッシャー広告サーバーを使えるようにする。 Google アド マネージャーから提供された回答:
Google アド マネージャーの Protected Audience API に関する計画では、次の理由により、トップレベルの Protected Audience オークションを制御せずに Google のパブリッシャー広告サーバーをサポートする予定はありません。

パブリッシャーの広告配信市場でお客様に適切にサービスを提供するために、Google のパブリッシャー広告サーバーでは、最上位の Protected Audience オークションを制御する必要があります。パブリッシャー広告サーバーとしての Google の役割は、パブリッシャーがオーバーブッキングすることなく直接販売キャンペーンを交渉できるように予測を提供し、直接予約を最適にペース設定して配信することです。これを行うには、最終オークションを実行して、対象となるすべての直接デマンドと間接デマンドを比較する必要があります。

予測とペース設定は、パブリッシャーが広告サーバーから期待するコア機能です。正確な予測がないと、広告枠の販売が過剰になり、ビジネスの評判を損なう可能性があります。ペースも重要です。広告主との予約契約を履行できないと、パブリッシャーと広告主の直接的な関係が損なわれるリスクがあり、パブリッシャーのビジネスに大きな影響を与える可能性があります。

つまり、パブリッシャーの広告サーバーがトップレベルの Protected Audience オークションを実行するアクティビティは、パブリッシャーの広告サーバーの他のアクティビティとは異なるものとして見なされません。
directFrom
SellerSignals		 directFrom
SellerSignals
: Google アド マネージャーがコンテキスト オークションの価格をパブリッシャーに表示しないようにします。		 Chrome の回答:
runAdAuction() に渡される情報は、販売者が独自の iframe から runAdAuction() を呼び出さない限り、販売者からのものであるとは限りません。複数販売者オークションでは、すべての販売者が runAdAuction() を呼び出すフレームを作成することはできません。directFromSellerSignals では、販売者のオリジンから読み込まれたサブリソース バンドルからコンテンツを読み込むことで、この問題に対処しました。これにより、販売者オークションの構成からオークションに渡される情報の真正性と完全性が不正に操作されることがなくなります。パブリッシャーが Protected Audience API を使用して、テクノロジー プロバイダが Protected Audience オークションに渡している情報を把握したい場合は、テクノロジー プロバイダにこの機能をリクエストできます。

Google アド マネージャーから提供された回答:
Google は長年にわたり、オークションの公平性に重点を置いてきました。たとえば、非保証型広告申込情報の価格など、パブリッシャーの非保証型広告ソースの価格を、オークションで入札する前に他の購入者と共有しないことを約束しています。この約束は、フランス競争当局へのコミットメントで改めて確認されています。

Protected Audience オークションでは、directFromSellerSignals を活用して約束を守り、マルチ販売者オークションでオークションが終了するまで、オークション参加者の入札価格を他のオークション参加者と共有しない予定です。なお、トップレベルのオークションのダイナミクスの詳細を明確化の更新で説明したとおり、コンテキスト オークションの価格は Google 独自のコンポーネント オークションとも共有されません。
情報露出 機密性の高いビジネス ロジックや契約の詳細がブラウザによって公開される可能性があります。 ウェブブラウザを使用しているユーザーは、ブラウザで発生しているすべてのことを確認できます。ブラウザ内で広告オークションが行われる場合、そのブラウザのユーザーは、さまざまな参加者が入札する金額など、オークションの進行状況を確認できます。ブラウザはユーザーのエージェントであるため、これを変更することは可能でも望ましいことではありません。ただし、これらのオペレーションは、ブラウザを使用しているユーザーのみが確認できます。Protected Audience API を使用して実行されるデバイス上のオークションは、Google を含むどのサーバーからも検知されません。
PerBuyerExperiment
GroupId		 現在の値の範囲は
PerBuyerExperiment
GroupId
で、購入者はコンテキスト データを信頼できるサーバー リクエストと関連付けることができます。		 Protected Audience API をこのように使用することは、API ユーザーがプライバシー サンドボックスの保護を回避しようとしないというプライバシー サンドボックスの必須の証明と矛盾しています。今後、Key-Value サーバーを信頼できる実行環境（TEE）で実行する要件により、この攻撃に対する技術的な保護が提供されます。
同一オリジン ポリシー 同一オリジン ポリシーを緩和して、サブドメインを許可します。 Google はこのリクエストを検討しており、エコシステムからの追加のフィードバックをお待ちしております。
API バージョニング Protected Audience API の変更に関するバージョニングとリリースノートのリクエスト。 Google はこのリクエストを検討しており、エコシステムからの追加のフィードバックをお待ちしております。
マルチ SSP オークション 最上位のオークション シグナルがコンポーネント シグナル auctionSignals との JSON 結合を実行できるようにします。 Google はこのリクエストを検討しており、エコシステムからの追加のフィードバックをお待ちしております。
単価制限 入札に使用される広告コンポーネント数の上限を 20 から 40 に引き上げました。 Google ではこのリクエストを検討しており、この機能が有用である理由について、エコシステムからの追加のフィードバックをお待ちしております。
（前四半期にも報告）
Protected Audience オークションのパフォーマンス		 Protected Audience オークションのラテンシが高いという報告がテスターから寄せられています。 レイテンシに関する質問については、Protected Audience API は一般に、販売者が入札者が使用できる時間とリソースの量を決定できるようにするコントロールを構築し、購入者が利用可能なリソースを最適に使用できるようにするツールを構築するという、既存の標準パラダイムに沿って設計されています。これらの設定とツールは現在一般公開されていますが、購入者と販売者が導入した後に初めてそのメリットを最大限に活用できます。また、Chrome ではオークションの速度を改善するためのさまざまなインフラストラクチャの改善にも取り組んでいます（crrev.com/1190815、crrev.com/1199839、crrev.com/1201837、crrev.com/1198339、crrev.com/1197323）。

このレイテンシ削減の取り組みの両方について、フィードバックをお寄せください。購入者と販売者が役立つと思われる新しいツールと、Chrome エンジニアが調査すべきボトルネックの報告です。
バイサイド フィルタリング インタレスト グループに基づく購入側のフィルタリングをサポート。 Google は、SSP と DSP がこの問題に対処するために設計を変更できるいくつかの方法を提案しています。
  • 一部の処理を DSP の Key/Value サーバーに移動。
  • SSP がコンテキスト シグナルを作成して DSP に提供する。
  • DSP のコンテキスト シグナルをキャッシュに保存する SSP。
パブリッシャーのインタレスト グループの管理 パブリッシャーが作成したインタレスト グループの使用を委任しようとしているパブリッシャーをサポートします。 Google は、このリクエストについて多くの関係者と協議を重ねてきました。パブリッシャーが作成したインタレスト グループの「委任」に関連するこのようなユースケースはすべて、現在対応できると考えています。また、今後、一部のユースケースをよりスムーズに進めるために、追加のサポートを構築する必要があると考えます。
（第 2 四半期にも報告）高信頼実行環境 パブリック クラウド以外の環境での高信頼実行環境（TEE）のサポート。 回答は前四半期と同様です。

Google は、パブリック クラウド ベースのソリューション以外のオプションのサポートを継続的に検討していますが、現時点ではオンプレミス TEE をサポートする予定はありません。この段階では、プライバシー サンドボックスのセキュリティ要件とオンプレミス デプロイメントがもたらす重大な課題を考慮すると、クラウドベースのデプロイメントの拡大と改善（AWS に加えて Google Cloud をサポートするなど）を継続することがエコシステムにとって最も有益であると考えています。ただし、プライバシーとセキュリティの制約を考慮して、このような要件がなぜ必要で実現可能なのかについて、追加のフィードバックをお待ちしております。
Trusted Execution Environment ロードバランサなどの TEE サービング パスのコンポーネントは、すべてのトラフィックをモニタリングし、各リクエストの IP アドレスの情報を取得できます。 現在、入札サービスとオークション、およびオンデバイスの Protected Audience オークションの両方の場合、IP アドレスはリクエスト ヘッダーのメタデータとして信頼できない販売者の広告サービスに渡されます。詳細については、メタデータ転送をご覧ください。長期的には、広告テクノロジーとトラッカー トラフィックを IP プロキシ経由でプロキシ化することを計画しています。これにより、コンポーネントがサービング パス内のすべてのトラフィックを検出できなくなります。
有効期間（TTL） サービスが新しい鍵をリクエストするまでの有効期間（TTL）は設定されますか？それとも、柔軟（または動的）に設定されますか？ TTL は通常静的です。現在、公開鍵の TTL は 8 日で、ローテーションは 7 日ごとに行われます。また、Aggregation Service の場合、秘密鍵の TTL も同じです。入札サービスとオークション サービスの場合、秘密鍵と公開鍵はリクエスト以外のパスで N 時間ごとに取得され、メモリ内にキャッシュに保存されるため、鍵のローテーションとサーバーがこれらの鍵を取得するまでに N 時間以内の遅延しか発生しません。鍵のローテーションと有効期限の間に 1 日のバッファを設けているのは、鍵の生成に失敗した場合でも、サービスが引き続き動作できるようにするためです。停止に対する耐障害性を高めるために TTL の延長を検討しています。鍵が漏洩した場合は、鍵の生成を手動で強制的に実行し、鍵をより早く無効にすることを計画しています。公開鍵はクライアントにキャッシュに保存されます（現在は 24 時間）。これは、コーディネーターが停止した場合でも、サービスが引き続き動作できるようにするためです。
トラフィック シェーピング 入札およびオークション サービスのトラフィック シェーピングのサポート。 購入者は、パブリッシャーのファーストパーティ データまたはコンテキスト データに基づいて、Protected Audience オークションのデマンドを示唆できます。販売者は、販売者の広告サーバーまたは Ad Exchange サーバーで同様の判断を行うこともできます。モデルは、ファーストパーティ データと、Protected Audience オークションの集計レポートでトレーニングできます。販売者は、この情報を使用して、Protected Audience オークションの需要がないときに入札サーバーとオークション サーバーにリクエストを送信しないようにできます。これはトラフィックを調整する効果的な方法であると考えています。
コンポーネント オークション コンポーネント販売者と共有される最上位のオークション シグナル コンポーネント オークションの購入者は、コンポーネント販売者からのシグナルのみを受信します。ヘッダー入札と Protected Audience のオークションを組み合わせたオークションの全体的なシーケンスに関するドキュメントを近日中に公開する予定です。
動画レンダリング Protected Audience とフェンスド フレームを使用した動画レンダリングのサポート。 Protected Audience API は、iframe に依存するメカニズムを使用した動画レンダリングをサポートしています。ただし、フェンスド フレームに対応するソリューションはまだ設計されていません。これが、フェンスド フレームの適用を 2026 年に延期することにした理由の一つです。つまり、パートナーが今フェンス付きフレームの適用を決定した場合、そのパートナーは動画のサポートを失うことになります。
フリークエンシー キャップ （前四半期にも報告）
キャンペーンと広告グループ内のユーザーごとのフリークエンシーの制御。		 回答は以前の報告から変更ありません。

Protected Audience は、オンデバイス オークション、コンテキスト キャンペーン、ブランディング キャンペーンのフリークエンシー キャップもサポートします。共有ストレージとサイト固有の上限を使用して、フリークエンシー キャップの追加の制御を行うこともできます。
広告表示設定 Protected Audience には、広告主のサイトごとにオプトアウトまたはブロックリストに登録する方法や、同じ所有者のすべてのインタレスト グループを除外する方法はありますか？ Protected Audience API やその他のプライバシー サンドボックス機能へのアクセスをブロックする方法はいくつかあります。
入札スクリプトとオークション スクリプトのソース URL の同一オリジン ポリシー スクリプトまたは JSON の読み込み URL を指定するすべてのフィールドが所有者と同一オリジンである必要があるという要件を緩和しました。 現在、このリクエストを検討中です。エコシステムからの追加のフィードバックをお待ちしております。
forDebuggingOnly 3PCD 後に forDebuggingOnly
.reportAdAuctionWin が残っていると、不正使用される可能性があります。		 過去数年間、サードパーティ Cookie のサポート終了後に Protected Audience の機能にギャップが生じるというフィードバックをエコシステムから受けてきました。Google は、プライバシー サンドボックスの目標を損なうことなく、3PCD 後に Protected Audience をサポートするための計画を策定しています。エコシステムで不足している機能について、ご提案やフィードバックをお待ちしております。
複数のインタレスト グループ 同じ入札単価で複数のインタレスト グループを使用する。 これは、基盤となるプライバシー モデルが変更されるため、現在のところ Protected Audience API ではサポートされていません。こちらで追加のディスカッションを歓迎します。
オンデバイス オークション Android 版 Chrome はデバイス上の Protected Audience オークションをサポートしますか？ はい。Android 版 Chrome では、デバイス上のオークションがサポートされます。
（2023 年第 2 四半期に報告）クリック関連データ クリック関連のデータを browserSignals に追加。 Google では引き続きこの機能リクエストを評価しており、この機能が優先されるべき理由について追加のフィードバックをお待ちしております。
高信頼実行環境プロバイダ 異なるクラウド プロバイダの信頼実行環境の機能に大きな違いはありますか？ 大きな違いは確認されていませんが、エコシステムは公開デプロイガイドを参照して、ニーズに最適なソリューションを確認することをおすすめします。

Google Cloud。
AWS。
（前四半期に報告）

インタレスト グループのターゲット除外のサポート		 インタレスト グループの除外ターゲティングをサポートする API: ユーザーがインタレスト グループに属していない場合にのみ広告を表示します。 YouTube では、この機能の実装を検討しており、リクエストについて協議しています。
コンテンツの違反 ユーザーが Protected Audience API によって配信された不適切な広告を報告できる機能を、フェンスド フレームでサポートします。 Google は、既存の フェンスド フレーム広告レポート メカニズムが、ユーザー作成の「不適切な広告」レポート フローを希望する広告テクノロジーにとって優れたオプションであると考えています。これにより、現在の業界標準と本質的に変わらない方法で、不正な広告を報告できるようになります。サードパーティ Cookie の削除後、フェンスド フレーム レンダリングが広く普及するまでの間など、ギャップが残っている場合は、追加の機能リクエストをお寄せください。
Private Aggregation API レポート ユーザーがそのインタレスト グループに費やした時間を計算するにはどうすればよいですか？ Chrome M116 以降では、pull/639 で定義されている最新情報を使用できるようになります。
k-匿名性サーバー K-匿名性サーバーに関する詳細 K-匿名性サーバーに関する詳細情報もご参照ください。フィードバックもお待ちしております。
動的広告の URL k-匿名性を維持しながら、事前宣言なしのクリエイティブ URL をサポート。 Google では現在、この機能リクエストについて検討中です。この機能の優先度を上げる理由について、追加のフィードバックをお寄せください。
k-匿名性の要件 興味 / 関心グループの更新に関する k-匿名性の要件は再導入されますか？ こちらの GitHub 投稿に記載されているポリシーに変更が生じることはありません。その投稿で発表したとおり、Protected Audience のインタレスト グループの更新に対する k-匿名性の要件を削除することにしました。これは、API の全体的なプライバシー保護に大きな影響を与えるものではありません。また、関連する技術がさらに開発、デプロイ、採用された後、より直接的な保護（IP アドレスのプライバシーや信頼できる更新サーバーなど）を検討する予定です。
入札およびオークション サービスのベータ版テスト 入札およびオークション サービスのベータ版テストはいつ開始されますか？ タイムラインとロードマップに記載されているとおり、入札とオークション サービスの第 1 フェーズのテストは 2023 年 11 月に開始されます。
ロードブロッキング 広告ネットワークのクリエイティブ調整のサポートをリクエストする（SSP と DSP が同じ会社またはプロパティ内にある）。 このユースケースに関するフィードバックありがとうございます。Google は、より多くの広告テクノロジーがこの機能のサポートに関心を持っているかどうかを把握したいと考えています。フィードバックをお待ちしております。
ネイティブ広告 ネイティブ広告のフェンス付きフレームのサポート。 Google では、このユースケースのサポートを検討しており、考えられる回避策と解決策について議論しています。
k-匿名性 k-anon の基準を満たすインタレスト グループ広告を最大化するにはどうすればよいですか？ このトピックに関する戦術的なガイダンスを共有しています。
POST のサポート POST リクエストを介してオークション データを送信する機能のサポート。 Google では現在、この機能リクエストを評価しています。この機能の優先度を上げる理由について、GitHub の問題の送信を追加で歓迎します。
レポートの粒度 複数のピースで構成される広告のフェンスド フレーム広告レポートのレポートの粒度はどれくらいですか？ 現在の設計では、ユーザーのプライバシーを侵害する可能性があるため、商品 ID や位置情報を取得できません。呼び出せるのは reserved.top_navigation のみです。これは、広告コンポーネントのフェンスド フレームでユーザーがアクティベーション（クリックなど）を行った場合に送信され、トップレベル ナビゲーションにつながります。
広告オークション コンポーネント オークションに参加している SSP が、自身で別のコンポーネント オークションをトリガーすることはできますか？ componentSeller に componentAuctions を含めることもできません。
複数販売者のオークションには、次の 2 つのレベルのみがあります。
1. コンポーネントは並列でオークションを行います。
2. トップレベル オークション（各 componentAuction の落札広告が競合するオークション）。
入札およびオークション サービスの提供状況 Chrome によるテストフェーズ中に入札とオークションを利用できますか？ Chrome によるテストフェーズ中は、入札サーバーとオークション サーバーは使用できません。
入札シグナル ブラウザによる入札シグナルのリクエストと削除を許可します。 Google ではこのリクエストについて検討しており、優先度を上げる必要がある理由について追加のフィードバックをお待ちしております。
generateBid() updateURL を介してインタレスト グループの userBiddingSignals を更新できる。 YouTube ではこの提案を検討しており、追加のフィードバックや議論をお待ちしております。
パブリッシャーの広告枠の種類 Protected Audience と TOPICS のテストでは、どのようなタイプのパブリッシャー広告枠がサポートされますか？ Protected Audience と Topics はどちらも、使用できる広告枠の種類に関して本質的に制限はありません。
サーバー間統合 Protected Audience では SSP と DSP の直接統合が必要ですか？ DSP が、処理された情報をオンデバイス入札機能に渡すために、独自のサーバーでコンテキスト シグナルを処理する必要がない場合は、SSP と DSP の直接統合は必要ありません。
B&A の bid_currency フィールド 入札およびオークション サービスの bid_currency フィールドのサポート。 B&A は bid_currency をまだサポートしていませんが、2024 年 1 月末までにサポートする予定です。こちらのタイムラインを参照してください。
perBuyerSignals perBuyerSignals のサイズに制限はありますか？ 購入者ごとのシグナルの数に制限はありませんが、送信するデータが多すぎると、ブラウザのパフォーマンスに悪影響が及ぶ可能性があります。
クロスサイトのユースケース Protected Audience API のインタレスト グループを複数のウェブサイトで使用できますか？ Protected Audience は、turtledove/issues/282 で説明されているように、このようなユースケースを想定していません。
インタレスト グループの HTTP リクエスト HTTP ヘッダーに興味 / 関心グループの blob を含めます。 Google はこのリクエストを検討しており、このリクエストに関するフィードバックをお待ちしております。
広告品質コントロール クロスサイト情報に関連する広告品質管理の喪失。 Google はこのフィードバックを検討しており、追加のフィードバックをお待ちしております。
Chrome DevTools 送信される Protected Audience ネットワーク リクエストは、Chrome デベロッパー ツールの [ネットワーク] タブに表示されます。 Google は、ネットワーク タブでこの機能を有効にできるよう取り組んでおります。この機能の優先度を上げる理由について、追加のフィードバックをお待ちしております。
Trusted Execution Environment プライバシーに影響する指標（およびその程度）の詳細が、信頼実行環境のモニタリングの説明に追加されるのはいつですか？ この情報を説明に追加する作業を進めています。更新された説明は 2023 年 11 月までに公開されます。
directFrom
SellerSignals		 directFrom
SellerSignals がウェブバンドルとしてパッケージ化されないのはなぜですか？		 今回の決定の根拠をこちらで公開しています。
インプレッションの委任 インタレスト グループの選択結果が別のターゲティング アクションとなるインプレッション委任を行う有効な方法はありますか？ ネストされた複数のオークションは、次の 2 つの理由から Google のプライバシー目標と整合しません。まず、オークションの落札者がフェンスド フレーム内にレンダリングされる場合、Protected Audience のプライバシー目標には、コンテキストを認識せずにクリエイティブをレンダリングする結果が含まれます。つまり、周囲のページの URL やファースト パーティ Cookie がプライバシー侵害となります。そのような環境では、ネストされたオークションは実行できません。2 つ目は、Protected Audience モデルでは、各オークションの落札者は、追加の 1 つのサイトのデータに基づく必要があるということです。ネストされたオークションは、これを組み合わせる方法であり、複数サイト プロファイルに基づいて広告を選択できるようになります。
保存データの条件 Key-Value サービスの信頼モデルにおける保存データの条件について詳しく説明します。 Key Value Service のデータは、リードスルー キャッシュではなく、メモリに読み込まれ、そこから提供されます。
購入者データシグナル DSP から受信する buyer_data シグナルのサイズに上限はありますか？ 現在のところ、DSP から受信する buyer_data シグナルにブラウザが課す上限はありません。

デジタル広告の測定

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

フィードバック テーマ 概要 Chrome の対応
クロスデバイス Attribution Reporting API のクロスデバイス サポートを計画する。 クロスデバイスは、3PC に加えて新しいプライバシー上の課題をもたらします。また、ユーザーが使用するデバイスやプラットフォームの範囲が広いため、技術的な配信の課題も追加されます。潜在的な解決策を検討していますが、現在アトリビューション レポートでサポートされている重要なユースケースに重点を置いており、サードパーティ Cookie の廃止前にクロスデバイス サポートを導入する予定はありません。
（前四半期にも報告）
トリガー データサイズ		 トリガーデータのサイズが 3 ビットに制限されているのはなぜですか？ サイズは 3 ビット、8 個の個別の値に制限されており、ユーザーに関するクロスサイトおよびクロスコンテキストの情報の量が制限されています。イベントレベル レポートの現在のパラメータ設定が十分かどうかについて、エコシステムのプレーヤーからフィードバックを送信していただければ幸いです。
コンバージョン プロセス コンバージョンに使用された複数のドメインをレポートします。 このユースケースは、複数の宛先の追加により可能になりました。追加のフィードバックをお待ちしております。
同じドメインで異なる国をサポートする アトリビューション レポートは、同じドメインで複数の国 TLD を持つウェブサイトで機能しますか？ この問題は、質問したステークホルダーと話し合い、解決しました。広告テクノロジーで複数の国別 TLD を使用する必要がある場合は、国別 TLD ごとに 1 つずつ、複数の登録を行う必要があります。
Protected Audience とアトリビューションのレポート 広告テクノロジーは、Protected Audience オークションのビュースルー コンバージョンとアトリビューション レポートのクリックスルー コンバージョンの両方にアクセスできますか？ はい。プライバシー サンドボックスは、Protected Audience 内の VTC と CTC の両方をサポートする必要があります。
集計可能レポートの遅延 集計可能レポートの遅延をさらに短縮。 この点について最近いただいたフィードバックは、こちらで共有しています。エコシステムからのフィードバックをお待ちしております。
集計可能レポートの遅延 サーバー メディエーションを導入して遅延を軽減。 YouTube ではこの提案を検討しており、追加のフィードバックをお待ちしております 。
イベントレベル レポートの遅延 イベントレベル レポートの遅延を短縮する。 柔軟なイベントレベルの設定で説明されている完全な柔軟なイベントレベルのプロポーザルでは、ノイズのトレードオフにより、イベントレベルのレポートの遅延を 1 時間まで短縮できます。
ソースごとのソース レポートの送信元 ソース レポート サイトあたりのソース レポート オリジン数の上限により、広告テクノロジーが 1 つのパブリッシャー オリジンに異なるレポート オリジンのソースを登録できなくなります。 この問題は、問題を提起したステークホルダーと話し合われ、リダイレクトを含む他の潜在的なソリューションを試す前に、ソース レポート サイトごとに 1 つのレポート送信元を使用するという潜在的なソリューションがテストされています。

この上限について、エコシステムからの追加のフィードバックもお待ちしております。
問題の報告 Attribution Reporting API のエラーや問題を Chrome に報告するにはどうすればよいですか？ 現在、広告テクノロジーが直面している Attribution Reporting API のエラーは、GitHub で問題として報告することをおすすめします。Chrome 関連の問題が発生している場合は、Chromium のバグを作成することをおすすめします。問題を報告する方法と場所については、フィードバックを共有するをご覧ください。
重複除去 異なるパイプラインとデバイス間でコンバージョンの重複を排除するにはどうすればよいですか？ デバイスと測定パイプライン全体での重複除去は、広告テクノロジーが現在 3PC で直面している既知の課題です。Attribution Reporting API を使用すると、広告テクノロジーは特定のコンバージョンを登録するタイミングを決定し、特定のメタデータを追加して、コンバージョンのトラッキングに使用した測定パイプライン（集計キーの一部）を示すことができます。この情報は、他の測定パイプラインと比較できます。

この件について、エコシステムからご意見をお寄せください。
重複除去と優先度 重複除去の前に優先度を高くするようリクエストします。 YouTube ではこのリクエストを検討しており、フィードバックをお待ちしております。
不正対策 悪意のあるユーザーがイベント単位のデータを改ざんするリスク。 イベントレベルのレポートがサポートされないのはなぜですか？で説明されている理由により、イベントレベルのレポートではレポートの検証が機能しません。
コンバージョンの種類 アトリビューション レポートでビュースルーとナビゲーションを区別するにはどうすればよいですか？ 次の組み込みフィルタ オプションがあります。source_type詳しくは、こちらをご覧ください。

集計サービス

フィードバック テーマ 概要 Chrome の対応
予算の回復 一部の広告テクノロジーでは、レポートの失敗、エラー、削除が発生した場合にレポートを再処理する機能がリクエストされています。 チームは、プライバシーを保護しながらこの問題に対処する方法を検討しています。
サイトの登録 複数の広告テクノロジーから、地域や広告主別にデータを分割するなどのユースケースで、同じアカウントで複数のオリジンを処理するためのサポートがリクエストされています。クライアント API の登録がオリジンベースではなくサイトベースになったため、この動作は広告テクノロジーでも想定されています。オリジンからサイト登録に移行すると、クライアント登録プロセスとの整合性が確保され、広告テクノロジーのオンボーディング プロセスが効率化されます。 アグリゲーション サービスのオリジン登録からサイト登録への移行はまもなく開始されます。エコシステムからのフィードバックをお待ちしております。
リリースとサポート終了計画 公開された集計サービスの機能とパッチのリリースとサポート終了のスケジュール。この計画の目標は、広告テクノロジーに Google のリリース ポリシーを公開し、今後のリリースと非推奨化に備え、安定性と安全性の高いバージョンのサービスが確実に実行されるようにすることです。 先日、集計サービスのリリースと非推奨化の計画に関する提案を公開しました。追加のフィードバックをお待ちしております。
コーディネーター 集約サービスでコーディネーターが停止した場合はどうなりますか？ システムが正常に機能するには、両方のコーディネーターが完全に使用可能である必要があります。短時間の停止は、クライアント ライブラリの再試行で対応できます。2 つのコーディネーターのいずれかが長時間使用できなくなると、集計ジョブは失敗します。

プライバシーの予算がまだ消費されていない場合は、ジョブを再実行できます。サービス障害により、広告テクノロジー ストレージに概要レポートが書き込まれずに予算が消費された場合は、現在、デバッグ レポートを使用してローカル テストツールで結果を取得することをおすすめします。

また、広告テクノロジーがジョブを再実行できるように、エラーが発生した場合に予算を回復できる機能の開発にも取り組んでいます。

Private Aggregation API

フィードバック テーマ 概要 Chrome の対応
Blob の URL 共有ストレージで Blob URL をサポートするようリクエスト。 Chrome M116 で Blob URL のサポートが追加されました。

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

ユーザー エージェント文字列の削減とユーザー エージェント クライアントのヒント

フィードバック テーマ 概要 Chrome の対応
JavaScript API User-Agent Client Hints JavaScript API の提供状況。 この機能は、凍結された UA と削減された UA でデフォルトで利用できる範囲を超えて高エントロピー データに積極的にアクセスするパートナー向けのコア ソリューションであるため、削除する予定はありません。
デバイスとフォーム ファクタの情報 ウェブサイトが、ウェブサイトにアクセスするデバイスがサポートできる入力、出力、その他の情報を認識する機能。 エコシステムからのフィードバックに基づき、このリクエストのサポートを追加しました。

IP 保護（旧 Gnatcatcher）

フィードバック テーマ 概要 Chrome の対応
対象となるサードパーティ トラフィック 説明で「対象となるサードパーティ トラフィック」とは何を指していますか？ Google はこの質問の重要性を認識しており、対象となるサードパーティ トラフィックと対象外となるサードパーティ トラフィックを特定するために積極的に取り組んでいます。この件についてご意見をお寄せください。
ネットワーク トラフィック監査 企業がネットワークのネットワーク トラフィック監査を実施できるようにする。 影響を受けるのは、ファーストパーティ サイトに埋め込まれたサードパーティ トラフィックのみであるため、フィルタリングが必要なトラフィックの量を抑えることができます。また、IP 保護の使用をユーザーが選択できるようにする予定です。企業が管理する Chrome では、IP 保護を無効にするエンタープライズ ポリシーが用意されます。最後に、IP 保護を無効にするためにネットワーク事業者に提供されるコントロール（ある場合）を検討しています。このトピックに関するフィードバックをお待ちしております。
アクセス制御 IP 保護は、アクセス制御に IP アドレスを使用するウェブサービスに影響する可能性があります。 Google は、不正行為防止のユースケースの重要性と、それらのユースケースに及ぼす可能性のある影響を認識しています。Google は、通常は IP アドレスに依存していた不正行為防止のユースケースをより適切にサポートする方法を検討しており、エコシステムからのフィードバックをお待ちしています。
2 ホップ プロキシ間の通信 プロキシ間で情報が漏洩しないようにする方法。 現在、プロキシ インタラクションの設計を進めています。Google は、ビジネス、プロセス、技術的な手段によるこのような情報共有の可能性を最小限に抑えることを目指しています。
Google 以外の認証 Google 以外の認証のサポート。 アカウント認証の詳細については、今後公開する予定です。初期的な考慮事項についてはすでにお知らせしています。
トラッカーの分類 IP Protection は、トラッカーとそのバリエーションをどのように判断しますか？ Google はこの質問の重要性を認識しており、対象となるサードパーティ トラフィックと対象外となるサードパーティ トラフィックを特定するために積極的に取り組んでいます。この件についてご意見をお寄せください。
アナリティクス IP 保護は、分析サービスの精度に影響する可能性があります。 Google は、IP 保護の影響をさらに把握し、エコシステムからのフィードバックや例を歓迎しています。
プロキシ ユーザーがプロキシを使用している場合、またはプロキシを手動で定義している場合、この場合の IP マスクはどのように機能しますか？ Google は、IP 保護が他のプロキシに与える影響を把握しようとしています。現時点でお伝えできる情報はございません。このトピックに関するフィードバックをお待ちしております。
プレミアム サービス IP 保護機能は有料機能ですか？ IP 保護は、ブラウザのコア機能の一部として Chrome ユーザーが利用できます。有料機能ではありません。
プロキシ サーバー ユーザー セッション中に同じプロキシ サーバーが使用されますか？ HTTP/S 接続は 1 組のプロキシを使用し、単一のマスクされた IP アドレスを送信元に提示します。それ以外に、異なる HTTP/S 接続で同じサーバーを使わなければならないという厳しい制約はありません。
プラットフォーム サポート IP Protection はどのプラットフォームでサポートされますか？ IP 保護は、まず Android 版 Chrome とパソコン版 Chrome で利用可能になります。保護を他のプラットフォームに拡大する方法については、引き続き検討しています。
オプトアウト ユーザーは IP 保護を無効にできますか？ IP 保護を使用するかどうかは、ユーザーが選択できるようにする予定です。
匿名化 IP 保護で匿名化されるリクエストにはどのようなものがありますか？ 対象となるサードパーティ ドメインへの HTTP/S リクエストと DNS リクエストは、プライバシー プロキシを介して匿名化されます。どのドメインが含まれるかを決定する方法については、今後の説明記事で詳しく説明します。残りのトラフィック（残りの DNS リクエストやその他の HTTP/S トラフィックなど）は影響を受けません。
データの可視化 ネットワーク アドレスには、IP Protection の最初のホップでアクセスされる場合があります。 2 ホップ プロキシ モデルでは、最初のホップ（Google によって制御）は送信元クライアント IP と 2 番目のホップへの接続リクエストのみを認識し、2 番目のホップ（外部 CDN によって制御）は最初のホップのタプル（プロキシ IP + ポート）と宛先 IP のみを認識します。送信元からのレスポンスの場合、2 番目のホップは、リクエストに関連付けられた最初のホップ プロキシとポートにレスポンスを転送できます。元のクライアント IP について何も学習する必要はありません（最初のホップは、宛先 IP について何も学習せずに、クライアントにレスポンスを返します）。これにより、最初のホップはクライアント IP と 2 番目のホップのみを学習し、2 番目のホップは宛先 IP のみを学習します。
WebView 今後、Android WebView で IP 保護を利用できるようになるのでしょうか？ 現時点では共有する予定はありませんが、この保護をできるだけ広範囲に提供することが Google のビジョンです。

バウンス トラッキング対策

フィードバック テーマ 概要 Chrome の対応
インタラクション トラッキング ユーザー インタラクションはどのようにトラッキングされますか？ バウンス トラッキング対策では、次の 2 種類のユーザー操作がトラッキングされます。

  • html 仕様で定義されているユーザー操作。基本的には、クリック、キー操作、タッチスクリーンのタップなどです。
  • webauth アサーションの成功。ユーザーがセキュリティ キーをタップする場合や、認証方法としてパスキーを使用する場合などです。

これらのインタラクションは、発生したページの最上位サイトに関連付けられます。たとえば、ユーザーが埋め込まれた iframe をクリックした場合、そのインタラクションはその埋め込まれたサイトではなく、トップレベル サイトに関連付けられます。

インタラクションは、スキームレスの etld+1 とインタラクションの時間を含むデータベースに保存されます。

インタラクションにより、関連付けられたドメインは、バウンス トラッキング緩和状態の削除から 45 日間保護されます。
許可リストに登録済みの例外 ドメインを除外できますか？ Google ではこのリクエストを検討しており、エコシステムからのフィードバックをお待ちしております。

プライバシー バジェット

今四半期にフィードバックはありませんでした。

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

フィードバック テーマ 概要 Chrome の対応
一元化されたアプローチ 関連ウェブサイト セットの管理にリポジトリの一元化アプローチを使用することに対する懸念。 送信内容の説明責任を果たすため、一般公開され、簡単にアクセスできるリポジトリが RWS の設計の鍵となります。サードパーティ Cookie 機能は最終的に Storage Access API または rSAFor API を使用して提供され、RWS メンバーシップにより自動的にアクセス権が付与されます（Storage Access API のプロンプトによるアクセス権付与とは異なります）。Google は、RWS 送信プロセスのようなアプローチが、サードパーティ Cookie へのアクセス権を自動的に付与する際の適切な要件であると考えています。
JSON ファイルの名前変更 API 名を変更した場合、ホストされている JSON ファイル名を変更する必要がありますか？ はい。送信ガイドラインが変更され、プライマリ ドメインは /.well-known/related-website-set.json で JSON ファイルを提供する必要があります。

RWS リスト内の既存のセットは変更する必要はありませんが、既存のセットに変更が送信された場合は、JSON ファイルを変更する必要があります。
（前四半期にも報告）ドメインの上限 関連付けられたドメイン数の増加をリクエストする 8 月 31 日の投稿で発表したとおり、エコシステムからのフィードバックに基づき、関連付けられたドメインの上限を 5 ドメインに引き上げました。関連付けられるドメインの上限を 5 つのドメイン（+ 1 つのプライマリ ドメイン）に引き上げることにしました。これは、他の主要なブラウザで提供されている最も類似した実装に最も近いものです。
サードパーティ Cookie 関連ウェブサイト セットは、サードパーティ Cookie を無効にした場合にのみ機能しますか？ 関連するウェブサイト セットは、ユーザーがサードパーティ Cookie をブロックしていなくても機能しますが、関連する Cookie は関連するウェブサイト セットと Storage Access API を使用せずに利用できるため、目に見える効果はありません。
正当な編集 関連ウェブサイト セット リポジトリでは、所有者以外のユーザーがセットを変更できないようにするにはどうすればよいですか？ 送信ガイドに従い、誰でも GitHub で PR を送信して first_party_sets.JSON ファイルを編集できます。ただし、PR が承認された場合（技術的な検証に合格した場合など）、Google によって週に 1 回（火曜日の午後 12 時（東部時間））手動で正規の FPS リストにバッチで統合されます。

不正な行為者が所有していないセットを変更しようとした場合、.well-known ファイルを変更できないため検証が失敗するため、問題にはなりません。
ドメインの不正使用 ドメインの不正使用により、関連するドメインデータが不正な第三者に公開される可能性があります。 Protected Audience の GitHub の問題で説明されているように、これはできません。

Fenced Frames API

フィードバック テーマ 概要 Chrome の対応
コンテンツの違反 ユーザーが不審な広告を報告できるようにする。 フェンスド フレームによって、不審な広告の報告が防止されることはありません。ユーザーは引き続き広告を操作し、通常どおりに広告テクノロジーに疑わしい広告を報告できます。
周辺のサイトとの連携 周囲または最上位のウェブサイトとのインタラクションを許可します。 Google は、このリクエストが必要な理由を理解し、エコシステムからの追加のフィードバックをお待ちしております。
ネイティブ広告 ネイティブ広告のフェンス付きフレームのサポート。 Google では、このユースケースのサポートを検討しており、考えられる回避策と解決策について協議しています。

Shared Storage API

フィードバック テーマ 概要 Chrome の対応
クロスドメイン ローカル ストレージのドメイン間通信を許可します。 このユースケースは現在、共有ストレージのプライバシー保護出力ゲートに対応していません。ただし、パーティショニングされていないストレージの提案を進めるにあたり、追加のコンテキストをお寄せください。
Blob の URL 共有ストレージで Blob URL をサポートするようリクエスト。 Chrome M116 で Blob URL のサポートが追加されました。

CHIPs

今四半期にフィードバックはありませんでした。

FedCM

フィードバック テーマ 概要 Chrome の対応
サードパーティ Cookie 現在、ユーザーが Chrome の設定で [サードパーティ Cookie をブロックする] を有効にした場合、FedCM は無効になりますか？ はい。FedCM は現在無効になっています。テストの場合は、chrome://flags/#fedcm-
without-third-party-cookies も有効にすることをおすすめします。

今後、サードパーティ Cookie を使用しない FedCM をサポートする予定です。

スパムや不正行為に対処する

Private State Tokens API（および他の API）

フィードバック テーマ 概要 Chrome の対応
トークンの有効期限 Google Chrome をアンインストールすると、トークンは失われますか？それともキャッシュに保存されますか？ ユーザーが Google Chrome をアンインストールすると、トークンは失われます。
トークン情報 発行元は、プライベート ステート トークン内の発行情報を非公開に保つにはどうすればよいですか？ 情報は常にトークン内に非公開に保たれ、鍵を持たない外部関係者が暗号を解除することはできません。
デモでエラーが発生する プライベート ステート トークンのデモを実行しようとするとエラーが発生する。 デモを更新しました。現在は正常に動作しているはずです。