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

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

CMA への取り組みの一環として、Google はプライバシー サンドボックスの提案の関係者エンゲージメント プロセスに関する四半期レポートを公表することに合意しています（コミットメントの第 12 項および第 17（c）（ii）項を参照）。プライバシー サンドボックスのフィードバック概要レポートは、フィードバックの概要に記載されているさまざまなソースから Chrome に寄せられたフィードバックを集約して生成されます。たとえば、GitHub の問題、privacysandbox.com で入手できるフィードバック フォーム、業界関係者とのミーティング、ウェブ標準フォーラムなどがありますが、これらに限定されません。Chrome ではエコシステムからのフィードバックを歓迎し、学んだことを設計上の決定に取り入れる方法を積極的に検討しています。

フィードバック テーマは、API ごとの普及率によってランク付けされます。特定のテーマについて Chrome チームが受け取ったフィードバックの量を集計し、量が大きい順に整理して表示しています。一般的なフィードバックのテーマは、公開ミーティング（W3C、PatCG、IETF）でのディスカッションのトピック、直接フィードバック、GitHub、Google の社内チームや公開フォームを通じて得られたよくある質問を確認することで特定されました。

具体的には、ウェブ標準団体の会議の議事録を確認し、直接のフィードバックとして、Google が 1 対 1 で行った関係者会議の記録、個々のエンジニアが受け取ったメール、API のメーリング リスト、公開フィードバック フォームを検討しました。次に Google は、こうしたさまざまなアウトリーチ活動に関与したチーム間で調整を行い、各 API に関連して出現したテーマの相対的な普及率を判断しました。

フィードバックに対する Chrome の回答に関する説明は、公開されているよくある質問、関係者から提起された問題への実際の回答、この公開レポート演習のために特筆すべき立場を決定したことから作成されました。現在の開発とテストの焦点を反映して、特に Topics、Protected Audience、Attribution Reporting API に関する質問とフィードバックが寄せられました。

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

頭字語の用語集

チップ
独立したパーティション状態を持つ Cookie
DSP
デマンドサイド プラットフォーム
FedCM
Federated Credential Management
FPS
ファーストパーティ セット
IAB
Interactive Advertising Bureau
。
IDP
ID プロバイダ
IETF
インターネット技術特別調査委員会
IP
インターネット プロトコル アドレス
openRTB
リアルタイム ビッダー
OT
オリジン トライアル
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 と同様にクライアントと統合する必要があります。Cookie など、多くの API には HTTP ヘッダー インターフェースがあります。広告業界のフレームワークである Prebid は、クライアントサイドで API との統合を構築する様子を見てきました。他の組織でも同様の方法があります。
クライアントサイドのソリューション エンジニアが 2012 年のプライバシー サンドボックスのスケーラビリティに懸念を示しているにもかかわらず、Google がプライバシー サンドボックス向けにクライアントサイド ソリューションを採用したのはなぜですか？ 研究分野としてのプライバシー強化技術（PET）は、2012 年以降、商業的に成り立つアプリケーションへと急速に進化しています。プライバシー サンドボックスの中心となるのは、10 年以上前は実現不可能だった PET の組み合わせです。さらに、パーソナル コンピューティング能力も高まり、ブラウザに対する消費者の期待や、規制によるプライバシーへの期待も高まっています。
ML Google では、機械学習を目的としたプライバシー サンドボックスの使用をどのように計画していますか？ 現在、広告テクノロジー エコシステムの大部分は ML を使用しており、Google ではその変化は期待していません。プライバシー サンドボックスは、アドテック企業やその他の誰かが機械学習の使用を継続するのを妨げるものではありません。また、プライバシー サンドボックスの API を統合している企業に機械学習の使用を義務付けることも求められません。機械学習の有無にかかわらず、企業が顧客のニーズに応える方法でプロダクトやサービスを構築し続けると予想するのが合理的です。プライバシー サンドボックス インテグレータが構築する ML は、インテグレータに知られるために隠されることはない。
データの確認 企業は、プライバシー サンドボックスを使用して取得したデータが正確であることと、Google が Media Ratings Council（MRC）などの機関による審査を希望していることをどう検証できますか？ プライバシー サンドボックスの API は、Chrome の基盤となっているオープンソース プラットフォーム内に構築されています。信頼できる実行環境で実行することを想定した API の部分はオープンソースで、監査可能です。MRC を含め、誰でもコードを検査できます。
（前の四半期もレポート）本番環境サポート Chrome では、エコシステムに影響するプライバシー サンドボックスの技術的な問題とエスカレーションに対応するために、どのようなプロセスが導入されていますか？ Google は、広告テクノロジーが技術的な問題を報告し、問題の解決に必要なエスカレーションを可能にするさまざまなチャネルを提供しています。さらに Chrome では、エコシステムの健全性に影響する技術的な問題とエスカレーションを解決するためのプロセスをさらに構築し、拡大していく予定です。Chrome ではこの取り組みに必要なリソースの確保に 尽力しています
フィードバックとエスカレーションに関する公開フォーラムと非公開フォーラムについて詳しくは、デベロッパー向けの投稿をご覧ください。
Chrome で利用できるテストモード Chrome を利用したテストモードのタイムラインと正確な実装に関する詳細をご確認ください。 テストモードに関するブログ投稿を公開しており、まもなく詳細をお知らせする予定です。
テストモードのラベルのサイズに関するご提案を募集しています。
他の業界標準との統合 プライバシー サンドボックスの API は、TCF v2.* と同意モードのいずれかまたは両方に接続しますか？ プライバシー サンドボックス API を TCF v2 または同意モードに直接統合する予定はありません。ただし、企業や業界団体は、自社のプロダクトやフレームワークをプライバシー サンドボックス API と連携させるよう調整することができます。たとえば、TCF などのフレームワークでは、各参加者は、受信した TCF シグナルと関連する TCF ポリシーに基づいて、独自のコンプライアンスのアプローチを決定する必要があります。Google は、プライバシー サンドボックスの構成要素が提供するさまざまな機能を、いつ、どのように使用するかを企業が決定することが期待されています。

登録と証明書

フィードバック テーマ まとめ Chrome レスポンス
制限 登録プロセスにより、Google はエコシステム内のどの会社にプライバシー サンドボックス API の使用を許可するかを決定できます。 登録と認証のプロセスは、基本的にエンティティの検証を伴い（たとえば、エンティティが DUN 番号を持っている、プライバシー ポリシーへのリンクを提供するなど）、API を呼び出すための公開証明書を要件にします。登録要件を正常に満たすことができるエンティティが検証されます。DUN を取得していない企業の場合は、Dun & Bradstreet に無料で迅速な取得プロセスを提供しています。目的は、前述の方法で API のプライバシー保護を強化するとともに、プライバシー サンドボックス API に透明性のレイヤを追加することで、関係者が誰がどの API を使用して、どのような証明書を作成しているかをより詳しく把握できるようにすることです。Google はこの問題について、さらなる業界フィードバックを受け付けています。フィードバックは、すでにこのプロセスの策定に使用されています。
再登録のオーバーヘッド 構成証明ファイルは 12 か月ごとに有効期限が切れ、ウェブサイトの再登録が必要です。 エコシステムからのフィードバックに基づき、アプローチを修正いたしました。したがって、ファイルは 12 か月または任意の設定された期間が経過すると期限切れになりません。登録に関するデベロッパー ガイドを更新し、コンテキストを追加しました。
構成証明ファイル 証明書ファイルの使用方法 関連性と測定に関する API を呼び出す企業はすべて、この適用期限までに、API の呼び出しを続ける予定がある限り、証明書ファイルをサイトにアップロードして公開するために保持することが義務付けられます。

ウェブサイトでは、プライバシー サンドボックスから 1 時間に約 1 件のリクエストが想定されますが、他の潜在的なエンティティでもクエリが発生する場合があります。これは、登録システム独自のメカニズムを介して行われ、登録済みのエンティティのサーバーにクエリが行われ、構成証明ファイルが有効であることを確認します。

証明書は透明性レポートに記載され、一般に公開されます。Google は、エコシステムの他の部分や関連する規制機関と同様に、企業が自社の証明書に従って行動することを期待しています。
登録 登録はサイトごとですか、それともオリジンごとですか。 登録はサイト単位で行われます。

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

トピック

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

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

Google は今後も、エコシステムに対する API の理解をさらに支援していきます。ステークホルダーからのご意見をお待ちしています。当面の間、Topics API の詳細を知りたい関係者には、Chrome デベロッパー ガイドのドキュメントをよくお読みください。
通知 ウェブサイトで Topics が確認されたときにユーザーに通知する通知。 このフィードバックには GitHub で対処しました。Topics コントロールについて詳しくは、Chrome ヘルプセンターをご覧ください。
ML ML を使用してユーザーの Topics を推測する方法 この件については現在調査しており、ぜひフィードバックをお寄せください。
さまざまなタイプの関係者にとっての有用性 小規模な広告テクノロジー企業では、ブラウザによる Topics の計算方法が原因で、Topics を監視できない可能性があります。 ユーザーが過去 3 週間以内に対象のトピックに関するページにアクセスしたと確認された広告テクノロジーのみが、トピックを受け取ります。広告テクノロジーがトピックに関するサイトの該当ユーザーの過去 3 週間に API を呼び出していない場合、戻り値は空になります。

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

Topics の拡張が進むにつれて、XHR のサポートは OT 機能が有効になっているユーザーにのみ含まれ、個々の OT テストグループの統合時に完全にサポート終了となりました。

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

最近のブログ投稿で示したように、分類は時間の経過とともに進化し、最終的に分類のガバナンスは、業界全体の関係者を代表する外部団体に移行されることが想定されています。topics-announce グループでも、拡大計画を公開しています。
嫌がらせ行為 リダイレクト チェーンを介した潜在的な攻撃。 Google ではこの問題について検討しており、追加のフィードバックをお待ちしています。
パブリッシャーの広告枠タイプ Protected Audience と Topics のテストでは、どのような種類のパブリッシャー広告枠がサポートされますか？ Protected Audience も Topics も、使用できる広告枠の種類に関する制限はありません。
立ち上げ期間 新しい分類が 100% になるまでの立ち上げ期間はおすすめしません。 エコシステムからのこちらのフィードバック リクエストと、PATCG 会議での議論を踏まえ、新しい分類法のロールアウトの計画を発表しました。

Protected Audience API（旧 FLEDGE）

フィードバック テーマ まとめ Chrome レスポンス
トップレベル オークション 最上位の Protected Audience API オークションを Google アド マネージャーに管理させることなく、Google のパブリッシャー広告サーバーを使用できる。 Google アド マネージャーが提供するレスポンス:
Protected Audience API に関する Google アド マネージャーの計画では、次の理由から、トップレベルの Protected Audience オークションの管理なしで、Google のパブリッシャー広告サーバーはサポートされていません。

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

予測とペースは、パブリッシャーが広告サーバーに期待する主要な機能です。正確な予測を行わなければ、パブリッシャーは広告枠を過剰に売り込み、ビジネスの評判を失う可能性があります。広告主との予約契約を履行できなくなると、パブリッシャーと広告主の直接的な関係が損なわれ、パブリッシャーのビジネスに多大な影響を与える可能性があるため、ペースも重要です。

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

Google アド マネージャーによる回答:
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 サーバーに移動する。
  • コンテキスト シグナルを作成して DSP に提供する SSP。
  • DSP のコンテキスト シグナルをキャッシュする SSP。
パブリッシャーのインタレスト グループの管理 ニュース メディアが作成したインタレスト グループの使用を委任するパブリッシャー向けのサポート。 Google は、このリクエストについて多くの関係者と協議を重ねてきました。Google は、パブリッシャーが作成したインタレスト グループを「委任」することに関連するすべてのユースケースに対応可能と考えており、将来的には一部のユースケースがよりスムーズに進行できるように、追加のサポートを構築する必要があると考えています。
（第 2 四半期にもレポート） 信頼できる実行環境 非パブリック クラウド環境での高信頼実行環境（TEE）のサポート。 Google の対応は以前の四半期と同様です。

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

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

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

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

デジタル広告を測定する

Attribution Reporting（とその他の API）

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

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

この機能に関して、エコシステムに関するフィードバックがございましたら、いつでも受け付けております。
重複除去と優先度 重複除去の前に優先値を設定するようリクエストします。 Google ではこのリクエストを検討しております。よろしければフィードバックをお寄せください。
不正防止 悪意のあるユーザーがイベントレベルのデータを改ざんするリスク。 イベントレベル レポートがサポートされていないのはなぜですか？で説明されている理由により、イベントレベル レポートではレポートの確認が機能しません。
コンバージョンの種類 Attribution Reporting でビュースルーとナビゲーションを区別するにはどうすればよいですか。 次の組み込みフィルタ オプションが用意されています: source_type詳しくはこちらをご覧ください。

集計サービス

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

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

また、障害発生時に予算を取り戻し、広告テクノロジーがジョブを再実行できるようにする機能の開発も進めています。

Private Aggregation API

フィードバック テーマ まとめ Chrome レスポンス
Blob URL 共有ストレージで Blob URL をサポートするようリクエストします。 Chrome M116 で Blob URL がサポートされるようになりました。

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

User-Agent の情報量削減と User Agent Client Hints API

フィードバック テーマ まとめ 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 保護では、トラッカーとそのバリアントの構成要素をどのように決定しますか？ Google はこの質問の重要性を理解しており、サードパーティのトラフィックが許可されるのか、そうでないのかを判別するよう努めています。このトピックに関するフィードバックをお待ちしております。
アナリティクス IP 保護は分析サービスの精度に影響を与える可能性があります。 Google は、IP 保護の影響をより深く理解するために、エコシステムからのさらなるフィードバックや例を歓迎します。
プロキシ ユーザーがプロキシを使用している場合や、手動でプロキシを定義した場合、IP マスクはどのように機能しますか？ Google は、IP 保護が他のプロキシに与える影響を把握したいと考えています。現時点でお知らせできる情報はございません。このトピックに関するフィードバックをお待ちしております。
プレミアム サービス IP 保護は有料の機能になるのですか？ IP 保護は、ブラウザのコア エクスペリエンスの一部として、Chrome ユーザーに提供されます。有料の機能にはなりません。
プロキシ サーバー ユーザー セッションの間も同じプロキシ サーバーを使用しますか。 HTTP/S 接続はプロキシの 1 ペアを使用し、マスクされた単一の IP アドレスを送信元に提示します。異なる HTTP/S 接続で同じサーバーを使用する必要があるという厳格な制約はありません。
プラットフォーム サポート IP 保護はどのプラットフォームでサポートされますか？ IP 保護は、まず Android 版とデスクトップ版の Chrome でご利用いただけます。Google は、保護を他のプラットフォームに拡張する方法を引き続き評価しています。
オプトアウト ユーザーは IP 保護を無効にできますか？ Google は、IP 保護を使用するかどうかをユーザーが選択できるようにする予定です。
匿名化 IP 保護で匿名化されるリクエストの種類 対象となるサードパーティ ドメインに対する HTTP/S リクエストと DNS リクエストは、プライバシー プロキシを介して匿名化されます。含まれるドメインを決定する方法については、以降の説明で詳しく説明します。残りのトラフィック（残りの DNS リクエストや他の HTTP/S トラフィックなど）は影響を受けません。
データの可視化 ネットワーク アドレスには、IP 保護の最初のホップ中にアクセス可能です。 2 ホップ プロキシモデルでは、最初のホップ（Google が制御）は送信元クライアント IP と 2 番目のホップへの接続リクエストのみを認識し、2 番目のホップ（外部 CDN によって制御）は最初のホップ（プロキシ IP + ポート）と宛先 IP のタプルのみを確認します。送信元からのレスポンスの場合、2 番目のホップはリクエストに関連付けられた最初のホップのプロキシ + ポートにレスポンスを転送でき、元のクライアント IP について何も学習する必要はありません（また、最初のホップは宛先 IP について何も学習せず、クライアントにレスポンスを返すだけです）。このようにして、最初のホップはクライアント IP と 2 番目のホップのみを学習し、2 番目のホップは宛先 IP のみを学習します。
WebView IP 保護は今後 Android WebView で利用できますか？ 現時点では公開する予定はありませんが、この保護をできるだけ広範に提供することを目標としています。

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

フィードバック テーマ まとめ Chrome レスポンス
インタラクションのトラッキング ユーザー インタラクションのトラッキング方法 バウンス トラッキング対策は、次の 2 種類のユーザー インタラクションをトラッキングします。

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

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

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

インタラクションにより、関連ドメインがバウンス トラッキングの軽減ステータスの削除から 45 日間保護されます。
許可リストに登録された除外 ドメインを除外することはできますか？ Google はこのリクエストを検討しています。エコシステムからのフィードバックをぜひお寄せください。

プライバシー バジェット

今四半期はフィードバックを受け取っていません。

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

フィードバック テーマ まとめ Chrome レスポンス
集中型アプローチ 関連ウェブサイト セットを管理するための一元的なリポジトリ アプローチに対する懸念 簡単にアクセスできる公開リポジトリは、送信の説明責任を提供する RWS の設計の鍵です。サードパーティの Cookie 機能は、最終的には Storage Access API または rSAFor API を使用して提供され、RWS メンバーシップにより自動的にアクセス権が付与されます（Storage Access API でプロンプトが表示されることはありません）。Google は、サードパーティ Cookie の自動付与されるアクセスには、RWS 送信プロセスのようなアプローチが適切な要件であると考えています。
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 レスポンス
コンテンツの違反 ユーザーが不審な広告を報告できるようにします。 Fenced Frames では、不審な広告の報告を防ぐことはできません。ユーザーは引き続き広告を操作し、不審な広告を通常の方法で広告テクノロジーに報告できます。
周辺サイトとのやり取り 周辺またはトップレベルのウェブサイトとのインタラクションを許可します。 Google は、このリクエストが必要な理由を把握し、エコシステムからのフィードバックを歓迎します。
ネイティブ広告 ネイティブ広告でフェンス フレームがサポートされるようになりました。 Google では、このユースケースのサポートを検討しており、考えられる回避策とソリューションを検討しています。

Shared Storage API

フィードバック テーマ まとめ Chrome レスポンス
クロスドメイン ローカル ストレージ用にドメイン間の通信を許可します。 このユースケースは現在、共有ストレージのプライバシー保護出力ゲートに適合していませんが、パーティション分割されていないストレージの提案を進化させる中で、追加のコンテキストを歓迎します。
Blob URL 共有ストレージで Blob URL をサポートするようリクエストします。 Chrome M116 で Blob URL がサポートされるようになりました。

チップ

今四半期はフィードバックを受け取っていません。

FedCM

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

Google では、今後サードパーティ Cookie を使用しない FedCM のサポートを検討しています。

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

Private State Token API（とその他の API）

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