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

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

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 のレスポンス
データ ガバナンスと規制コンプライアンス 規制要件に準拠したプライバシー サンドボックスの使用に関するエコシステム ガイダンス。 他の新しいテクノロジーと同様に、プライバシー サンドボックスの使用が法律に準拠していることを確認する責任は各企業にあります。Google は、法律に関する助言を提供することはできません。ただし、これはエコシステムにとって重要な分野であることは認識しております。Google は、API ごとに広範な技術ドキュメントを公開しています。これらのドキュメントは、必要な法的評価を行うための基礎となるものです。また、規制要件への準拠に向けた企業の取り組みを支援する追加資料の公開にも取り組んでいます。
CMA 定量テストの提案書 CMA 定量テストの提案に関する詳細 Google は CMA と連携して、サードパーティ Cookie の廃止とプライバシー サンドボックスの提案がエコシステムに与える影響を把握するためのテストを設計しています。4 月に CMA は、テストとトライアル期間中に想定される内容に関する概要ガイダンスを公開し、6 月には詳細なガイダンスを公開しました。CMA の定量テストに関するご質問やご意見は、CMA に直接お寄せください。
Chrome 主導のテストモード テスト スケジュールの詳細と明確化 5 月 18 日に公開されたブログ投稿では、Chrome 主導のテストの 2 つのモードについて詳しく説明しています。これらの詳細は確定的なものではなく、2023 年第 3 四半期に進展するにつれて、実装に関するガイダンスをさらに公開する予定です。
パーティション化されたストレージ Chrome 主導のテストではパーティショニング ストレージが使用されますか？ ストレージ パーティショニングは、サードパーティ Cookie のサポート終了テストの前にすべてのユーザーにリリースされます。そのため、テストのすべてのアームで有効になります。この期間中、サイトはサポート終了トライアルを有効にして、パーティショニングされていないストレージを復元できます。
本番環境サポート Chrome では、エコシステムに影響するプライバシー サンドボックスの技術的な問題やエスカレーションをサポートするために、どのようなプロセスが設けられていますか？ Google は、広告テクノロジーが問題を報告し、必要なエスカレーションを行うためのさまざまなチャネルを提供しています。
フィードバックとエスカレーション用の公開フォーラムと限定公開フォーラムの詳細については、フィードバックの概要をご覧ください。
登録のタイムライン 現在の登録期間が短すぎる 違反措置の適用期限については現在検討中です。より適切なタイムラインについて、エコシステムの皆様からご意見をお聞かせください。
D-U-N-S ナンバー 登録と証明書発行における D-U-N-S ナンバーの要件の詳細 DUNS ナンバーの取得要件については、Dun & Bradstreet のウェブサイトをご覧ください。要件は市場によって異なるため、参加者は関心のある特定の市場のウェブサイトを必ず確認してください。ただし、一般的に、参加者はビジネスの名前、住所、ビジネス オーナーまたはマネージャーの連絡先情報など、ビジネスに関する基本情報を提供する必要があります。また、ビジネスの年間収益などの財務情報を提供するよう求められる場合があります。申請が完了すると、D&B が申請内容を確認し、申請が承認された場合は D-U-N-S ナンバーを発行します。
オリジン トライアルから一般提供への移行 オリジン トライアルから一般提供への移行は、現在のオリジン トライアルのテスターに影響しますか？ 7 月より、テスターは一般提供の関連性と測定の API にアクセスできるようになります。これにより、オリジンのトライアルの提供と一般提供が重複することになります。
AdExchanger の調査 調査方法の詳細 このアンケートでは、回答者にビジネスの同期率と収益を見積もるよう依頼しました。回答者は、個々の質問に回答する方法を選択できました。
パラメータの値 ノイズレベル、匿名性のしきい値、プライバシー バジェットなどのパラメータ値はどのように決定されますか？ こちらの GitHub の説明では、プライバシー サンドボックス API の背後にあるより一般的な原則について説明しています。多くの値はまだ確定されていません。この件に関するフィードバックをお待ちしております。

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

トピック

フィードバック テーマ 概要 Chrome のレスポンス
プライバシーの保護 プライバシー保護に関する Topics API の評価に関する研究 Google は研究コミュニティに積極的に参加し、論文、レポート、ワークショップのプレゼンテーションで Topics API のプライバシー特性に関する研究を発表しています。研究コミュニティの外部メンバーがこの分野に関心を寄せていることを嬉しく思います。

Topics API は、大規模なユーザー トラッキングを困難にすることで、ウェブ上の一般的なトラッキングからユーザーを保護します。これらの論文は、Topics API でこの目標を達成していることを示しています。サードパーティ Cookie よりもプライバシー保護のレベルが高く、ユーザーを保護しながら、ユーザーがよく訪れるサイトをサポートできます。
トピック タクソノミーの粒度が十分でない 広範なトピック分類には、地域固有のトピックなど、より詳細なトピックは含まれません。 エコシステムからの以前のフィードバックに応え、6 月 15 日にブログ投稿を公開し、エコシステムからのフィードバックに基づく多くの改善を盛り込んだ新しい分類について詳しく説明しました。分類の改訂作業の一環として、Google は Raptive（旧 CafeMedia）や Criteo など、エコシステム全体の複数の企業と連携してきました。更新された分類では、有用性が低いとの報告があったカテゴリを削除し、広告主様の関心により合致するカテゴリを追加しました。デリケートなトピックを除外するという Google の取り組みは継続されます。

エコシステムの皆様には、最新の分類をご覧いただき、変更点についてフィードバックをお寄せいただくことをおすすめします。
分類と分類システムの更新プロセス Topics 分類と分類システムのリリース頻度、および企業がこのような更新に備える方法について詳しくは、こちらをご覧ください。 先日のブログ投稿で説明したように、分類は時間の経過とともに進化し、最終的には業界全体の関係者を代表する外部関係者に分類のガバナンスが移行される予定です。また、topics-announce グループで段階的な導入計画も共有しました。
ファーストパーティ シグナルへの影響 最近の分類の更新でトピックの数が増えると、その価値が非常に高くなり、結果として他のファーストパーティのインタレスト ベースのシグナルの価値が低下する可能性があります。 2023 年第 1 四半期のレポートで、CMA は次のようにコメントしています。「Google は、提案された新しい分類について、広告テクノロジーのサプライ チェーン全体の複数の市場参加者と協議を重ねているようです。一部の大手パブリッシャーは、トピックの有用性が高まると、ファーストパーティ データ ベースのソリューションに対する競争圧力が高まると述べていますが、Google の予備的な見解では、有用性が高まることは、全体的な競争にとって、特にサードパーティ Cookie のサポート終了後も広告枠の収益化を継続できる小規模パブリッシャーにとって、より良いことだと考えています。」Google の見解は、CMA が行ったこのコメントと一致しています。
さまざまなステークホルダーにとっての有用性 SSP や DSP として機能する広告テクノロジーは、他のエコシステム プレーヤーよりも大きなメリットがある場合があります。 Google の回答は前四半期から変わっていません。

「Google は、Google 自身のビジネスを優遇して競争を歪めない方法でプライバシー サンドボックスの提案を設計し、実装し、デジタル広告の競争と、規模にかかわらずパブリッシャーと広告主に及ぼす影響を考慮することを CMA に約束しています。Google は、これらの取り組みが CMA の要請に準拠していることを確認するため、引き続き CMA と緊密に連携していきます。プライバシー サンドボックスのテストが進むにつれて、Google は、さまざまなタイプの関係者にとって新しい技術がどのように機能するかを評価する重要な質問の 1 つとして、この点において、フィードバックは非常に重要です。特に、技術的な設計のさらなる改善に役立つ、具体的で実用的なフィードバックは重要です。Google は CMA と協力して定量テストのアプローチを開発してきました。CMA がテスト設計に関するメモを公開し、市場参加者に詳細な情報を提供して提案されたアプローチについてコメントする機会を提供することを支持しています。」
子トピック トピックの選択基準がブラウザでのアクセス頻度である場合、セグメントの分散により、子トピックがトップに上がることはなくなるのでしょうか？ Chrome では現在、他のランキング手法の評価と、ランキングを改善する可能性のある他のシグナルの調査を行っています。改定された計画については、今後エコシステムに通知いたします。
機密性 Topics API の目標は、Topics API から取得または導出されるユーザー情報が、現在のトラッキング方法で導出される情報よりも個人的な機密性が低くなるようにすることです。 Google は、Topics API は現在の技術よりもプライバシー保護が大幅に強化されており、ユーザーの再識別を大幅に制限し、機密性の高いトピックを除外するように設計されていると考えています。トピックをファーストパーティ データと関連付けたり、組み合わせたりして、機密性の高いカテゴリを作成できることは認識しておりますが、Topics API はユーザーのプライバシー保護に向けた一歩であると信じており、API の継続的な改善に取り組んでいます。
分類構造 トピック分類に ID、バージョニング、その他のメタデータ構造を追加 現在、API レスポンスには分類 ID が含まれています。長期的なガバナンスに向けて、Topics オブジェクトを確認し、必要に応じてバージョニングに関する追加のメタデータを含めることをおすすめします。
パブリッシャーの管理設定 パブリッシャーは、サイトをどのトピックに分類するかを決定できます。 サイトの誤分類により、トピック シグナルの全体的な有用性が若干低下する可能性がありますが、誤分類された特定のサイトが他のサイトよりも損害を受けることはありません。これは、サイトのオークションではサイトのコンテキスト情報が常に利用可能であり、誤分類された場合でも、正しいトピックと同等の情報が提供されるためです。この件に関するフィードバックはこちらからお寄せください。

ニュース メディアが分類を管理できるようにすると、リスクが生じます。サイトが意図的にサイトを誤って分類し、すべてのユーザーの利便性を損なう可能性があります。また、あまり一般的でないトピックに機密情報をエンコードし、ユーザーのプライバシーを侵害する可能性があります。
Chrome 拡張機能 現在の Cookie 管理拡張機能と同様に、Chrome 拡張機能がトピックを管理、フィルタできるようにする これは、GitHub で説明されているように、すでに可能であるはずですが、エコシステムからの追加のフィードバックをお待ちしております。
一般提供への移行 オリジン トライアルから一般提供に移行する際に、Topics API に影響はありますか？ オリジン トライアルから一般提供に移行するユーザーのデータが失われることはありません。
プライバシー ホスト名には、Topics API によって公開される可能性のある個人情報が含まれている場合があります。 Google は、こちらに記載されているように、プライバシーを確保するためのさまざまな緩和策を講じています。
不正行為と不正使用 不正なアクセスによるトピックの操作を防ぐ方法 緩和策については、こちらをご覧ください。
トピック分類器 ウェブサイトはトピックの分類の変更をリクエストできますか？ このトピックについてエコシステムからのご意見をお待ちしております。フィードバックはこちらからお送りください。
トピック プロバイダのサイト 多くのトピックのコンテンツをホストする特定のウェブサイトを「特別なトピック プロバイダ サイト」として指定し、ウェブページに提供されているタグに基づいて分類システムをトレーニングします。 提案についてはこちらで議論しており、追加のフィードバックをお待ちしております。

Protected Audience API（旧 FLEDGE）

フィードバック テーマ 概要 Chrome のレスポンス
トラフィック シェーピング 秒間クエリ数（QPS）の負荷を最適化するための SSP ドリブンのフィルタリングによるパフォーマンスへの影響 Google はトラフィック シェーピングについてかなりの時間を費やしており、SSP にはキャッシュを利用することをおすすめしています。
テストボリューム SSP と DSP が大量のトラフィックを獲得できていないため、Protected Audience をテストするのが難しい。 Google は、Protected Audiences の導入とテストに向けて、SSP パートナーと DSP パートナーと常に連携しています。一般提供が開始され、Protected Audience が有効になっているトラフィックの割合が増加したことで、パートナーがテストを実施しやすくなったと考えています。
複雑さ Protected Audience ソリューションを実装するには、多大な労力と費用が必要です。 Google は、プライバシー サンドボックスなどの新しいテクノロジーの導入が難しいことを認識しています。プライバシー サンドボックス チームは、幅広い関係者と緊密に連携して、その取り組みを教育しサポートしています。また、エコシステムの導入をサポートする他の促進剤を継続的に評価しています。
高信頼実行環境 パブリック クラウド以外の環境での高信頼実行環境（TEE）のサポート Google では、クラウドベースのソリューション以外のオプションのサポートを検討していますが、オンプレミスのセキュリティ上の制限により、プライバシー サンドボックスの評価に時間がかかるため、現時点ではオンプレミス TEE をサポートすることは現実的ではありません。プライバシー サンドボックスのセキュリティ要件と、オンプレミス デプロイメントに伴う重大な課題を考慮すると、クラウドベースのデプロイメントの拡張と改善（AWS に加えて GCP のサポートなど）を継続することが、エコシステムにとって最も有益であると Google は考えています。ただし、このような要件が必要な理由について、追加のフィードバックをお待ちしております。
費用構造 入札とオークション サービスの提案では、クライアントサイド モデルと比較して、広告テクノロジーの費用と複雑さが増加します。 現在、入札とオークション サーバーで入札とオークションのワークフローをサポートする費用を見積もるためのガイドを作成しています。このガイドは、広告テクノロジーの使用状況と関連付けられ、設計の目標の 1 つを達成します。
k-匿名性タイムライン 予定されている k-匿名性制約は、renderUrl にいつ適用されますか？ 違反措置のタイムラインに関する説明を作成しており、近日中に公開する予定です。
runAdAuction の制限 Chrome で、runAdAuction をトップページからのみ呼び出せるように制限できますか？ Google の設計では、runAdAuction をトップページから呼び出せるように完全にサポートしていますが、トップドメインからのみ呼び出せるように制限することは、パブリッシャーにとって有害であると考えられます。

プライバシー サンドボックスは、パブリッシャーと広告主の負担を最小限に抑える必要があるという意見がエコシステムから寄せられています。このフィードバックは、サイト所有者がサイトの運営に第三者ツールを使用できるという、ウェブ開発の一般的な原則に沿っています。プライバシー サンドボックスの目標は、パブリッシャーと広告テクノロジーの運用方法を規定することなく、健全なエコシステムを促進することです。

パブリッシャーがサイト上で runAdAuction を呼び出す方法と呼び出し元を選択できるようにすることで、パブリッシャーが要件に最適なパスを見つけられるようにします。
実装サポート Chrome は、複数販売者オークションのオープンソース実装を構築または貢献できますか？ プライバシー サンドボックスは、サードパーティ Cookie やその他のクロスサイト ID に依存しないプライバシー保護技術を開発することを目的としています。Google は、広告テクノロジーの運用方法を規定することなく、健全なエコシステムの構築を促進したいと考えています。

API の仕組みに関するガイダンスを GitHub リポジトリで公開しています。また、業界と協力してソリューションを検討しています。

Google の中心的な役割は、プラットフォーム テクノロジーの構築であり、それらのテクノロジーを使用する戦略を定めることではありません。そのため、特定の実装を構築する予定はありません。Google のテクノロジーは、広告テクノロジー企業が消費者に適切なプライバシー保護ガイドラインを設け、顧客に最適なサービスを提供できるようにします。
マルチセラー オークション Chrome は「コンテキスト」に基づく落札結果をコンポーネント オークションと強制的に共有しますか？ Protected Audience API は、マルチ販売者オークションを開始する当事者がコンポーネント オークションに情報を渡せるように設計されています（注: オークションの開始前のみ）。

ただし、ブラウザが特定の情報がコンテキスト ウィナーであるかどうかを区別する方法はないため、特定の情報のブロックや必須化を強制することはできません。
同意トラッキングに関するユーザー設定 ユーザーの同意に基づくトラッキングを正しく実装する方法について PA に問い合わせる広告テクノロジー 回答には、質問 1 で述べた内容が含まれます。
「特定の広告については、表示されるクリエイティブやその選択方法を管理するうえで、関連する広告技術プロバイダが最適な立場にあります。」

5 月の WICG Protected Audience ミーティングで、この問題に関連する多くのシナリオについて議論しました。この問題に関するフィードバックや議論をお待ちしております。
カスタム オーディエンス カスタム オーディエンスの作成に関連する SSP のユースケースは、Protected Audience API でサポートされますか？ Protected Audience API を使用すると、SSP やその他の広告テクノロジー プロバイダがカスタム オーディエンスを所有して管理できます。SSP が PA API と統合する方法に関する詳細なガイダンスは現在開発中であり、SSP やその他の広告テクノロジー プロバイダが統合作業をサポートするために利用できるようになります。
フォーマット Protected Audience API は動画に対応していますか？ 動画広告は、VAST XML または HTML（最終的に動画プレーヤーに VAST XML を読み込む可能性のあるアウトストリーム広告）のいずれかの方法で配信されます。購入者は renderURL を使用してどちらの形式でも返すことができます。VAST 仕様は、Attribution Reporting API をサポートするために最近更新されました。動画広告を配信するサイトは、Protected Audience API を介した広告配信方法に備える必要があります。つまり、プレースメント タグが Protected Audience iframe から動画プレーヤーに URL を渡せるようにする必要があります。フェンス付きフレームについては、2026 年以降にフェンス付きフレームの使用が必須になる前に、動画のニーズに対応できるよう取り組んでまいります。
ペース ペーシングのユースケースは Protected Audience API とどのように連携しますか？ フィードバックをお寄せいただきありがとうございます。これまでは主に DSP の懸念事項でしたが、より多くの SSP パートナーから詳細なリクエストが寄せられるにつれて、Google もこの件に取り組んでいきたいと考えています。
更新頻度 dailyUpdate からの呼び出しの頻度（インタレスト グループごとに 1 日あたり最大 1 回）は、商品情報の更新など、特定のユースケースでは不十分な場合があります。 フィードバックをお寄せいただきありがとうございます。広告テクノロジーが異なる頻度で更新されるシグナルを使用できるようにする他のソリューション（K/V ルックアップなど）もあります。
広告品質管理 パブリッシャーは広告品質コントロールをどのように実装しますか？ 現在、Protected Audience API には、パブリッシャーがオークション設定の一部として、入札前に設定できる特定の管理設定（広告に関連付けられたラベルに基づく拒否リストなど）を SSP に通知する機能が用意されています。エコシステムに必要な追加機能について、フィードバックをお寄せください。
デバッグ forDebuggingOnly 機能はいつ削除されますか？ サードパーティ Cookie のサポート終了に伴い、損失イベントの forDebuggingOnly は廃止される予定です。勝利イベントの forDebuggingOnly は、早ければ 2026 年に廃止される予定です。
クロスデバイス インタレスト グループ 認証済みユーザー エージェントでクロスデバイスのインタレスト グループを有効にするための提案 Google ではこの提案を検討していますが、クロスデバイス ターゲティングの精度が高いため、こちらの GitHub の問題で説明されているように、プライバシーに関する重大な懸念が生じます。
（第 1 四半期にも報告）動的リマーケティング サードパーティ Cookie の廃止後も、Protected Audience API を使用して動的リマーケティングを実施できますか？ このユースケースは、こちらで説明している Protected Audience を使用して実現できると考えられます。
関連データをクリックする クリック関連のデータを browserSignals. に追加する 現在、クリックが発生した日時を明確にして、暫定的な掲載順位をお知らせするよう依頼しています。
（2022 年第 4 四半期にも報告）Protected Audience のユーザー定義関数 Protected Audience API ではユーザー定義関数（UDF）がどのようにサポートされますか？これらは、エンドユーザーがプログラムして API の機能を拡張できる関数です。 この問題を提起した広告テクノロジー企業は、UDF で何ができるかをまだ評価中であるため、少なくとも一般提供になるまでは、対応すべきフィードバックはないと述べています。
通貨 通貨金額は浮動小数点数で表さないでください。 この問題については、こちらで詳しく説明しています。
DSP 以外の広告選択機能 Protected Audience API オークションで広告サーバーが果たす役割 広告サーバーで入札後広告選択 / 動的クリエイティブ最適化サービスを継続して提供するようリクエストが寄せられていることを認識しております。現在、現在の Protected Audience API とこれらのリクエストの間に存在する詳細なギャップ分析を評価しています。
GenerateBid generateBid から広告インタレスト グループごとに複数の広告候補を返して、それらの候補を scoreAd でスコアリングする Google 広告の提案をサポート。 現在、この件について評価中です。追加のフィードバックはこちらからお寄せください。
オークション注文 Protected Audience API オークションは、他のすべてのオークションの結果から入力を取得できるように、最後に実行する必要がありますか？ Protected Audience API を最後に実行する技術的な要件はありません。
ユーザーが開始しないナビゲーション ユーザーが開始しないナビゲーションを公開する Google では現在、このリクエストを審査し、こちらで議論 しています。皆様からのフィードバックもお待ちしております。
キャッシュ ユーザーの状態が変化した場合、SSP はキャッシュから特定の DSP の perBuyerSignals を構築してはなりません。 キャッシュ保存が perBuyer シグナルのすべてのユースケースで機能するとは限らないことを認識しており、さらなるオプションを検討しています。キャッシュ保存がユースケースに適しているかどうかについて、エコシステムから追加のフィードバックをお寄せください。
アトリビューション レポートと Protected Audience Attribution Reporting API と Protected Audience API を連携させるにはどうすればよいですか？ 現在、Protected Audience API と Attribution Reporting API の両方のモード（イベントレベル レポートと概要レポート）で統合を利用できます。Protected Audience API と Attribution Reporting の統合の改善について、6 月 1 日に詳細をお知らせしました。詳しくは、こちらをご覧ください。
サーバー エンドポイント 最終的な設計では、サーバー エンドポイントが信頼できる集計サーバーになりますか？ サーバー エンドポイントは、収集および変換されたレポートの処理に使用される信頼できる集計サーバーとは独立した、広告テクノロジーが維持するエンドポイントです。現時点では、レポート エンドポイントに変更を加える予定はありません。現在の設計では、集計可能なレポート自体（暗号化されたペイロードを含む）がクロスサイト データを漏洩しないようにすることを目的としています。そのため、信頼できるエンドポイントは必要ありません。さらに複雑なのは、広告テクノロジーによって望ましいバッチ処理戦略が異なる可能性があることです。追加のフィードバックはこちらからお寄せください。
WebIDL 現在の Protected Audience API 仕様は、WebIDL 仕様に対応していません。 Google ではこのフィードバックを評価し、こちらの問題について議論しています。
同意の管理 Protected Audience API では、同意シグナルの受け渡しはどのように処理されますか？ コンテキスト情報は Protected Audience API の対象外です。Google は現在、この問題について協議しており、皆様からのフィードバックをお待ちしております。
アカウント ベースのマーケティング アカウントベースのマーケティングのユースケースは可能でしょうか？ Protected Audience API は、さまざまなオーディエンス ベースのマーケティングのユースケースをサポートしています。Google は、Protected Audience API がこの特定のユースケースを最適にサポートする方法を継続的に検討しており、この問題についてエコシステムから追加のフィードバックをお待ちしております。
コンポーネント オークション コンポーネント オークションの参加者はどのようなスコアを得ますか？ コンポーネント オークションでは、インタレスト グループを直接スコアリングするのではなく、DSP が generateBid 関数から送信した広告と入札単価をスコアリングします。generateBid() 関数はインタレスト グループごとに実行され、DSP は generateBid の実行時に
を返します。

return {
  'ad': adObject,
  'adCost': optionalAdCost,
  'bid': bidValue,
  'render': renderUrl,
  'adComponents':
    [adComponent1, adComponent2, ...],
  'allowComponentAuction': false,
  'modelingSignals': 123};
}

外部からの寄与 Key/Value Server GitHub コードベースでの外部コントリビューションをサポートするためのリクエスト。 Google は、GitHub コードへの外部からの貢献をサポートするために、関連するプロセスを更新する予定です。
インタレスト グループのサイズ IG でサポートされているキーの最大数はいくつですか？ 現在の上限は 1 つの IG のサイズが 50 KB で、キーはその一部としてカウントされます。サイズの上限に関するご意見をお待ちしております。
バッチ処理 K/V サーバー呼び出しの数を減らすにはどうすればよいですか？ HTTP Cache-Control ヘッダーを使用すると、K/V 呼び出しの数を減らすことができます。たとえば、コンポーネント オークション間でキャッシュに保存される場合や、1 つのページ上の広告スロット間でキャッシュに保存される場合があります。
バージョン管理 複数バージョンの広告テクノロジー コードのサポート 入札サービスとオークション サービスは、複数のバージョンの広告テクノロジー コードをサポートします。Bidding and Auction API では、SelectAd リクエストでオークション リクエスト（入札 / オークション、レポート）に使用するコードのバージョンを指定できます。
共有ストレージ 入札およびオークション サービスで共有ストレージへの書き込みをサポート。 現在、入札サービスとオークション サービスは共有ストレージをサポートしていません。このようなユースケースがエコシステムにとって重要な理由について、追加のフィードバックをお寄せください。
ウェブからアプリ 興味 / 関心グループのウェブからアプリへの共有をサポート。 現在、Chrome と Android の Protected Audience API のデプロイでは、ウェブからアプリへのリンクは対象外ですが、このユースケースの重要性についてエコシステムからのご意見をお待ちしています。
k-匿名性 k-匿名性の代替手段を処理する方法 現在、この問題について協議中です。ご意見やご感想をお寄せください。

デジタル広告の測定

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

フィードバック テーマ 概要 Chrome のレスポンス
代替の VTC イベントレベル レポートの構成 代替の VTC イベントレベル レポートの構成に関するフィードバック 現在のイベントレベルの設定が最適ではないというフィードバックが寄せられています。最適なグローバル設定について、フィードバックをお寄せください。この点について、さらにフィードバックをお寄せいただければ幸いです。柔軟なイベントレベルの説明も、この問題の解決に役立つと考えております。
柔軟なイベントレベルの設定 柔軟なイベントレベルの設定機能のステータス 柔軟なイベントレベルの設定に関するドキュメントを共有しました。この機能はまだ提案段階であり、この機能がエコシステムにとって有益かどうかについて、さらにフィードバックをお寄せください。
柔軟なイベントレベルの設定 異なる当事者からの矛盾する報告を調整するにはどうすればよいですか？ ほとんどのレポート シナリオは集計レポートを使用して対応できますが、柔軟なイベントレベルの構成プロポーザルは、イベントレベル レポートの柔軟性を高めるために提案されたものです。イベントレベル レポートは、最適化のユースケースでよく使用されます。このシナリオについて、エコシステムからのご意見やフィードバックをお待ちしております。
ソースの登録 トリガーの登録後にソースの登録が行われた場合 現在、ソースの登録がトリガーの登録後に行われると、ソースとトリガーは相互に関連付けることができません。これは特殊なケースのシナリオと思われます。この問題について、他にご不明な点やご意見がございましたら、お気軽にお問い合わせください。多くの広告テクノロジーが直面していると思われる問題については、解決に向けて取り組んでまいります。
複数の広告代理店との連携 広告主が複数の広告代理店を利用している場合、DSP は Attribution Reporting API をどのように使用できますか？ この API はリダイレクトをサポートしているため、広告主様が複数の広告代理店と連携している場合でも使用できます。また、API でプライバシーが確保されるように、リダイレクトにはいくつかの制限が設けられています。また、広告テクノロジーが報告した特定のシナリオに対して、Shared Storage API を利用した回避策も特定しました。このシナリオについて、他にご意見がありましたらお寄せください。いただいたフィードバックに基づいて、引き続き改善を続けてまいります。
宛先の制限 自動更新広告のユースケースは、リンク先数の上限の影響を受ける可能性があります。 この問題は 5 月 1 日の WICG ミーティングで議論され、妥当な上限についてフィードバックを求めています。イベントレベル レポートを使用した Attribution Reporting の説明に、ブラウザがソースサイトによって表される「デスティネーション」eTLD+1 の数を制限できることを追加しました。（pull リクエストを参照）。
アトリビューション レポートと Protected Audience Attribution Reporting API と Protected Audience API を連携させるにはどうすればよいですか？ 現在、Protected Audience API と Attribution Reporting API の両方のモード（イベントレベル レポートと概要レポート）で統合を利用できます。Protected Audience API と Attribution Reporting の統合の改善について、6 月 1 日に詳細をお知らせしました。詳しくは、こちらをご覧ください。
柔軟なイベントレベルの設定 パラメータを設定できるようになったため、ノイズ シミュレーションのベスト プラクティスを共有します。 GitHub でコードを共有しています。このコードを使用すると、テストする柔軟なイベントレベルの構成について、情報量の増加とノイズの影響を評価できます。このコードをテストしてフィードバックを共有してくださる方からのコメントをお待ちしております。
アプリとウェブをまたいだアトリビューション測定 アプリとウェブにわたるアトリビューション測定はいつ利用可能になりますか？ 5 月 9 日に、Attribution Reporting API を使用したアプリとウェブにわたるアトリビューション測定のテストを発表しました。関連性および測定の API は Chrome 115 で一般提供される予定ですが、クロスアプリおよびウェブ アトリビューション測定は、現在のところ Chrome 115 で一般提供される予定はありません。
コンバージョンの重複を排除する 独立した測定ソリューションを ARA と照合するにはどうすればよいですか？ 現在の標準的な方法と同様に、広告主様はサードパーティの独立した測定プロバイダと連携して、コンバージョン レポートの重複を排除します。イベントレベル レポートでコンバージョンの重複を除去する方法に関するリソースをご用意しています。
アトリビューション レポートのデータベースの更新中にデータが失われる 発表されたとおりに Chrome がアトリビューション レポート データベースを更新する際に、データが失われることはありますか？ Chrome Stable 115 以降、一部の Chrome ユーザーに対して Relevance API と Measurement API がデフォルトで有効になります。一般提供は、潜在的な問題をモニタリングしながら段階的に拡大していく予定です。目標は、2023 年第 3 四半期までに、数週間にわたって 100% の可用性を達成することです。これは、関連性と測定のオリジンの試験運用の終了と同時に行われます。7 月より、テスターはこれらの API の一般提供へのアクセスを登録できるようになります。これにより、登録を通じてオリジン トライアルの提供と一般提供が重複することになります。オリジン トライアル トークンは 9 月 19 日まで有効ですが、進行中のテストを中断することなくオリジン トライアルからシームレスに移行できるように、有効期限が切れる前に API に登録することをおすすめします。

こちらのお知らせに記載されているとおり、古いバージョン（M113 以前）から登録されたデータは更新後に移行されないため、データが失われる可能性があります。このデータ損失はデバッグ レポートには表示されません。また、114 から 115 への移行でデータ損失が発生しないように努めます。
課金 コンバージョン単価の請求でアトリビューション レポートを使用する こちらの記事で説明されているように、イベントレベル レポートと概要レポートにはノイズが付加されるため、Attribution Reporting API はコンバージョン単価の課金ニーズには適さない場合があります。エコシステムのプレーヤーの皆様は、Attribution Reporting API によるさまざまな課金モデルへの影響について、GitHub でフィードバックを共有することをおすすめします。

集計サービス

フィードバック テーマ 概要 Chrome のレスポンス
集計可能レポートの遅延の変更 エコシステムからのフィードバックを受けて、集計レポートの遅延を [10 ～ 60 分] から [0 ～ 10 分] に変更する提案に対する好意的な反応 提案された変更に対する好意的な反応をいただき、ありがとうございます。提案内容について、引き続きフィードバックをお寄せください。
オンプレミス ソリューション 集計サービスをオンプレミス データセンターにデプロイできますか？ Google では、クラウドベースのソリューション以外のオプションのサポートを検討していますが、オンプレミスのセキュリティ上の制限により、プライバシー サンドボックスの評価に時間がかかるため、現時点ではオンプレミス TEE をサポートすることは現実的ではありません。プライバシー サンドボックスのセキュリティ要件と、オンプレミス デプロイメントに伴う重大な課題を考慮すると、クラウドベースのデプロイメントの継続的な拡大と改善（AWS に加えて GCP のサポートなど）がエコシステムにとって最も有益であると Google は考えています。ただし、このような要件が必要な理由について、追加のフィードバックをお待ちしております。
別の期間のレポートを再処理する さまざまな期間のレポートを再処理する機能 さまざまな期間のバッチを分割できるようにするというリクエストも同様に寄せられています。1 つの提案は、共有 ID を広告テクノロジー定義のラベルで拡張できるようにし、レポートを異なるバッチに分割できるようにすることです。Google は現在、このプロセスの評価を初期段階に進めており、この提案が進展するにつれてエコシステムを更新していきます。
高信頼実行環境におけるプライバシーへの影響 高信頼実行環境のプライバシーへの影響に対する肯定的な感情 Google は、提案についてエコシステムから好意的な反応が寄せられたことをうれしく思います。今後も改善と開発を進めていくため、皆様からのフィードバックをお待ちしております。
利用規約 集約サービスの利用規約に同意する期限はいつですか？ 利用規約に同意する期限はまだ指定されていませんが、登録の遅延を防ぐため、エコシステム企業にはできるだけ早く利用規約に同意することをおすすめします。ご不明な点がございましたら、お気軽にお問い合わせください。
キーの検出 キー検出機能により、テスト担当者は、クロス ネットワーク アトリビューションの概要レポートを処理してパフォーマンスと精度を向上させるために、考えられるキーの組み合わせの明示的なリストを必要とせずに、集計レポートをクエリできるようになります。 現在、考えられる解決策と回避策を調査中です。エコシステムからのフィードバックもお待ちしております。

Private Aggregation API

フィードバック テーマ 概要 Chrome のレスポンス
報告元 報告元はどのように定義されますか？ レポート送信元は、常に非公開集計呼び出し元のスクリプト送信元です。
128 ビットのキースペース 128 ビットのキースペースの制限について明確に このキースペースの制限を明確にし、ページ間の不整合を解消します。このキースペース内に収まるようにハッシュ戦略を使用することをおすすめします。
レポートあたりの最大貢献度 現在の制限であるレポートあたり 20 件のコントリビューションは低すぎます。 寄付の最大数を増やすのではなく、上限で切り捨てるのではなくレポートを分割することを検討しています。この提案が進展するにつれて、エコシステムを巻き込んでいきます。
リーチレポート クロス プラットフォーム/クロスデバイス リーチ レポートのリクエスト。リーチはブランド広告の基本的な指標です。広告主は、リーチとフリークエンシーのレポートでクロスプラットフォーム/クロスデバイスの推定値を使用して、キャンペーンを分析し、費用を割り当てています。リーチモデルは、サードパーティ環境で表示される広告を測定するためのシグナルとしてサードパーティ Cookie を使用しているため、広告テクノロジー プロバイダは、サードパーティ Cookie が廃止された後の代替ソリューションをリクエストしてきました。
 プライバシー サンドボックス チームは、サードパーティ Cookie のサポート終了後にクロスドメイン リーチ手法をサポートする機能を検討しています。
エコシステムからのフィードバックをお待ちしております。

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

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

フィードバック テーマ 概要 Chrome のレスポンス
（2023 年第 1 四半期にも報告）その他のフォーム ファクタに関するヒント TV、VR などの追加のフォーム ファクタを提供するための User-Agent Client Hints（UA-CH）のリクエスト Google では、まだいくつかの重要な設計上の決定（「TV」などの単一の値を提供するか、フォーム ファクタの機能のリストを提供するかを決定）に取り組んでいますが、このアイデアの試作には引き続き関心を寄せています。
プライバシー バジェット プライバシー バジェットの制限により、リクエストが多すぎると UA-CH リクエストが非決定的になる可能性があります。 現時点では、プライバシー バジェットの提案について新しい情報はありませんが、サードパーティ Cookie が廃止される前に UA クライアント ヒントのリクエストを制限しないことを約束しています。
サイトの互換性 ウェブサイトが UA-CH ブランドを使用して、特定のブラウザによるサイトへのアクセスを制限している。 ブランドリストには有効なユースケースがあり、その 1 つが互換性です。こうした問題を回避するために、UA は複数のブランドを自由に設定できます。

IP 保護（旧 Gnatcatcher）

フィードバック テーマ 概要 Chrome のレスポンス
不正行為と不正使用 IP 保護で不正行為対策を設定するにはどうすればよいですか？ Google は、不正行為防止のユースケースの重要性と、それらのユースケースに及ぼす可能性のある影響を理解しています。不正行為防止のサポートの詳細については、夏の後半にお知らせする予定です。不正行為防止のユースケースをより適切にサポートする方法を検討するにあたり、エコシステムからのフィードバックをお待ちしています。
GeoIP GeoIP のテストとデプロイのタイムラインの詳細 Chrome では最近、GeoIP に関する計画の最新情報を公開しました。デプロイのタイムラインについては、第 3 四半期に詳細を発表する予定です。IP 保護は、まず少数のトラフィックに対してユーザーが有効にする機能としてリリースされる予定です。この提案は企業にとって大きな変更を伴う可能性があるため、この機能をより広範囲に展開する前に、エコシステムが調整とフィードバックの提供を行う時間を確保したいと考えています。
アカウント認証 プロキシ サーバーによるアカウント認証の仕組み アカウント認証の詳細については、夏の後半に公開する予定です。最初の考慮事項についてはすでにお知らせしています。

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

フィードバック テーマ 概要 Chrome のレスポンス
テストのガイダンス バウンス トラッキング対策をテストする方法に関する情報 5 月に公開された ブログ投稿では、バウンス トラッキング緩和策をテストする方法について詳しく説明しています。
ドキュメント バウンス トラッキングに関する提案の明確さ 現在の提案は、まだ開発段階にあり、Chrome はエコシステムに明確な情報を提供し、提案を継続的に更新しています。詳細については現在調査中です。ご意見、ご感想をお寄せください。
Cookie の削除 バウンス トラッキング対策により、ドメイン内のすべての Cookie が削除されますか？ バウンス トラッキング緩和（BTM）では、こちらで説明されているように、すべてのストレージとキャッシュが削除されます。
バウンス トラッキング対策の回避 ポップアップや新しいタブでリダイレクトを実行すると、バウンス トラッカーの分類がバイパスされる可能性があります。 バウンス トラッキングの抑制の仕様は現在も開発中です。これまでは、同じタブへのリダイレクトに主に重点を置いてきましたが、今後はポップアップ フローに取り組む予定です。追加のフィードバックはこちらからお寄せください。

プライバシー バジェット

フィードバック テーマ 概要 Chrome のレスポンス
近接ターゲット プライバシー バジェットは、近接ターゲティングのユースケースに影響する可能性があります。 この問題についてフィードバックをいただいております。エコシステムへの潜在的な影響について、詳しくお聞かせいただければ幸いです。

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

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

フィードバック テーマ 概要 Chrome のレスポンス
（前四半期にも報告）ドメインの上限 関連付けられたドメイン数の増加をリクエストする Chrome では、特定されたユースケースのプライバシーと有用性のバランスを考慮して、関連するサブセットに適切な数値の上限を評価しています。当初から、関連するサブセットの正確な数は未確定であると Chrome は説明してきました。
埋め込みのユースケース ファーストパーティ セット、CHIP、共有ストレージを必要とする埋め込みユースケースのサポート Chrome ではこのユースケースに関するフィードバックを受け取りました。担当チームが調査を進めております。追加のフィードバックもお待ちしております。
リポジトリ管理 不一致や怠慢がある場合に GitHub リポジトリからファーストパーティ セットを削除するポリシーに関する情報 Chrome では、このユースケースに関するフィードバックを受け取りました。担当チームが調査を進めております。追加のフィードバックをお寄せください。
ユーザーへの説明 Chrome は、ファーストパーティ セットの認知度と理解度を高めて、導入を促進する必要があります。 Chrome は、ファーストパーティ セットについてユーザーに説明することに取り組んでおり、この点について ヘルプセンター記事（Chrome UI からリンク）を公開しています。また、Chrome では、適切なコンテキストでユーザーに最適な方法で教育する方法を継続的に学習しています。
3PCD 以降 サードパーティ Cookie のサポート終了後も、サードパーティ Cookie はファースト パーティ セット内に引き続き存在します。 requestStorageAccess と requestStorageAccessFor により、明確に定義された特定のユースケースでサードパーティ Cookie を再度使用できるようになりますが、（Chrome における）サードパーティ Cookie の現在の状態と同様に、デフォルトで使用できるのではなく、サイトによるアクティブな呼び出しが必要になります。

1 つのセット内での呼び出しにはユーザーの承認は必要ありませんが、ユーザーは設定でこの動作をオプトアウトすることで、この呼び出しを防ぐことができます。

詳しくは、ヘルプセンター記事（Chrome UI からリンク）をご覧ください。FPS が 100% に引き上げられるにあたり、既存のデベロッパー ガイドを拡張する予定です。
ファーストパーティ セットの送信 必要な .well-known/first-party-set の名前を変更して、拡張子を .json にします。 この変更は、特定のウェブ ホスティング プランがサポートされるようにするために行いました。
IANA 登録 first_party_sets.JSON は IANA に登録されている必要があります。 提案を検討しております。追加のフィードバックはこちらからお寄せください。

Fenced Frames API

フィードバック テーマ 概要 Chrome のレスポンス
広告ブロック フェンスド フレームを使用すると、広告ブロッカーによる広告のブロックが容易になる可能性があります。 拡張機能は、iframe と同様にフェンス付きフレームとやり取りできます。フェンスされたフレームが移動しようとしている実際の URL も拡張機能に表示されるため、iframe の場合と同様に、ブロック用の URL 照合ルールを適用できます。すべてのフェンス付きフレームを無条件にブロックすると、フェンス付きフレームの広告以外のユースケースが破損する可能性があります。

Shared Storage API

フィードバック テーマ 概要 Chrome のレスポンス
より広範な導入 共有ストレージは、ブラウザ間で利用できる業界標準である必要があります。 いただいたフィードバックは、今後の参考にさせていただきます。Chrome は、提案を推進し、フィードバックを募集し、採用を促進するために、W3C フォーラムに引き続き積極的に参加し、
出力ゲート 共有ストレージの出力ゲート機能が制限されています。 Google は、このフィードバックについて検討しており、出力ゲート機能が制限されている理由について、エコシステムからの追加のフィードバックをお待ちしております。
規制遵守 共有ストレージは、データ保持ポリシーなどの規制遵守をどのように処理しますか？ 共有ストレージを使用すると、保存されたデータの存続期間と有効期限を制御するロジックを柔軟に実装してカスタマイズできます。広告テクノロジーは、書き込みタイムスタンプに基づいて共有ストレージ データを更新または消去できます。
A/B テスト Shared Storage API と Protected Audience API の A/B テストを実施するにはどうすればよいですか？ YouTube は現在、この問題に関する追加のガイダンスを公開する準備を進めており、今後詳細をお知らせいたします。
共有ストレージの上限 共有ストレージの上限に達した場合 上限に達すると、それ以上の入力は保存されなくなります。
同じページ読み込みでの複数回のアクセス 同じページの読み込みで共有ストレージに複数回アクセスするとどうなりますか？ これを処理する最善の方法は、window.sharedStorage.append(key, value) 関数を使用することです。広告ごとに値を更新すると、複数の広告がある場合に競合が発生する可能性があります。append 関数は、既存の値の末尾に新しい値を追加するだけです。
iframe の機能 サードパーティ Cookie のサポート終了後に動作しなくなる特定の iframe 機能を、共有ストレージがサポートするようになりますか？ サードパーティ Cookie のサポート終了後、iframe 内のローカル ストレージはトップレベル サイトによってパーティショニングされますが、iframe 自体はブロックされません。iframe のローカル ストレージ内のデータは複数のトップレベル サイトに複製できませんが、iframe 内でローカル ストレージを使用できます。

CHIPs

フィードバック テーマ 概要 Chrome のレスポンス
パーティションの上限 パーティション分割されたサイトごとに 10 KiB は依然として大きいため、この値を下げたいと考えています。 Firefox はすでに CHIPS について 肯定的な立場を示しています。Webkit のサポートについては、パーティショニングされたストレージよりもパーティショニングされた Cookie が優先されるユースケースについて、 こちらの GitHub の問題で直接 Apple にフィードバックを送信することをおすすめします。
認証済みの埋め込み CHIP は、認証された埋め込みに影響するパーティショニングが異なるため、現在の SSO ログインフローにも影響する可能性があります。 Google は、Storage Access API（ユーザー プロンプトあり）を活用して、認証済みの埋め込みのユースケースをサポートする予定です。最近、 プロトタイプ作成の意向を送信しました。
生涯保証ポリシー 有効期間のポリシーはファーストパーティ Cookie に適用されますか？ 現在のところ、ファーストパーティ Cookie に有効期間の制限を適用する予定はありません。

FedCM

フィードバック テーマ 概要 Chrome のレスポンス
OAuth 認可のサポート プロファイル以外の OAuth スコープの承認を調整する Google は、サードパーティ Cookie のサポート終了後に基本認証以外の認可をサポートする最善の方法について、W3C FedID CG を通じて Web Identity コミュニティからの意見を積極的に求めています。
SAML のサポート SAML サポートの要件を調整する サードパーティ Cookie のサポート終了後、Google は（OpenID Connect のサポートに加えて）SAML のサポートニーズについて、研究コミュニティと教育コミュニティから積極的に意見を求めています。

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

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

フィードバック テーマ 概要 Chrome のレスポンス
新しいシグナルの探索 デバイスの完全性やユーザーの信頼に関するブラウザによるシグナルの検討について、複数のパートナーから肯定的な意見が寄せられています。通常、新しい専用シグナルが、現在のレベルの不正行為検出を維持するのに十分かどうかについても慎重です。 Google は、不正行為対策とウェブの安全性に関するコミュニティと協力して新しい提案を検討し、懸念事項を認識し、共有することを楽しみにしています。これがまさに、「スパムと不正行為の防止」がプライバシー サンドボックスのコア ワークストリームである理由であり、ユーザーのプライバシーを改善しながらウェブの安全性を維持するための投資を継続的に優先する理由です。
PST に関する好意的なフィードバック 複数のパートナーが、さまざまな不正行為防止やウェブ安全性に関するユースケースで PST をテストまたは利用する関心を示しています。 PST を活用した新しいソリューションのさらなる検討にご関心をお寄せいただき、ありがとうございます。Chrome デベロッパー サイトでは、リソースとサンプルコードをご利用いただけます。また、フィードバックもお待ちしております。
不正行為と不正使用 サードパーティ Cookie の廃止後、識別子を使用できなくなった場合の測定における広告不正の防止 / 検出に関するガイダンス。 Google は、不正行為防止のためにサードパーティ Cookie によって失われたシグナルの一部を回復し、新しいプライバシー管理を適用できるプライベート ステート トークンなどのツールを導入しました。Google は、プライバシー サンドボックスの他の変更と連携して機能性を維持するため、新しい不正行為防止と不正使用防止の提案に積極的に投資しています。
カード発行会社から送信元への情報レート カード発行会社から送信元への情報の比率が、一意のユーザーを特定できるほど高い。 プライベート ステート トークンを使用して伝送できるユーザーデータを明確にするため、仕様を更新しました。設計上、一度に使用できる公開鍵は 6 つまでで、これは特定のユーザーの「状態」を表す場合があります。これらの鍵セットは、緊急の鍵のローテーションが必要なまれなケースを除き、60 日ごとにしか更新できないため、時間の経過とともに追加のユーザーデータを結合する速度が遅くなります。新しいウェブ API には、提供されるユーティリティと提供される新しいユーザー情報のバランスがあります。Google は、PST がサードパーティ Cookie のサポート終了の影響を受ける主要な不正行為防止ユースケースを可能にしながら、ユーザーのプライバシーを保護するうえで適切なバランスを実現すると見込んでいます。
統合の取得 fetch の統合は複雑で不要です。 fetch の使用には賛否両論があり、Google はウェブ エコシステム内での標準化をさらに進めたいと考えていますが、標準の詳細が明確になるまでは、この変更を行うには時期尚早であると考えています。標準が確立された場合は、ウェブ デベロッパーをその標準に責任を持って移行させることにも取り組んでいます。
保存場所 プライベート ステート トークンの鍵構成は、PrivacyPass プロトコルと同じ場所に保存する必要があります。 オリジン トライアルのテスト中、デベロッパーは、.well-known ディレクトリではなく一般的な URL にキーを保存する柔軟性を好むと回答しました。PrivacyPass の鍵コミットメント形式は、鍵セットで暗黙的な「公開メタデータ」値を許可することを目的としているバージョンには特に適していません。PrivacyPass のバリエーションが公開メタデータ（POPRF、部分的な RSA ブラインド、キーセット）で標準化された場合は、それをサポートするために今後のバージョンの PST に移行する可能性があります。
API のヘッダー実装 API のヘッダー実装に関する質問 API が標準化され、この API のエコシステムの使用が成熟するにつれて、この API の標準ヘッダー以外のバージョンの両方をサポートし、使用頻度が低い場合や、発行/利用リクエストと他のデータを標準的な方法で関連付けるための十分なデベロッパー ツール/サポートがある場合は、ヘッダー バージョンを非推奨にすることを検討しています。この問題についてはこちらで議論しています。
登録 カード発行会社にブラウザ ベンダーへの登録を義務付けることは現実的ですか？ Private State Tokens の発行元登録プロセスを説明するように仕様を更新しました。独自のプロセスを使用しますが、プライバシー サンドボックスの他の作業の登録プランと同様です。カード発行会社には、PST の使用方法について公開声明を発表し、ユーザーのプライバシーを保護する技術的な制限を認識するよう求めます。