フィードバック レポート - 2024 年第 2 四半期および第 3 四半期

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

Google は CMA との約束の一環として、プライバシー サンドボックスの提案に関するステークホルダーのエンゲージメント プロセスについて、四半期ごとに公開レポートを提供することに同意しています（約束の第 12 項と第 17 項（c）（ii）を参照）。2024 年 7 月 22 日、Google は Chrome でのサードパーティ Cookie（3PC）を廃止せず、代わりにユーザーの選択肢を増やす最新のアプローチを導入することを発表しました。そのため、Google は CMA の同意を得て、Google と CMA が Google の発表の影響を十分に検討できるように、2024 年第 2 四半期の公開レポートを CMA に提出しませんでした。

これらのプライバシー サンドボックスのフィードバック概要レポートは、フィードバックの概要に記載されているさまざまなソースから Chrome が受け取ったフィードバックを集計して生成されます。これには、GitHub の問題、privacysandbox.com で公開されているフィードバック フォーム、業界関係者とのミーティング、ウェブ標準フォーラムなどが含まれますが、これらに限定されません。Chrome は、エコシステムからのフィードバックを歓迎し、学んだことを設計上の意思決定に組み込む方法を積極的に模索しています。

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

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

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

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

頭字語の用語集

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

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

フィードバック テーマ 概要 Chrome の対応
サードパーティ Cookie のサポート終了（3PCD） 3PCD に向けた Google の計画と、デジタル広告業界に対する長期的な影響の評価について Google は、ユーザーの選択肢を拡大する新しいアプローチを提案しています。こちらに記載されているとおり、サードパーティ Cookie のサポートを終了する代わりに、Chrome で新たなエクスペリエンスを導入します。これによりユーザーは、ウェブ ブラウジング全体に適用される、十分な情報に基づいて選択でき、その選択をいつでも調整できるようになります。Google は、この新しい方法について規制機関と協議しており、リリースに際しては業界とも連携していきます。
ユーザーの選択 ユーザー選択の発表は、プライバシー サンドボックス ソリューションの採用に対するエコシステムの関心を高めました。ユーザー選択に関するお知らせについては、モニタリング機能などの機能のリクエストなど、さまざまなフィードバックが寄せられています。 ユーザーの選択を重視した更新されたアプローチでは、クロスサイト ID に代わるプライバシー保護強化の代替手段をデベロッパーが用意することが引き続き重要です。新しいエクスペリエンスの詳細については現時点では未定ですが、Chrome での Cookie を使用しないトラフィックが大幅に増加することが予想されます。つまり、プライバシー サンドボックス API は引き続きビジネスにとって重要です。Google は、プライバシーと実用性をさらに向上させるため、プライバシー サンドボックス テクノロジーに継続的に投資していきます。
ユーザー選択 UI オプトアウト/同意機能のタイムライン、検討中のユーザー オプションの種類、UI が自動テスト環境に与える影響に関する質問。 現時点では、タイムラインに関する最新情報はございません。3PCD の開発を中止することを決定した後、できるだけ早くエコシステムに最新情報を提供したいと考えました。ユーザー選択のタイムラインについては、新しい情報が入り次第お知らせいたします。
Chrome テスト 2024 年第 1 四半期以降、3PCD の市場での普及と経済的影響を測定するために、Chrome でテストラベルを引き続き利用できるようにするリクエスト。 2024 年第 1 四半期の Chrome によるテストが終了しても、テスターはテストと調整にラベル付きブラウザ グループを引き続き使用したいと考えていることを認識しています。Google は、ユーザー選択に関するお知らせを踏まえ、ラベルの今後の対応を検討しています。それまでの間、Chrome チームは 2025 年 1 月までの Chrome マイルストーン 132 を通じ、ラベル付きブラウザ グループのサポートを拡大する意向を公開しています。
Android 版プライバシー サンドボックス Android 版プライバシー サンドボックスと Chrome 版プライバシー サンドボックスは密接に関連しており、Android なしでプライバシー サンドボックスを適切に評価することはできません。クロスデバイスとマルチタッチの要素を含む一般的なカスタマー ジャーニーは、Chrome のプライバシー サンドボックスと Android のプライバシー サンドボックスの両方にとって重要です。 Android 版プライバシー サンドボックスは、Google の CMA に対するコミットメントの対象外です。

フィードバックが Android のタイムラインとリリースに関するものである場合、現時点では Android の継続的な取り組み以外にお伝えできる情報はありません。Android はプライバシーを向上させるための独立したワークストリームとして扱われます。

すでにお伝えしたように、Android でプライバシー サンドボックス API を利用できるかどうかは、ユーザーがデバイスを更新する頻度によっても左右されます。これは Google の管理下にありません。
モード B トラフィック制限あり モード B の広告オークションのトラフィックが想定を下回っています。 Protected Audience API（PA API）のオークションのボリュームが想定よりも少ない理由は複数あります。たとえば、

- これまでに PA API を統合した企業は、バナー フォーマットのみを含めていました。
- セルサイド プラットフォームがオークションを開始するとは限りません。
- ブラウザにインタレスト グループ（IG）がない場合があります。
- 入札が行われていない可能性があります。

ただし、PA API のテストに失敗してトラフィックを受け取らなかったという報告は確認されていません。
サービス停止の可視性 プライバシー サンドボックス API に影響するサービス停止と問題の可視性。 ブラウザ外部にサービスがあるプライバシー サンドボックス API については、 公開ステータス ページがあります。

Chrome チームは、プラットフォームの信頼性と、ウェブ上の主要なサイトやサービスで使用されるすべての重要な API（プライバシー サンドボックス技術を含む）を最優先事項としています。これまでに停止したのは 1 回だけです。これは、1% でテストするための一時的な構成に関連していました。このサービス停止に関連する試験運用版の設定はまもなく不要になるため、Chrome で API が通常の方法で有効にされると、この問題は発生しなくなります。
Cookie グラフ調査 プライバシー サンドボックス フレームワークのこちらのホワイトペーパーで示されている CookieGraph メソッドに対する Chrome の見解は、どのようなものですか？ この論文では、ユーザーがアクセスしたドメインとは異なるドメインによって設定されたファーストパーティ（1P）Cookie の検出と普及について、興味深い点がいくつか指摘されています。論文が指摘しているように、これらの Cookie は、ユーザーがウェブサイトをどのように操作したかについて、分析や情報を収集するのに非常に便利です。このデータは、デベロッパーがユーザーに優れたブラウジング エクスペリエンスを提供するために不可欠です。

この論文では、ファーストパーティ Cookie をクロスサイト トラッキング ベクトルと見なしているため、この主張の主な根拠に欠陥があります。ただし、これは、論文で概説されている非常に積極的な前提条件下でのみ当てはまります。

  1. ユーザーがサイトと個人情報（PII）を共有することに同意している。
  1. デバイスには、サイト間でユーザーをトラッキングするために使用できる安定した指紋があります。

これらは再識別のベクトルであり、ファーストパーティ Cookie を使用しなくても（サーバーサイドのデータ共有などによって）悪用される可能性があります。また、サードパーティ Cookie のような状態ベースのトラッキング メカニズムに焦点を当てた現在の取り組みとは別に取り組む必要があります。

最後に、この論文では分析用 Cookie と広告 Cookie はトラッキング Cookie と同等であり、厳密に必要な Cookie はトラッキング以外の Cookie とみなしていますが、必ずしもそうとは限りません。実際、ファーストパーティ分析や、店舗検索ウィジェット、チャット ウィジェット、ロードバランサ Cookie など、サイトごとに分割されたベンダー サービスは、多くの場合 1 つのドメインに限定されます。逆に、厳密に必要な Cookie の中には、不正行為防止を目的としたクロスサイト トラッキングのものもあります。
UX の変更 Chrome 112 では UX が変更され、ファーストパーティ Cookie の管理が Chrome 設定の [デバイス上のサイトデータ] セクションに移動されました。これにより、ユーザーがすべての Cookie をブロックしにくくなる可能性があります。 この変更は、サードパーティ Cookie（またはパーティション分割されていないストレージ）の管理を、他のすべてのサイトデータから分離して強化する取り組みの一環です。サードパーティ Cookie の管理は [プライバシーとセキュリティ] パネルに移動され、ファーストパーティ Cookie と、サイトの重要な機能に通常依存する他のすべての種類のサイトデータの管理は [デバイス上のサイトデータ] にまとめられます。Google は引き続きこのトピックに関するフィードバックをモニタリングしていきますが、現時点では、有意なプライバシー管理の見つけやすさと、機能的なブラウジング エクスペリエンスの維持のバランスが取れていると考えています。
請求とお支払い テスターはプライバシー サンドボックス API の他の領域のテストに重点を置いているため、課金と支払いは完全にテストされていません。 デベロッパーや企業は、いつ、どのようなテストを行うかを自由に選択できます。これらの API は、2023 年 9 月からテスト用に一般提供されています。
テスト DSP が SSP から受信する試験運用中のトラフィックはすべてラベル付けされているわけではありません。一部の DSP から、ラベルのないテスト対象のインプレッションの割合が、トリートメント グループとコントロール グループで異なる可能性があるという報告がありました。 Chrome では、企業が入札リクエストでラベルを転送するかどうかを制御できません。ブラウザからラベルを取得するメソッドが用意されています。パートナーがラベルを直接読み取れない場合は、エコシステムがパートナーにラベルを渡すかどうかを判断します。
Android WebView での 3PCD サポート終了をテストするために、Android WebView で「サードパーティ Cookie の段階的廃止をテスト」フラグを有効にする方法に関するガイダンスをリクエスト。 Android WebView では、3PC はデフォルトでブロックされます。
モデル トレーニングのリスクを軽減する差分プライバシー モデル トレーニングで差分プライバシーを使用する理由 差分プライバシーと高信頼実行環境（TEE）を組み合わせることで、データ漏洩を防ぎ、機密情報を脅威から保護するためのモデル トレーニングが実現します。このアプローチにより、モデルの重みから個々のユーザーデータが漏洩することはありません。

登録と構成証明

フィードバック テーマ 概要 Chrome のレスポンス
登録 登録済みのオリジンと、www サブドメインを持つ広告テクノロジーのオリジンとの間で、構成証明の登録がどのように機能するかについて、明確な説明を求める。 広告テクノロジーは https://example.com にのみオンボーディングする必要があります。https://example.com/.well-known/privacy-sandbox-attestations.json に構成証明を配置すると、https://www.example.com はサブドメインであるためカバーされます。
API の仕様 構成証明ファイルの JSON スキーマをリポジトリに追加することを提案。 Google はこの提案を評価しており、こちらから追加のフィードバックをお待ちしています。

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

トピック

フィードバック テーマ 概要 Chrome のレスポンス
トピックの重み付け Topics で最も重要なことは、特定のシグナルの希少性です。現在の設計は、観測された各トピックの横に重み値を追加できるように進化する必要があります。あるブラウザにおける特定のトピックについて、そのトピックを使用しているすべてのブラウザと比較した相対的な重み付けが、ウェイトです。 シグナルの希少性が最も重要なシグナルである理由を詳しく説明します。このユースケースの有用性について、エコシステムからの追加のフィードバックをお待ちしております。こちらからお寄せください。
トピックの信頼性 Google は、トピックの信頼性について、長期にわたってより強固な保証を提供する必要があります。 API の変更は、エコシステムからのフィードバックに基づいて引き続き行われ、変更前に公開討論されます。Google が提案するガバナンス構造の見直しにより、さらなる保証が得られます。
分類器 パブリッシャーのサイトが誤って分類されたり、意味のある目的を果たすほど高すぎる Topics が割り当てられたりすることがよくあります。 トピックの分類に関する説明に記載されているとおり、サイトは、最も人気のあるサイトを含む人間がキュレートしたオーバーライド リストと、デバイス上の機械学習モデルを組み合わせて分類されます。Chrome では、トピックの分類にサイトが貢献するためのオプションを継続的に評価しています。ユーティリティの改善は、プライバシーと不正使用のリスクと比較検討する必要があります。

たとえば、次のようなリスクがあります。

- さまざまな（および機密情報の可能性がある）意味をトピックにエンコードするために自己ラベル付けを使用しているサイト、
- 他者にとっての有用性を損なうためにトピックを攻撃するサイト（ユーザーのトピックに無意味なノイズでスパム行為をするなど）。

一般ユーザーは、chrome://topics-internals または この Colab で利用可能なツールを使用して、これらのコンポーネントを検査できます。テストを重ねることで、分類の精度は向上していく予定です。誤って分類されている可能性があるサイトの例について、フィードバックをお寄せください。
API に関する質問 不適切なコンテンツを収益化する SSP が Topics API によって持続的で反競争的なメリットをもたらすことへの懸念。 サードパーティ Cookie と同様に、エンティティが登録され、証明されている限り、ブラウザは Topics を返す先のブラウザに依存しません。
（以前の四半期でも報告）

さまざまな種類の関係者に対する

有用性		 現在、トピック分類システムではページのホスト名のみを使用して対応するトピックを定義しているため、多様なコンテンツを扱う大規模なサイトは一般的なトピックを、小規模なサイトは広告価値の高いニッチなトピックを提供することになります。 回答は前四半期と同様です。

サードパーティ Cookie と同様に、さまざまなサイトから提供される情報の価値には違いがあります。ニッチな興味 / 関心のサイトは、価値の貢献が不安定です。ニッチな興味 / 関心のサイトには商業的に価値のあるコンテキストがないものもあり、価値の貢献が低くなります。Topics API のメリットを享受できるサイトは次のとおりです。Google は、サイトレベルではなくページレベルでの分類の可能性も検討しましたが、そのような分類にはプライバシーとセキュリティに関する重大な懸念事項がいくつかあります。
分類器 小規模なサイトには、不正確な分類が割り当てられるか、分類が割り当てられないことが多く、価値交換に参加できません。 申し立てられている損害について、誤分類される可能性のある特定のサイトは、他のサイトと比べてそれほど損害を受けません。これは、サイトのコンテキスト情報はオークションで常に利用可能であり、誤分類された場合でも、正しいトピックと同等の情報を提供できるためです。トピックは通常、自社サイトではなく外部ウェブサイトから有用な広告情報を収集するために使用されます。
分類のバージョン 下位互換性を確保するために分類バージョンにアクセスするにはどうすればよいですか？ 分類のバージョンは、トピック対応の取得リクエストで送信されるリクエスト ヘッダーの一部です。

たとえば、ヘッダーが「(1 2);v=chrome.1:2:5, ();p=P000000000」の場合、バージョンは chrome.1:1:2 です。ここで、chrome.1 は構成バージョン、2 は分類バージョン、5 はモデル バージョンです。

これは仕様で説明されており、説明にも追加されています。
Topics データ トピックデータの更新方法について明確にするようリクエストする。 分類の更新が指定されていません。これにより、ブラウザ ベンダーは実装を柔軟に行うことができます。

Chrome の分類の V1 から V2 への更新のヒューリスティクスは次のとおりです。

- V1 と V2 の両方のトピックに対して、単一の分類ツリーが維持されます。
- 同じトピック ID は同じ意味を表します。
- ツリーは増加のみを続けます。新しいトピックや接続を追加するだけで、縮小することはありません。
- ただし、一部のトピックやリンクはバージョンで「無効」になっているため、削除または再編成されたように見える場合があります。

例:

- 「ピックアップ トラック」に「トラック、バン、SUV」が中間親として追加されました。
- 「外国語の学習」の 2 番目の親が「教育」になり、元の親「参照」が無効になりました。

「無効」のトピックの影響: これらのトピックは、新しい分類には使用されません。ただし、ユーザーのブロックを適用する際には考慮されます。ユーザーが V1 でトピックをブロックした場合、V2 では子トピックが別の親の下に表示される場合でも、子トピックはブロックされたままになります。
分類器 誤った分類の原因と利用可能な是正オプションを把握すること。 まず、Chrome でサイトのトピックが判断されるのは、広告目的でユーザーの興味 / 関心を判断する Topics アルゴリズムの入力としてのみ使用されることを明記しておきます。他のより一般的な分類を目的としたものではありません。

Google は分類モデルの全体的な精度に注目しており、可能であれば適合率と再現率を改善しようとしていますが、個々のサイトの分類レベルではなく、グローバル レベルで改善しています。これは、誤分類が起きた場合、誤分類された個々のサイトに損害を与えるのではなく、他のサイトの広告選択時に Topics シグナルの品質が低下するためです。誤って分類されたサイトの広告を選択する場合、そのサイトの実際のトピックはすでにそのサイトに知られており、広告クエリへの入力として使用できます。

追加のフィードバックはこちらからお寄せください。
API テスト Topics や一般的なプライバシー サンドボックス API は Chromium でテストできますか？ Topics API は Chromium には同梱されておらず、Chrome に同梱されています。
Topics 呼び出し元 広告テクノロジーで TEE サービスを活用し、プライバシーに準拠した方法で高度な分析の費用をサポートする Topics の付加価値を高めるようリクエスト。 同様のフィードバックには、こちらで回答しています。逆頻度も検討しましたが、最終的に逆頻度をモデル化した結果、購入者と販売者から提供された価値に基づいて、逆頻度とトピック値に相関関係がないことがわかりました。

その他のフィードバックがございましたら、こちらからお寄せください。
API 仕様 ブラウザのインタレスト コホートの設定によって Topics API がブロックされる可能性はありますか？ このフィードバックには、こちらで回答いたしました。

Topics API は FLoC の進化版であり、FLoC の権限ポリシーを遵守しています。解説に記載されているように、「注: FLoC の古い Permissions-Policy: interest-cohort=() でもトピックの推定を禁止できます。」
トピックのランキング 「上位 5 つのトピック」を取得する際、ウェブサイトへのアクセス頻度は、対象となる各呼び出し元に基づいてカウントされますか？それとも、ブラウザのアクセス履歴全体に基づいて常にカウントされますか？また、トピックは呼び出し元ごとに個別にランク付けされますか？ 閲覧履歴のサブセットの頻度に基づいて算出されます。閲覧履歴のエントリ（ページ）が参加の対象となるのは、そのページに Topics の呼び出し元が 1 つ以上存在する場合のみです。トピック履歴の保存について詳しくは、こちらをご覧ください。

Topics API の機能強化に関するお知らせに記載されているとおり、ランキングは頻度とバイナリ優先度レベルによって異なります（詳しくは、こちらとこちらをご覧ください）。ただし、通話頻度には関係ありません。必ずしもすべての呼び出し元が、次のエポックで上位 5 つのトピックをすべて入手できるわけではありません。説明に記載されているように、「過去 3 週間以内に該当するトピックに関するサイトにユーザーがアクセスしたことが確認された場合にのみ、呼び出し元はトピックを受信できます。」ブラウザは、どの呼び出し元がどの上位 5 つのトピックを観測したかをトラッキングする必要があります（仕様の呼び出し元ドメインを含む上位 5 つのトピックに対応）。

この問題についてご意見がございましたら、こちらからお寄せください。

Protected Audience API（旧 FLEDGE）

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

費用		 TEE をパブリック クラウドで運用する場合、オンプレミスの広告テクノロジー データセンターと比べて費用が高くなる。 Google の現在の TEE セキュリティ モデルは、パブリック クラウドの実装のプラクティスを活用しています（詳細については、パブリック クラウドの TEE 要件の説明をご覧ください）。たとえば、現在のハードウェアベースの TEE は、すべての物理攻撃を防御するものではありません。Google がサポートしている既存のパブリック クラウド プロバイダである AWS と GCP は、社員によるものを含む物理的なアクセス リスクに対する緩和策を設計して実装しています。

一部の広告テクノロジーは、クラウド サービスの運用はオンプレミスの広告テクノロジーのデータセンターよりも費用がかかると言っていますが、他の広告テクノロジーは、費用やその他のメリットのためにパブリック クラウドで運用しています。

Google は、パブリック クラウドの外部を含む TEE サポートの拡大オプションを継続的に評価しています。その一環として、オンプレミス データセンターの調査を進めており、エコシステムと連携して、こうしたサポートを提供するための潜在的なソリューションを探っています。現時点では、この研究がエコシステムに実用的なソリューションをもたらすことを保証することはできません。
PA API と Google アド マネージャー（GAM） GAM では公正な市場結果を達成できません。GAM では、広告をタイムリーに配信できず、PA API を使用して配信された広告の数を報告できません。また、特定のスロットで PA API をオフにするなど、広告の配信に使用する方法を構成することもできません。 Google アド マネージャーの回答:

Google アド マネージャーでは、PA API を介して広告を配信する際のレイテンシの最適化に取り組んでおり、PA API デマンドによるパブリッシャー収益の増加が、PA API オークションのレイテンシの増加による費用を上回るようにしています。初期テストでは、パブリッシャー様がサードパーティ Cookie なしのトラフィックで Protected Audience API から純利益の面でメリットを得ていることが示されています。つまり、Protected Audience API によって増加したデマンドが、遅延による費用を上回っています。YouTube の取り組みについて詳しくは、よくある質問をご覧ください。

また、GAM では、PA API を介して配信された広告に関するレポートをパブリッシャーに提供しています。これには、Google アド マネージャーがコンポーネント販売者である場合に配信される広告と、Google アド マネージャーがトップレベル販売者である場合に他のコンポーネント販売者経由で配信される広告が含まれます。レポートについて詳しくは、ヘルプセンターをご覧ください。

最後に、GAM では、パブリッシャーは UI 内のコントロールを使用して、トラフィックでの PA API の使用を有効または無効にできます（詳しくは、ヘルプセンターをご覧ください）。ニュース メディアが希望する追加の管理機能に関するフィードバックは、Google が検討いたします。機能リクエストは、Google の標準的な機能の優先順位付けプロセスに沿って優先されます。
PA API、Google アド マネージャー/AdX Google は、AdWords が自社でのみ購入するように、GAM が最終的な販売決定を行わない PA API のインプレッションは購入しない立場を取っているようです。Google アド マネージャーまたは Ad Exchange は、他のエクスチェンジのように、別のトップレベルの販売者にコンポーネント オークション設定を送信する可能性があるため、純粋に市場地位の悪用と見受けられます。 Google 広告プラットフォームの担当者の回答:

これは Google の見解ではありません。Google の購入側プラットフォーム（Google 広告とディスプレイ＆ビデオ 360）は、Google 以外のエクスチェンジからインプレッションを購入します。これは、PA API のインプレッションと PA API 以外のインプレッションの両方に該当します。
市場の反応 Mozilla の懸念: Google の Protected Audience は、広告主（と Google）を保護するよりも、広告主を保護する。 Mozilla の評価に感謝いたします。Google は、公開されている標準フォーラムで Mozilla のフィードバックに引き続き対応いたします。この評価のテーマは、PA API の現在の実装では、計画されている保護対策のすべてがまだ適用されているわけではないということです。Google は、PA API の市場投入アプローチにおいて、実用的な限り早急にプライバシー保護を導入しつつ、導入を促進することのバランスを取ることを目標としてきました。この取り組みの一環として、API との統合をよりスムーズに進め、今後の保護対策（Fenced Frames の VAST 機能など）に組み込むためのフィードバックをより多く収集できるように、段階的にプライバシー制限を適用するためのロードマップを策定しました。

また、Mozilla がプライバシーとデジタル広告に対する独自のアプローチについて発表した「自由でオープンなインターネットはプライバシーを犠牲にしてはならない」と「プロダクトとインフラストラクチャを通じてオンライン広告を改善する」も歓迎します。
（前四半期にも報告あり）

オークションの結果		 単一のオークションで複数のレンダリング URL と対応するスコアを返すようにリクエストします。これにより、ネイティブ広告で重複を排除し、UX とレイテンシの問題を回避しやすくなります。 回答は前四半期と同様です。

Google は、単一の PA API オークションから複数の renderURL とそれぞれのスコアを共有することを検討しましたが、プライバシーに関する懸念から実装しませんでした。

同じ広告が同じユーザーに 1 つのページで複数回表示されないようにしたいというご要望はよく理解しており、現在、このリクエストを検討しております。ネイティブ広告のユースケースを最適にサポートするために PA API で追加のサポートが必要な点について、エコシステムからのフィードバックをお待ちしております。こちらからお寄せください。
パフォーマンス PA API に影響するレイテンシに関する懸念。 レイテンシに関する懸念の声を多数いただいておりました。そのため、SSP が DSP レイテンシの上限を設定できるだけでなく、レイテンシを短縮できる改善も可能にする、PA API の一部として多くの機能を開発しました。 レイテンシに関するベスト プラクティス ガイドが最近更新されました。このガイドには、これらの機能を活用する方法に関する詳細な情報が記載されています。また、新しいレイテンシ改善の開発も継続しており、その一部は こちらでご覧いただけます。
最上位の販売者 パブリッシャーが、トップレベルの PA API オークション セラーの代替を選択できるようにする必要があります。 PA API は、単一販売者と複数販売者の両方の設計において、誰がオークションを開始するかに関係なく機能します。PA API オークションをサポートするかどうか、またどのようにサポートするかは、各企業が独自に選択します。
（前四半期にも報告）

除外ターゲティング		 広告主が特定のオーディエンスに広告を表示したくないというユースケースに対するソリューションのリクエスト。 Google は、追加の（コンテキスト ベースの）入札単価による IG の除外ターゲティングをサポートしています。これにより、特定のオーディエンスに広告を表示したくない広告主様のニーズを満たすことができます。

詳細については、こちらの説明と こちらの GitHub の問題をご覧ください。

また、PA API 入札の IG 除外ターゲティングをサポートするソリューションも検討中です。こちらからフィードバックをお寄せください。
（前の四半期にも報告されています）

ネイティブ広告		 ネイティブ広告のフェンスド フレームのサポートをリクエスト。 Google はこのユースケースのサポートを検討しており、 こちらで可能な回避策と解決策について説明しています。
WebView Chrome で IG が参加したオークションが WebView で実行されたオークションで利用できなかったシナリオについて、明確化を求めています。 十分なプライバシー インフラストラクチャが利用可能になり次第、Google はこれらのユースケースをサポートする予定です。現時点では、これ以上お知らせできる情報はありませんが、 こちらからフィードバックをお寄せください。
否定的な IG 初期ヘッダー機能を使用して、除外 IG をサポートする updateURL 処理のリクエスト。 現在、このリクエストを審査中です。こちらから追加のフィードバックをお寄せください。
ダイバーシティ フィルタリング 複数の販売者と複数のオークションで PA API を使用してネイティブ広告を実行する場合の多様性フィルタの実装方法に関するガイダンスのリクエスト。 現在、このリクエストについて こちらで検討しております。追加のフィードバックがございましたら、ぜひお寄せください。
（以前の四半期でも報告）

ブロック フィルタ		 複数の販売者を使用して PA API でネイティブ広告を配信する際に、「パブリッシャーのブロック」（フィルタ）ルールを適用する方法に関するガイダンスの提供をリクエスト。 こちらにガイダンスを記載しております。ご意見やご感想をお寄せください。
制限事項 サブドメイン レベルではなく、ドメイン レベルで制限を許可するようリクエストします。 サブドメイン レベルまたはオリジン レベルでの制限は、ウェブの基本セキュリティ モデルに従うため、これが Google のデフォルトの設計です。

この件について詳しくは、こちらとこちらをご覧ください。
信頼性の高い入札 信頼できる入札シグナル リクエストでのユーザー エージェントと関連するクライアント ヒントのリクエスト。 YouTube ではこの機能リクエストをトラッキングしており、 こちらで追加のフィードバックをお待ちしております。
（前四半期にも報告あり）

複数の IG		 同じ入札単価で複数の Instagram を使用する。 これは、基盤となるプライバシー モデルの変更につながるため、現在 PA API ではサポートされていません。

詳しくは、 こちらをご覧ください。
（前四半期にも報告）

パフォーマンス		 ロジックをクライアント側に移行すると、ページのパフォーマンスや UX が低下し、ウェブサイトの SEO スコアが低下する可能性があります。 Google はこの問題について現在調査中です。 こちらから追加のフィードバックをお寄せください。
オークションの動向 PA API では、オークションの動向に関する情報（参加者、オークションにかけられた各コンポーネントの落札者など）が削減されるため、パブリッシャーの追跡可能性が低下し、取引が維持されているかどうかを把握しにくくなります。 取引の追跡に関するソリューションは、こちらで提案しています。既存のフィールドの一部を修正し、IG オブジェクト内に新しいフィールドを作成して取引 ID とシート ID を保存し、イベントレベルのレポートを介して、generateBid から scoreAd または下り（外向き）に伝播できるようにする予定です。これにより、取引のユースケースを適切にサポートできます。

広告テクノロジーがオークションの動向に重要とみなしている、パブリッシャーがこのトレーサビリティを維持するために必要なその他のメタデータについて、フィードバックをお寄せください。広告テクノロジーには、参照するメタデータの具体例と、どのパーティから流入する必要があるかの具体例を提供することをおすすめします。
GAM AdX のデマンドにアクセスするには、パブリッシャーの広告サーバーとして GAM を使用しなければならないという要件に関する懸念。 Google アド マネージャーから提供された回答:

GAM では、エクスチェンジ機能にアクセスするためにパブリッシャーが広告サーバー機能を使用する必要はありません。
（前四半期にも報告あり）

コンポーネント オークション		 PA API コンポーネントのオークションの落札者は GAM に表示されるため、情報へのアクセスの不平等に関する懸念が生じます。 回答は前四半期から変わっていません。

Google アド マネージャーから提供された回答:

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

PA API オークションでは、Google は約束を守り、マルチセラー オークションでオークションが終了するまで、オークション参加者の入札価格を他のオークション参加者と共有することはありません。なお、こちらの最新情報で説明したように、Google はコンテキスト オークションの価格を、Google 自身のコンポーネント オークションを含むどのコンポーネント オークションとも共有しません。

また、Google は、コンポーネント オークションの構成に関する情報（購入者が SSP に提供するシグナルなど）を、Google 独自のオークションで使用しません。実際、Google は、コンポーネント販売者がトップレベルの販売者から難読化された方法でコンポーネント オークション構成を指定できるように、PA API を変更することを歓迎します。」
GAM Instagram または PA API コンポーネント オークションに参加していない場合、Google アド マネージャーはトップレベル オークションの実施/レポートについて収益分配をリクエストしますか？ Google アド マネージャーから提供された回答:

パブリッシャーが GAM を広告サーバーとして使用する場合、GAM はトップレベル オークションを実施し、広告サーバー機能に対して広告配信料金を請求します（PA API オークションの外部で適用される広告配信料金と同じです）。

ただし、落札した広告が GAM 以外のコンポーネント販売者から提供された場合（つまり、GAM が IG または PA API コンポーネント オークションの作成に参加していない場合）は、GAM は請求を処理せず、メディア料金の割合を請求しません。
クリック感 クリック イベントの登録にも同じ差分プライバシーが適用されますか？ 現在のところ、この機能は「k-anon」の制限の対象となる予定はありません。これは、「クリック数」が generateBid() 関数内の browserSignal としてのみ使用され、イベントレベルのレポートでは新しい属性として使用できないためです。
パフォーマンス コンテキスト入札リクエストに無条件で応答するため、下り（外向き）の費用が高くなる。 プライバシー上の理由から、IG を備えた DSP に関する情報を直接提供することはできません。ただし、プライバシーを保護しながら分析情報を提供できる代替ソリューションの検討を進めています。
ネイティブ広告とアウトストリーム広告 ネイティブ広告とアウトストリーム広告に関する Chrome の見解に関する最新情報をリクエストする。 Chrome の位置は、該当するユースケースによって異なります。

動画については、Chrome の立場は、Google の API を使用して、エコシステムが実用的なインストリーム動画ソリューションに収束するよう促すことです。現時点では、GAM の提案が唯一の具体的な提案です。

ネイティブ広告については、こちらでフィードバックを積極的に収集しており、近日中に広告テクノロジーを活用したより多くの検出ステップを導入する予定です。
リアルタイム モニタリング（RTM） ラベル付きトラフィックは RTM レポートを送信しません。 Google ではこの問題を認識しており、解決に向けて取り組んでいます。

新しい情報が入り次第、こちらでお知らせいたします。
オーディエンス拡張のサポート PA API におけるオーディエンス拡張/販売者が選んだオーディエンスのサポートに関する最新情報のリクエスト。 Google では、このユースケースに対応するソリューションの提供に取り組んでいます。YouTube では、どのような機能を構築してサポートすべきかについて、エコシステムからフィードバックを収集しています。

新しい情報が入り次第、お知らせいたします。こちらからフィードバックをお寄せください。
デバッグ Chrome のデベロッパー ツールには、PA API の詳細なパフォーマンスをモニタリングするパネルがありません。たとえば、全体的なパフォーマンスは IG の数や購入者の数によって影響を受ける可能性があります。 この具体的なフィードバックは、モニタリングを支援する Chrome デベロッパー ツール UI の機能に関するものです。10 月 7 日、広告テクノロジーがモニタリングとアラートの基盤として使用できるカスタム イベントを設定できる機能を導入しました。詳しくは、こちらをご覧ください。今回の更新により、このフィードバックの大部分に対処できると考えています。

サポート対象のデータポイントやデベロッパー エクスペリエンスなど、この機能についてさらにフィードバックがございましたら、こちらの GitHub ディスカッションでお知らせください。
シグナル DSP がコンテキスト オークションの結果に関係なく perBuyerSignals を SSP に確実に送信できるかどうかに関する懸念。 コンテキスト オークションでは、1 つの DSP から 1 つの落札入札単価のみが存在すると想定されます。つまり、その後の PA API オークションで上回ろうとする入札単価が 1 つあると想定されます。PA API フローの場合、SSP は（オンデバイス IG の形式で）送信の需要があるかどうかを確認したいすべての DSP を招待することを決定します。コンテキスト オークションで落札できなかった DSP が、PA API オークションへの参加に「再招待」される可能性は十分にあり、実際には非常に高いと考えられます。この「再招待」では、DSP が承諾する場合、広告検証ツールが DSP に検討を依頼するシグナル（そのキャンペーンに存在する場合）を SSP に転送します。

つまり、PA API オークションでは、コンテキスト オークションで何が起こったかに関係なく、DSP が perBuyerSignals を SSP に送信する方法が常に存在します。
シグナル generatedBid() に渡される browserSignals オブジェクトに prevClicks を追加するリクエスト。 このリクエストは、クリック率シグナルをサポートする Google の提案によって解決できます。この機能については、先日のブログ投稿と、対応する説明記事でお知らせしました。

この提案についてご意見がございましたら、こちらからお寄せください。
（前の四半期にも報告あり）

シグナルのモデリング		 モデリング シグナルのビット数を 12 ビットから 30 ビットに増やすリクエスト。 このフィードバックに対し、こちらで反論の提案をしています。Google は、提案に対する業界の意見を把握するために積極的に業界と連携しており、現在、業界へのメリットと Chrome ユーザーやその他の関係者への影響を比較検討しています。
ドキュメント Key-Value（K/V）サーバーおよび TEE の使用方法に関するガイダンスをリクエストします。 K/V のコンテキストにおける TEE の使用に関するガイダンスについては、K/V サービスの信頼モデルの設計の詳細について、こちらをご覧ください。
否定的な IG の存続期間 除外 IG の有効期間を 365 日に延長するようリクエストします。 除外リストは広告の表示を防ぐために使用されますが、不正な行為者は除外リストを使用してユーザーに関する情報を入手し、再特定のリスクを招く可能性があります（たとえば、不正な行為者が攻撃を行う方法の一つは、除外リストを含む高額の入札単価を繰り返し設定して、ユーザーが特定のサイトにアクセスしたかどうかを把握することです）。

TTL を 365 日間維持すると、不正な行為者によるネガティブな IG に関するデータが大幅に増加し、プライバシー リスクが大幅に増大します。

そのため、ユーザーのプライバシーを保護するため、このリクエストには対応いたしかねます。
API 仕様 perBuyerSignals の一部として渡される値として挿入できるのはどのようなものですか？販売者が任意に定義できますか？ perBuyerSignals は、オークション内で提供したい情報を販売者が購入者に提供する場所です。

何を挿入するかはエコシステムが決定しますが、こちらで追加のディスカッションも歓迎します。
広告サイズのマクロの置き換え 広告サイズのマクロの置換が機能しない問題について、ガイダンスを求めています。 詳細については近日中に公開いたします。
入札後の SSP マクロの置換: トップレベル URL のなりすまし 検証ベンダーがプライバシー サンドボックス フレームワーク内でトップレベル URL を検証できるように、Chrome で導入できるメカニズムはどれですか。

フェンスド フレーム内で、SSP から提供されたトップレベル URL の精度を確保するために使用できる代替のデータポイントやシグナルはありますか？		 フィードバックについては、こちらで引き続き受け付けております。
機能のリクエスト updateURL の取得とリアルタイム レポートのポストバックで低エントロピーの UACH を提供するようリクエスト。 これらのリクエストについては、こちらで議論されています。こちらとこちらで、追加のフィードバックをお寄せください。
機能のリクエスト 特定のクライアントがトリガーされ、forDebuggingOnly.reportAdAuctionWin() と forDebuggingOnly.reportAdAuctionLoss() を介して、ダウンサンプリングされた forDebuggingOnly イベントレベル レポートを送信したときに、デバッグ デザインを有効にすることを信頼できるサーバーに同意するよう求めます。 これは現在追跡中の有効なリクエストです。利用可能になり次第、エコシステムに最新情報をお知らせします。フィードバックはこちらからお寄せください。
API 使用量 ユニーク ユーザーリーチとインプレッション リーチをカウントする方法に関するガイダンスを求めるリクエスト。 共有ストレージ ワークレット内から IG を読み取って、非公開集計レポートを送信できるようにする方法の提案について検討しています。

詳細については、こちらをご覧ください。この提案とエコシステムへの有用性について、フィードバックをお待ちしております。
API 使用量 パブリッシャーがテストすべき内容、重要な API、有効にする API、今後の予定が明確でない。 パブリッシャーとエコシステムにおけるその役割をより適切にサポートするための取り組みが進行中です。
API 使用量 広告オークション ワークレット イベントにイベント リスナーを追加できますか？ これは通常のイベントでは不可能です。ただし、Chrome Devtools プロトコル イベントでは、このユースケースの一部に対応できます。

通常のイベントは、分離/プライバシーのプロパティに影響する可能性があります。詳細については、こちらをご覧ください。
k-匿名性 広告のレンダリング要件について明確にしたい（例: 広告が表示された場合、少なくとも 50 人に広告が表示される）。 デベロッパー向けドキュメントでは、今後の開発に関する Google の期待事項の概要を説明しています。特に、初期の k-匿名性のしきい値は k=10 人であると説明しています。

blink-dev メーリング リストでは、Chrome で現在進行中の最新情報を確認できます。

k-匿名性メーリング リスト スレッドに記載されているとおり、Google は現在、Chrome Stable トラフィックの約 1% に k-匿名性の要件を試験的に適用しており、明示的にラベル付け（「モード A」と「モード B」）のスライスには適用していません。
擦れ TEE K/V チャッフィングは、プライバシー保護と実用性（つまり、キーワード/動画パフォーマンス/費用など）？ このタイプのリクエストは、チャッフィングを制御できる非本番環境インスタンスでのみ処理されます。本番環境インスタンスでは、引き続きチャフが必要です。非本番環境の使用に関するフィードバックを受け取ったら、状況を評価できます。
チャッフィング デバッグ/非本番環境の K/V バイナリからのチャットを無効にするフラグを追加するリクエスト。 このフラグはリリース 1.0.0 で提供されています。
API バグ Chrome 126 にアップグレードした後、設定で API が有効になっているにもかかわらず、API が機能しなくなった。 この問題は、開発目的でユーザーが有効にした Chrome フラグ「enable-fenced-frames」に関連していることが判明しました。このフラグをデフォルトにリセットすると、問題は解決します。
レポート リアルタイム レポート API のオプトインが購入者に対して販売者に依存しないようにするリクエスト。 このリクエストは こちらで審査中です。
最近リリースされた RTM ソリューションは、すでにこの機能を導入済みの広告テクノロジーからのフィードバックを歓迎します。
レポート サードパーティのレポートのリクエスト: DSP と SSP は Chrome からインプレッション通知を受け取りますが、中間レイヤの技術プロバイダはデフォルトで受け取りません。 現在、このリクエストについて検討しております。追加のフィードバックがございましたら、こちらからお寄せください。

Protected Auction サービス

フィードバック テーマ 概要 Chrome の対応
TEEs Google の技術基準に基づく手動オンボーディングの要件は、クラウド ベンダーの選択に厳しい制限を課します。Google が想定しているように、適用される技術基準は、クラウド プロバイダ局に訪問しなくても遵守できます。代替プロバイダの遅延が 2025 年（早くても）まで引き延ばされることは許容できません。これは、Google のソリューションへのチップを促進するネットワーク効果をもたらすためです。 集計サービスは、一部の広告テクノロジー ユースケースに対応するために TEE サービスで実行する必要がある唯一のサービスです。集約サービスは、アマゾン ウェブ サービス（AWS）と Google Cloud Platform（GCP）の両方をサポートしています。広告テクノロジーから寄せられたフィードバックに基づき、現時点ではこのようなサポートで十分であると判断いたしました。

その他のクラウド プロバイダについて - Google は、パブリック クラウド プロバイダにおける TEE の詳細な基準を公開しています。これらは、TEE ソリューションが プライバシー サンドボックスのプライバシーとセキュリティの目標を満たすことを目的としています。

具体的には、プライバシー サンドボックスの TEE サーバーは、暗号化されていないクロスサイト ユーザーデータ（アグリゲーション サービスのパブリッシャー サイトと広告主サイトのデータなど）を処理します。API のユーザー プライバシーの目標を達成するには、これらのデータが安全である必要があります。同様に、API が企業の機密ビジネス情報を継続的に保護できるように、安全な環境も必要です（たとえば、他の PA API オークション参加者が購入者の独自のビジネスデータにアクセスできないようにするなど）。

現在のところ、敵対的なオペレーターからユーザーデータを完全に保護する TEE 技術はありません。そのため、クラウド プロバイダの信頼性を検証するための複数の要件が含まれています。

「クラウド プロバイダ局」が何を指しているのか不明であり、要件の一部ではありません。要件についてのフィードバックをお待ちしています。また、説明で定義されているプロセスに沿って提出されたリクエストに基づくなど、新しいプロバイダのサポートも引き続き評価しています。今のところ、Azure のサポート リクエストしか受けていませんが、これは現在評価中です。
B&A 設計は継続的に進化しているため、B&A サービスの技術的な複雑さと実現可能性を評価することは困難です。 これらの懸念に対処するため、B&A の設計に関する詳細な説明を GitHub で公開し、提供開始のタイムラインと PA API をサポートする機能のロードマップを公開しました。Google は、B&A をデプロイし、GitHub のエコシステムからフィードバックを収集しようとしている広告テクノロジーをサポートしています。
B&A TEE の使用を開始するか、オンデバイスから TEE の使用に移行するために、B&A で TEE を使用する費用を計算するガイダンスとより良い方法を探しています。 Google は最近、K/V サーバー インスタンスのサイズ設定ガイドを公開しました。このガイドには、費用をより正確に測定するためのツールが含まれています。
K/V サーバー 広告検証ツールが、K/V サーバーの完全なページ URL を使用して広告検証を実行できるようにリクエストしている。 現在、広告の検証を目的として、TEE で実行されている K/V サーバーにページの完全な URL を提供する可能性を検討しています。K/V BYOS では、ページ全体の URL は使用できません。
オークションのセキュリティ 悪意のあるユーザーが機密データにアクセスしたり、なりすまし行為を行ったりできないようにするオークションのセキュリティ機能について - リプレイ攻撃からオークションを保護する機能と、セキュリティ保護対策を実装する方法 B&A の現在のセキュリティ モデルでは、オークションの完全性を保護できます。B&A は TEE で実行され、悪意のある行為者から広告テクノロジーのシグナルとコードの機密性を保護します。

B&A アーキテクチャでは、暗号化された B&A リクエスト ペイロード（リクエストの暗号文）が、クライアントから信頼できない広告サーバーを経由して SellerFrontEnd サービス（SFE、TEE で SSP によって実行）に送信されます。リクエストの暗号文には、タイムスタンプベースの生成 ID が含まれています。SFE はリクエストのタイムスタンプを調べ、サーバー時間から ±n 秒以内にないリプレイ リクエストを拒否します。さらに、B&A はサーバー間通信のために、パディングされた固定サイズのレスポンス ペイロードを返すことができます。これらのソリューションは、悪意のある攻撃者が同じリクエスト ペイロードをリプレイしてコンテンツの詳細を取得しようとした場合に、システムを介したリプレイ攻撃を軽減するのに役立ちます。

B&A は、説明動画でセキュリティ モデルを文書化し、更新しています。

K/V サーバー経由のシグナル		 K/V サービス経由で送信された perBuyerSignals を、Chrome からの信頼できる入札シグナル リクエストの一部として含めるようリクエスト。 ページの完全な URL を含む、TEE で実行されている K/V サーバーに転送された perBuyerSignals の情報を含める可能性を評価しています。
K/V サーバー K/V と B&A のプライバシー制約の段階的な導入スケジュールをリクエスト。 TKV の導入に段階的なアプローチを希望されていること、K/V と B&A に関する具体的なリクエストがあることを理解しております。

しかし、慎重に評価した結果、現時点ではこれらの API のプライバシー保護を緩和しないことにいたしました。Google は、ユーザー プライバシーを保護し、プライバシー サンドボックスに対する信頼を維持するために、チェーフィングなどの対策が重要であると考えています。
K/V サーバー 互換性のある構成で K/V ストアをスケーリングする方法についてガイダンスを求めています。 詳しくは、最近公開された K/V サーバー インスタンスのサイズ設定ガイドをご覧ください。このツールでは、パラメータの組み合わせごとに QPS（説明では「RPS」）が表示されます。
K/V サーバー K/V サーバー リクエストに販売者情報を追加しました。 現在、この件について検討中です。こちらから追加のフィードバックをお寄せください。
K/V + B&A サービス K/V と B&A のリリース タイムラインまたはロードマップを明確にするようリクエストします。 K/V と B&A の両方には、ステージとタイムラインがあります。

オンデバイスの PA API オークションと組み合わせた K/V サーバー（B&A と比較）の公開タイムラインは、こちらで確認できます。K/V の「一般提供」の定義については、ベータ版と一般提供の機能セットが定義されているロードマップ セクションをご覧ください。

B&A の公開タイムラインはこちら、ロードマップについてはこちらをご覧ください。スケール テストは「完全な安定性、本番環境規模のテスト」と定義されています。この段階の具体的な機能セットについては、こちらをご覧ください。

B&A にはアルファ版とベータ版のステージもあるため、大規模テストにはそれ以前のステージの機能のスーパーセットが含まれます。

K/V と B&A の両方について、これらのステージの定義が、いつ何を利用できるかを明確にすることに役立つかどうかをお知らせください。それでも問題が解決しない場合は、お知らせください。計画に役立つよう、より具体的な内容に変更させていただきます。

デジタル広告の測定

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

フィードバックのテーマ 概要 Chrome のレスポンス
市場の反応 競合するアトリビューション システムで、イベントレベル レポートと要約/集計レポートのみを厳しい制限内で使用するよう求める要件は、競争に対する恣意的な制限です。データ保護コンプライアンス（匿名化など）を確保するための安全保護対策が講じられている場合でも、イベントレベルでデバイス固有のリターゲティングやアトリビューションをリアルタイムで行うことができなくなります。 この設計は、API のプライバシー目標（サイト間で受け渡されるクロスサイト情報の保護など）に基づいています。たとえば、ARA はイベント レポートによるイベントレベルのアトリビューションをサポートしています。イベント レポートは最低でも 1 時間遅れてレポートされます。これは、タイミングサイドチャネル攻撃を使用して、イベントレベルのレポートと広告主のサイトのユーザー ID を関連付けるのを難しくするために必要です。こちらをご覧ください。

また、アトリビューション分析の方法は ARA 以外にも存在します。たとえば、個人を特定するデータを意図的に提供したユーザーから情報を直接収集するなど、複数の方法があります。

現在のプライバシー サンドボックス API のプライバシー境界では実現できないユースケースについては、フィードバックを受け付けています。
マルチサーフェス ARA と Shared Storage API がマルチサーフェスのユースケースをサポートしているかどうか、またそれが裏付けられているかどうかを確認するためのリクエスト。 現在、ARA と共有ストレージはマルチサーフェス（クロスデバイス）アトリビューションをサポートしていません。同じデバイスでのアプリとウェブのクロス アトリビューション（ARA 経由）がサポートされています。
（前四半期にも報告あり）

クロスデバイス		 ARA はクロスデバイス コンバージョンに対応していますか？ Google の回答は、前四半期と同様です。

クロスデバイスは、サードパーティ Cookie に加えて新しいプライバシー上の課題をもたらします。また、ユーザーが使用するデバイスやプラットフォームの範囲が広いため、技術的な配信の課題も追加されます。解決策を検討中ですが、現在は ARA でサポートされている重要なユースケースに重点を置いており、クロスデバイス サポートのタイムラインは未定です。
スケーリング Attribution Report API（ARA）が現在設定されており、すべての Chrome ユーザーにサービスを提供するために信頼性の高いロールアウトとスケーリングが可能かどうかに関する懸念。 ARA は現在、すべての Chrome ユーザーが利用可能で、想定どおりに動作しています。また、ARA をテストしている広告テクノロジー企業の数は増加し続けているため、Google は ARA の信頼性とスケーラビリティのテストとモニタリングを継続しています。

この件に関するエコシステムのフィードバックがありましたら、こちらからお寄せください。
（前の四半期でも報告）

重複除去		 ARA でデバイスのアトリビューション メカニズムが制限されるため、パブリッシャーが同じ広告クリックに対して同じタイプの複数のコンバージョンの重複を除去するなど、サマリー レポートでアトリビューション後のロジックを効果的に実行できないという懸念。 Google の回答は前四半期から変わっていません。

デバイスや測定パイプライン間での重複除去は、広告テクノロジーが現在 3PC で直面している既知の課題です。ARA を使用すると、広告テクノロジーは特定のコンバージョンを登録するタイミングを決定し、特定のメタデータを追加して、コンバージョンのトラッキングに使用した測定パイプライン（集計キーの一部）を示すことができます。この情報は、他の測定パイプラインと比較できます。

この件について、エコシステムからの追加のフィードバックをお待ちしております。こちらからお寄せください。
コンバージョン トラッキング 複数のドメインのコンバージョンを扱えるようにする機能のリクエスト。 現在、このリクエストについて こちらで検討しております。エコシステムに関するフィードバックがありましたら、ぜひお寄せください。
レポート ブラウザはコンバージョンを送信するまでに 2 日以上 30 日以内待機します。これは、ステークホルダーの広告主のほとんどが、ほぼリアルタイムで作業するパフォーマンス重視の広告主であるため、懸念の原因となる可能性があります。 イベントレベル レポートのデフォルト設定では、2 日間、7 日間、30 日間というデフォルトのレポート期間が設定されています。

柔軟なイベントレベルのレポートを使用すると、広告テクノロジーでレポート期間の数と長さをデフォルト値から変更できます。レポート期間を最短で 1 時間に変更すると、パフォーマンスを重視する広告主のユースケースで役立ちます。

この件について、エコシステムからの追加のフィードバックをお待ちしております。こちらからお寄せください。
オンラインからオフラインへのアトリビューション ARA では、オンラインからオフラインへの広告掲載に関して、広告の実装方法はありますか？または、オフラインからオンラインへのアトリビューションの測定に関して、他に推奨される方法はありますか？ 現在のところ、ARA でオンラインからオフラインへの測定ユースケースをサポートする予定はありません。このタイプのサポートでは、プライバシーとセキュリティに関する重大な課題を考慮する必要があります。

このサポートのユースケースに関するエコシステムからのフィードバックは、こちらからお寄せください。
デバッグ レポート アプリからウェブのアトリビューションを行う Chrome（ソース / トリガー）の登録で、AdID にアクセスできるように保存または取得するにはどうすればよいですか？ デバッグ レポートを有効にするには、広告テクノロジーがアプリとウェブの両方でユーザーをすでに統合できることを Google に証明する必要があります。これは、デバッグ レポートによって新しい情報が漏洩しないようにするためです。広告テクノロジーは、ユーザーごとに一意の結合キーを提供することで、結合を証明できます。この結合キーは、AdID またはファーストパーティの結合キーにすることができます。広告テクノロジーが AdID を使用している場合、Chrome はブラウザから AdID にアクセスすることをネイティブにサポートしていません。API では、各広告テクノロジーがウェブ登録時に AdID を渡す独自の方法を持っていることを前提としています。
バケットの粒度 広告主ごとに異なるバケット戦略を使用できますか？ さまざまな方法で資金提供予算のスケーリングを試し、ユースケースに最適な方法を見つけることをおすすめします。ARA は、さまざまな広告テクノロジーのユースケースを満たすために、柔軟かつカスタマイズ可能なように作られています。そのため、広告主様または業種ごとに異なるバケット化戦略をテストすることをおすすめします。異なるバケット化戦略を使用すると、トラッキングする測定値と測定値の量が異なる場合に役立ちます。
ドキュメント ARA のアプリ<>ウェブの実装に関する追加ドキュメントの依頼。 ARA のアプリとウェブの連携に関するドキュメントは、こちらで公開されています。
パフォーマンス ARA 関連のリクエストの数は、サイトの動作に必要なキープアライブ リクエストの数と比べて、パブリッシャー様のサーバーに重い負荷がかかる可能性があります。ソースイベントを 1 つのリクエストでバッチ処理すると、サーバーの負荷を軽減できます。たとえば、JSON でエンコードされたオブジェクトの配列を 特定のロジックに基づいてソースイベントをバッチ処理することは、API と JavaScript ロジックを組み合わせることである程度可能です。現在このリクエストを評価しています。エコシステムからの追加のフィードバックをお待ちしています（こちら）。
機能のリクエスト サーバー間統合がサポートされていないため、回避策の提案。 現時点では、ARA でのサーバー間統合のサポートは導入する予定はありません。サーバー間統合をサポートするには、プライバシーに関する多くの課題をさらに検討する必要があります。

サーバー間サポートの追加のユースケースについて、こちらからエコシステムからのフィードバックをお待ちしています。
ドキュメント ARA の主要部分や、いくつかの簡単なユースケースで利用を開始する方法を説明した「クイックスタート」ガイドの依頼。 ARA のクイック スタートガイドは、こちらから入手できます。

Google では、今年中にこのドキュメントの改善に取り組んでまいります。ドキュメントの追加が必要な特定のユースケースやシナリオについて、こちらからフィードバックをお寄せください。
API 使用量 多くの小数値のスケーリングの貢献に関する推奨事項のリクエスト。 さまざまな方法で YouTube チャンネル メンバーシップ プログラムの予算を調整し、ユースケースに最適な方法を見つけることをおすすめします。値が小さい場合のシナリオでは、さまざまな値でエプシロンをテストして、ユースケースでエプシロンからのノイズが許容される屈曲点を特定することをおすすめします。

詳細については、ARA の概要レポートの最適化 に関する Google の研究論文をご覧ください。
柔軟なイベントレベル 柔軟なイベントレベル（複数のトリガー仕様）はいつ実装されますか？ 現在、フレキシブル イベントレベルでは、ソースごとに生成できるレポートの数、レポート対象期間の数と期間、トリガーデータのカーディナリティの登録構成をカスタマイズできます。

現在、イベントレベルの柔軟な機能強化に関するエコシステムのフィードバックを収集していますが、現時点では実装する予定はありません。

こちらに記載されているイベントレベルの柔軟な機能強化のメリットが得られるユースケースについて、フィードバックをお寄せください。
バケット処理 バケットの集計貢献度の上限、将来の拡張性、下位互換性を検討するようリクエスト。 Google では現在、このリクエストについて検討中です。こちらから追加のフィードバックをお寄せください。
Epsilon ARA が一般提供に移行すると、イプシロン範囲はどうなりますか？ ARA は 2023 年第 3 四半期に Chrome で一般提供されました。現時点では、ε 値のウィンドウを変更する予定はありません。Google が提案するガバナンス構造の見直しにより、変更が予想される場合は、さらなる保証が得られます。
レポート Trigger-unknown-error レポートには、レポートの本文にソース属性は含まれません。 仕様に記載されているように、trigger-unknown-error のレポート本文に他のフィールドを含める必要はありません。レポート本文のフィールドを説明する表は、エラーの根本的な原因に応じて、ソース関連のフィールドが存在する場合と存在しない場合があるため、誤解を招く可能性があると認識しています。

たとえば、ソース照合ロジックが実行される前に内部エラーが発生すると、デバッグ レポートの入力に使用できるソースデータが存在しないことを意味します。

この点を明確にするため、ドキュメントを更新しました。
API 使用量 2 つの測定目標（カウントと値）を使用する場合は、貢献度予算とエプシロンの両方を分割することを示唆していますか？ 2 つの測定目標を使用する場合は、貢献度予算を 2 つの目標に分割することをおすすめします。
レポート ARA はマルチタッチ アトリビューション レポートまたはアシスト レポート（貢献度レポート）をサポートしていますか？ ARA は現在、マルチタッチ アトリビューションとアシストレポートには対応していません。現時点では、この機能を実装する予定はありません。

ユースケースとその優先度について、こちらからフィードバックをお寄せください。
API バグ ARA の場合、ドキュメントでは XOR を使用してソースとトリガーの集計キーピースを結合すると記載されていますが、実際には OR が使用されています。この不一致により、実装時に混乱やエラーが発生する可能性があります。 これがエラーであることを反映するようにドキュメントを更新しました。

集計サービス

フィードバック テーマ 概要 Chrome の対応
集計ジョブ 集計ジョブで複数のプレフィックスを許可するリクエスト。 Google はこのフィードバックを調査しており、こちらに提案を投稿しています。この提案に関するフィードバックは、こちらからお寄せください。
機能のリクエスト service_account_token_creator_list が設定されていない（または空である）場合、アカウントの IAM ポリシーの変更がスキップされるように terraform スクリプトを変更するようリクエスト。 Google では現在、こちらでこの問題を調査しており、エコシステムからのフィードバックをお待ちしております。
API 使用量 Terraform プランで常に変更が表示されることについて、明確にする必要があります。 この問題は AgS 2.8 リリースで修正されています。
API 使用量 柔軟な寄与度フィルタを使用して、広告主ごとの集計頻度を設定する際の推奨事項を探します。 現在、ARA では広告主ごとのバッチ処理が可能です。柔軟な貢献度フィルタリングは、広告テクノロジーがレポートの貢献度をさまざまな頻度でさらに細分化したい場合など、高度なケースに使用できます。

広告テクノロジーの一括処理について詳しくは、こちらを、ARA での ID のフィルタリングについてはこちらをご覧ください。また、身分証明書のフィルタリングに関するドキュメントも作成中です。
機能のリクエスト 集計サービス（AgS）での log_sum_exp のサポートをリクエストします。 ユースケースの詳細について、この関係者に連絡をとりました。詳細がわかり次第、お知らせいたします。
機能のリクエスト AgS に問題が発生したときや、デプロイされた AgS に問題が発生する可能性があるときに、より多くのログ、分析情報、その他の指標を表示できるようにリクエストします。 エラー、緩和策、説明を追加したドキュメントの更新版をこちらで公開しました。

文書化されていないエラー、指標、ログなど、記載されていないエラー、指標、ログなどがあれば、さらにフィードバックをお寄せください。どのような詳細情報が役立つかについては、 こちらをご覧ください。
API テスト テスト期間の終了後、イプシロンの最終的な値はどうなりますか。 現時点では、ε 値のウィンドウを変更する予定はありません。テスターの皆様には、さまざまなパラメータを試してフィードバックをお寄せください。
レポート レポートは生成されていますが、戻りコードで PRIVACY_budget_AUTHORIZATION_ERROR が引き続き表示されます。 このエラーを回避するために、正しいレポート送信元と集計可能なレポートを指定する方法に関するガイダンスを用意しています。

この問題について、特にエラーが繰り返し発生する場合は、追加のフィードバックをお寄せください。
キーの発見 キー検索の提案の計画 鍵検出プロポーザルのロールアウトのタイムラインはまだ決まっていませんが、こちらでプロポーザルに関するエコシステムからのフィードバックをお待ちしております。
カスタマイズ 集計サービスで利用できるカスタマイズ オプションを探しています。 Aggregation Service のカスタマイズは TEE 内では行えませんが、TEE 外の一部のコンポーネントでは可能です。これは、TEE 内で維持する必要があるプライバシーとセキュリティの基準によるものです。

現在、広告テクノロジーがアーキテクチャとカスタマイズ可能なコンポーネントを理解できるように、ドキュメントを更新しています。特定のカスタマイズはサポートできないため、可能な限り標準の設定を使用することをおすすめします。
スポット インスタンスとオンデマンド インスタンス システムは、スポット インスタンスとオンデマンド インスタンスのどちらを使用してテストされましたか？一時的に使用できなくなる可能性以外に、スポット インスタンスを使用する際の具体的なデメリットはありますか？ 広告テクノロジーにはオンデマンド インスタンスを使用することをおすすめします。そのため、スポット インスタンスでのテストを優先していません。スポット インスタンスの欠点は、予算の使用中にジョブが中断されることです。予算が消化され、広告テクノロジーが概要レポートを受け取る前にジョブが中断された場合、広告テクノロジーはジョブを再試行することはできず、予算の回復をリクエストする必要があります。予算の復元は、プライバシーを保護するために致命的な障害が発生した場合にのみおすすめします。

広告テクノロジーは、費用を最小限に抑えるために自動スケーリングを構成することをおすすめします。自動スケーリングに 0 を選択すると、ジョブがリクエストされるまで実行中のインスタンスはありません（リクエスト時にインスタンスが起動するため、レイテンシが増加する可能性があります）。
既知のエラーと解決策 集計サービス ジョブに「サービスエラー」と表示される件について、明確化が必要 この問題はこちらで解決済みです。

また、エラー メッセージを一部更新し、よりわかりやすくしました。たとえば、AWS では、以前よりも具体的な権限/認証エラーが内部エラーとして表示されていましたが、エラーがスローされるようになりました。

エラーコードと緩和策の手順に関するドキュメントをこちらで更新しました。ドキュメントに記載されていないエラーや、追加の詳細情報として役立つと思われるエラーについて、 こちらからフィードバックをお寄せください。

Private Aggregation API

フィードバック テーマ 概要 Chrome のレスポンス
キーのデザイン プライベート アグリゲーション鍵の設計ガイダンスのリクエスト プライベート アグリゲーションに特化したガイドはありませんが、集計サービスの負荷テスト フレームワークと高度な鍵管理ガイドの両方をリソースとして使用できます。
予算に対する割合 掛金の予算はどのレベルで計算され、制限されますか？ 貢献度予算は、ローリング 10 分間のウィンドウで 2^16、ローリング 24 時間間のウィンドウで 2^20 です。

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

ユーザー エージェントの情報量削減/ユーザー エージェント クライアント ヒント

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

IP 保護（旧 Gnatcatcher）

フィードバック テーマ 概要 Chrome の対応
Android IP 保護の Android への展開予定について教えてください。 Google は、IP 保護などの秘密追跡機能を Android に導入することを検討していますが、現時点でお知らせできる正式な予定はありません。
API 使用量 IP 保護に対する不正行為防止の例外があるか、今後あるかどうかに関する質問 Google は、IP アドレスに基づくウェブ上のユーザーの追跡を防ぎながら、不正行為防止のための IP アドレスの使用など、サーバーの通常の運用の中断を最小限に抑えるよう努めています。現時点では詳細をお伝えすることはできませんが、近日中に詳細をお知らせできる見込みです。引き続き検討してまいります。
不正な行為者の特定 悪意のある IP アドレスに対する従来のセキュリティ対策の有効性に関する懸念。 IP Protection は 1P リクエストをプロキシしないため、ほとんどの侵入検知システムは影響を受けないと考えられます。今後、シークレット ユーザーの不正行為防止とサイトの不具合に関する懸念事項に対処するための詳細情報を提供していく予定です。
IP アドレスのマスキング ニュース メディアのサイト（ファースト パーティ）が広告サイト（サードパーティ）と同じドメインを使用している場合、両方の IP アドレスがマスキングされますか？そうでない場合、両者を区別するにはどうすればよいですか？ IP 保護では現在、プロキシを通過するサードパーティのトラフィックを特定するリストベースのアプローチを提案しています。ただし、オリジンがこのリストに含まれている場合でも、1P コンテキストでアクセスされた場合はプロキシされません。最初に優先される特定のサードパーティ ドメインと、IP 保護のファースト パーティとサードパーティのコンテキストを正確に定義する方法について、現在詳細を確定しています。
IP アドレスのマスキング IP 保護と、不正行為防止システムへの影響に関する懸念。 ファースト パーティは Google の IP 保護計画の影響を受けないため、フォーラムなどのサイトは紛争解決のために IP アドレスにアクセスできるようにする必要があります。今後、広告の不正行為に関する懸念に対応するための追加情報を提供する予定です。
IP アドレスのマスキング 影響を受けるドメインのヘッダーで IP はマスクされていますか？ ユーザーは、現在の位置を表すプロキシ前の IP アドレスに基づいて、地理的エリアに割り当てられます。詳しくはこちらをご覧ください。

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

フィードバック テーマ 概要 Chrome の対応
API の仕様 タブが閉じられた際の Chrome による拡張ナビゲーションの処理動作について、明確化が必要です。 この問題はこちらで解決し、それに応じて仕様を更新しました。
ナビゲーション トラッキング クロスサイト リクエストのエントロピーを低減するために、有限のリンクセットを含むトラッキング緩和アプローチについて説明します。 Google は、こちらで他のブラウザ ベンダーとこのトピックについて引き続き議論しており、この問題に関する追加のフィードバックや具体的な提案をエコシステムからお待ちしております。

プライバシー バジェット

GitHub の説明とデベロッパー サイトに記載されているとおり、プライバシー バジェットはプライバシー サンドボックスの提案の一部として積極的に検討されていません。

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

フィードバック テーマ 概要 Chrome の対応
（前四半期にも報告）関連するウェブサイト セット（RWS）のドメイン数の上限 RWS 内の関連付けられたドメインの上限を引き上げるリクエスト 回答は前四半期と同様です。

現時点では、数値の上限を引き上げる予定はありません。この上限は、ユーザーのプライバシーに関する考慮事項、W3C のエコシステム ステークホルダーからのフィードバック、他のブラウザの類似実装の検討に基づいて設定されました。
詳しくは、ブログ投稿（1、2）をご覧ください。

数値制限を超えるクロスサイト Cookie アクセスを必要とするユースケースを検討し、ID のユースケース、認証済み埋め込み、広告のユースケースに関する Google のガイダンスを活用することをおすすめします。ユーザー セッションがログイン アクションに関連付けられている場合は、Federated Credentials Management（FedCM）API を使用して機能を維持することをおすすめします。

こちらから、必要と思われる他のユースケースについてフィードバックをお寄せください。
クロスサイト Cookie の処理 サブドメインで設定されたクロスサイト Cookie が、プライマリ ドメインからの後続のリクエストで渡されません。CORS と認証情報を適切に構成しても、問題が解決しません。 後続の取得リクエストでクロスサイト Cookie を送信するには、完全なオリジン（サブドメインを含む）を指定する必要のある requestStorageAccessFor API の正しい使用方法については、こちらをご覧ください。
ユーザーの選択 ユーザー選択のロールアウト後に RWS で使用される requestStorageAccessFor に関する詳細情報（特に、現在サードパーティ製の広告配信プラットフォームへのアクセスを許可している暗黙的または明示的なユーザー操作が、新しいシステムでどのように機能するか）のリクエスト。 ユーザー選択モードの場合（つまり、ユーザーが 3PC の保持または制限を選択した場合の）RWS の動作は、3PC を許可した場合と、RWS を有効にした 3PC をブロックした場合の Chrome の既存/配送動作と一致します（[関連サイトにグループ内のアクティビティの表示を許可する] 設定）。

requestStorageAccess を呼び出す前に、hasStorageAccess を呼び出して、パーティション分割されていないクロスサイト Cookie に埋め込みがすでにアクセスできるかどうかを確認することをおすすめします。ユーザーが 3PC を許可した場合、hasStorageAccess メソッドは true を返します。現在、3PC が許可されている場合、requestStorageAccessFor にユーザー操作は必要ありません。

このケースで適切な動作を議論し、明記するために、新しい GitHub の問題を作成しました。エコシステムからの追加のフィードバックをお待ちしております。
API 使用量 「商用」目的での RWS の使用に関して明確さが欠如しており、導入が妨げられていることへの懸念。ステークホルダーは、ターゲティング広告用にパブリケーションをグループ化することに関心を示しています。 RWS の目的は、サイトのコア機能とコア ユーザー ジャーニーをサポートすることです。ターゲット広告に関連するユースケースでは、専用の広告 API を使用することをおすすめします。
API 使用量 requestStorageAccess で localStorage データは設定できても Cookie は設定できない問題を報告します。 この問題は、SameSite 属性の誤字脱字が原因で発生しました。スペルが正しいことを確認し、3PC の場合は明示的に None に設定します。
API の仕様 リポジトリ全体の JSON スキーマの不一致（「contact」フィールドの配置ミスなど）や、改善案（一貫性を確保するための「oneOf」キーワードの使用など） Google はこのフィードバックを調査しており、近日中にスキーマの改善を検討する予定です。

その他のフィードバックがございましたら、こちらからお寄せください。
RWS へのサードパーティ（3P）によるアクセス ユーザーの同意を得たうえで、RWS API データにアクセスするサードパーティ ドメインをニュース メディアが指定できるようにします。 サードパーティが独自のパーティショニングされていないデータを RWS サイトデータと組み合わせることを許可すると、プライバシー サンドボックスのクロスサイト トラッキング保護が損なわれます。

ただし、Google は RWS にパーティション分割したデータをサードパーティが維持できるようにする可能性を検討しており、そのようなソリューションの設計についてのフィードバックを こちらで求めています。

Fenced Frames API

フィードバック テーマ 概要 Chrome のレスポンス
API に関する質問 ネットワークにアクセスできないフェンスド フレームによって、広告主のブランド保護と不正行為防止が損なわれる可能性があるという懸念。 Google は、フェンス付きフレームを適用する計画の一環として、この懸念を追跡しています。フェンス付きフレームの適用に対応したソリューションの検討をまもなく開始し、十分な提案が得られ次第、共有いたします。
API に関する質問 Fenced Frames API は引き続き 2026 年に予定されていますか？ 公式発表のとおり、フェンス付きフレームは 2026 年までに必須になります。
API バグ reportEvent() がクロスオリジン サブフレームからクリックデータを正常に送信すると、setReportEventDataForAutomaticBeacons() はトップフレームのデータを上書きしません。 Google はこの問題について現在調査中です。こちらから追加のフィードバックをお寄せください。

Shared Storage API

フィードバック テーマ 概要 Chrome のレスポンス
アプリ広告 Android 版プライバシー サンドボックスには、Shared Storage API と同等の API はありません。 Google は、ユースケースのニーズとプラットフォームの制約に基づいて、Android でのソリューションを評価しています。現時点でお伝えできる情報はございませんが、この問題についてエコシステムからさらにフィードバックをいただければ幸いです。
API 使用量 Shared Storage API を実装するために追加の JavaScript ワークレットの必要性に関する混乱。
 Google ではこのフィードバックを調査し、Share Storage API の追加のワークレット スクリプトの必要性を説明するドキュメントの更新を検討しています。
信頼できない Shared Storage API は、プライバシーに関する批判に基づいて大幅に変更されるか、廃止される可能性があるため、信頼できる基盤として使用できません。 共有ストレージ インフラストラクチャを大幅に変更または廃止する予定はありません。発表された主な変更点は、フェンス付きフレームが必須となり、イベントレベルのレポートが非推奨となる、Select URL 出力ゲートに関するものです。ただし、これらの変更は 2026 年以降に適用されます。

CHIPS

フィードバックのテーマ 概要 Chrome の対応
パーティション化された Cookie Chrome は Firefox とは異なり、フレームの祖先に基づいてパーティション キーを区別しないため、不整合が生じます。 Chrome では、セキュリティ上の懸念と Firefox の動作との不一致を解決するために「祖先チェーンビット」を採用しました。

この件について詳しくは、こちらをご覧ください。
パーティション化された Cookie ストレージ アクセスレベルが異なる埋め込み iframe は、同じパーティション分割 Cookie を共有して上書きするため、認証状態に不整合が生じます。 この構成では、Storage Access API の呼び出しでパーティショニングされていない Cookie を使用することをおすすめします。

この件については、こちらで詳しく説明しています。
パーティション化された Cookie サードパーティ Cookie が無効になると、パーティショニングされた Cookie ジャーは削除されますか？この動作をテストする方法はありますか？ 現時点では、お伝えできる情報はございません。ただし、デベロッパーは、Chrome DevTools の [Application] > [Cookies] パネルから、パーティション化された Cookie を手動で削除して、この機能をテストできます。

FedCM

フィードバック テーマ 概要 Chrome の対応
ID プロバイダ（IdP）登録スコープと組織選択ツール
 現在の同一オリジン ポリシーから同一サイト ポリシーへの IdP 登録の拡張に関する質問。この変更により、大学のウェルカム ページで、送信元固有の個別の登録を必要とせずに、複数のサブドメインベースの ID プロバイダを登録できるなど、より幅広く柔軟な ID 管理が可能になります。

デバッグ機能の改善、サイレント メディエーションの承認済みクライアントの処理、Cookie の動作の明確化、ポップアップの文言のカスタマイズ、タイムアウトの問題への対応に関するフィードバック。		 Google は、このフィードバックを認識しており、組織選択ツールを FedCM に組み込む方法を検討しています。

Google はこの手法の改良に引き続き取り組んでまいります。エコシステムからのフィードバックについては、 こちらからぜひお寄せください。
IdP Cookie Device Bound Session Credentials（DBSC）の提案の一環として、有効期間の短いセッション Cookie を実装した場合の影響について説明します。FedCM のユーザー エクスペリエンスに関する懸念が提起されています。期限切れの IdP クッキーを更新するには、ユーザーに表示されるモーダルが必要です。 提案されている DBSC では、ユーザー操作なしで Cookie を更新できるため、継続的なユーザー エクスペリエンスを実現できます。

この問題について詳しくは、こちらをご覧ください。
API の仕様 「providers」配列のサイズが 1 でない場合に、FedCM API 仕様で「NetworkError」を使用する妥当性に関する質問。 ネットワークの問題ではなくコーディング エラーを反映しているため、「TypeError」の方がこの状況に適しているというご意見に同意いたします。Google ではこの変更について検討し、マルチ IdP のサポートに向けた今後のアップデートでこの制限をなくす可能性を検討していきます。

追加のフィードバックはこちらからお寄せください。

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

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

フィードバック テーマ 概要 Chrome のレスポンス
サポート終了トライアルとモード B デプリケーション トライアル、モード B のテスト、プライベート ステート トークン（PST）の廃止の可能性、不正行為対策のユースケースに適した新しい API の可能性に関する懸念。 デプリケーション トライアルとモード B テストに変更はありません。最新情報はデベロッパー ブログでお知らせいたします。PST を廃止する予定はありません。GitHub で進行中の機能開発と更新について検討しています。

新しい API はまだ発表されていませんが、PST で不正防止のユースケースに適切に対処する方法について、ぜひフィードバックをお寄せください。
API に関するフィードバック 不正行為対策のユースケースに対応するため、トークンを無効にする機能をリクエストします。 カード発行会社は、使用するキーを変更することですべてのトークンを取り消すことができますが、個々のトークンを取り消すことはできません。これは、カード発行会社がトークンの発行と利用を関連付けることを許可する必要があるためです。この場合、2 つのイベント間の追跡を防止する PST プライバシー モデルが破綻します。