このページは Cloud Translation API によって翻訳されました。

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

2023 年第 2 四半期の四半期レポート。プライバシーサンドボックスの提案と 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 レスポンス
データガバナンスと規制コンプライアンス	規制要件を遵守したプライバシーサンドボックスの使用に関するエコシステムガイダンス。	すべての新しい技術と同様に、各企業はプライバシーサンドボックスの使用において法律を遵守する責任を負い、Google が他者に法的な助言を行うことはできかねます。しかし、このエコシステムにとっても重要な課題であることも認識しています。Google は各 API について、必要な法的評価を行う根拠となる広範な技術ドキュメントを公開しています。また、規制要件を遵守する企業の取り組みを支援する追加資料の提供にも取り組んでいます。
CMA 定量的テストの提案	CMA の定量的テストの提案に関する詳細	Google は CMA と協力して、サードパーティ Cookie の廃止による影響の全体像を示すテストを設計し、プライバシーサンドボックスの提案をエコシステムに導入しています。CMA は 4 月に、テスト期間とトライアル期間中の見通しに関する大まかなガイダンスを公開し、6 月には詳細なガイダンスを公開しました。CMA の定量的テストの提案に関する質問やフィードバックは、CMA に直接共有することをおすすめします。
Chrome で利用できるテストモード	テストスケジュールに関する詳細情報と明確化	Google は 5 月 18 日にブログ投稿を公開し、Chrome が提供する 2 つのテストモードに関する詳細情報を公開しました。これらの詳細情報は最終的なものではなく、2023 年第 3 四半期の進捗に応じてさらなる実装ガイダンスを公開する予定です。
パーティション化されたストレージ	Chrome を活用したテストでパーティションストレージを使用する予定はありますか？	ストレージパーティショニングは、サードパーティ Cookie のサポート終了テストに先立って、すべてのユーザーにリリースされる予定です。そのため、テストのすべてのテスト群で有効になります。この期間中に、パーティション分割されていないストレージを取り戻すために、非推奨トライアルを有効にすることもできます。
本番環境サポート	Chrome では、エコシステムに影響するプライバシーサンドボックスの技術的な問題とエスカレーションに対応するために、どのようなプロセスが導入されていますか？	Google は、広告テクノロジーが問題を報告し、必要なエスカレーションを可能にするさまざまなチャネルを用意しています。フィードバックとエスカレーションに関する公開フォーラムと非公開フォーラムについて詳しくは、デベロッパー向けの投稿をご覧ください。
登録スケジュール	現在の登録期間が短すぎます	適用期限はまだ検討中です。適切な期限について、エコシステムの声をお聞かせください。
D-U-N-S ナンバー	登録と認証に必要な D-U-N-S ナンバーの要件の詳細	D-U-N-S ナンバーを取得するための要件は、Dun and Bradstreet のウェブサイトで確認できます。要件は市場によって異なるため、参加者は興味がある特定の市場のウェブサイトを必ず確認する必要があります。ただし、参加者は通常、ビジネスに関する基本情報（ビジネスの名前、住所、ビジネスオーナーまたはマネージャーの連絡先情報など）を提供する必要があります。また、ビジネスの年間収益などの財務情報の提供を求められる場合もあります。申請が完了すると、D&B が審査を行い、申請が承認された場合は D-U-N-S 番号を発行します。
オリジントライアルから一般提供への移行	オリジントライアルから一般提供への移行は、現在のオリジントライアルテスターに影響しますか？	7 月より、テスターは一般提供の関連性と測定に関する API にアクセスできるようになります。これにより、オリジントライアルの可用性と一般提供が重複します。
AdExchanger の調査	調査手法の詳細	この調査では、回答者に自社のビジネスの同期率と収益を見積もるよう求めました。質問に対して個別に回答する方法は、回答者に委ねられていました。
パラメータの値	ノイズレベル、匿名性のしきい値、プライバシーバジェットなどのパラメータ値はどのように決定されますか？	この GitHub の説明では、プライバシーサンドボックス API の背後にある、より一般的な原則を説明しています。多くの値は現在確定中ですが、このトピックに関するフィードバックをお待ちしております。

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

トピック

フィードバックのテーマ	概要	Chrome レスポンス
プライバシー保護	プライバシー保護に関する Topics API の評価に関する調査	Google は研究コミュニティと積極的に関わり、Topics API のプライバシー特性に関する研究を論文、レポート、ワークショップのプレゼンテーションで発表しています。より多くの外部メンバーがこの分野に関わっていることを嬉しく思います。 Topics API は、ユーザーの大規模なトラッキングを非常に困難にすることで、ウェブ上での一般的なトラッキングからユーザーを保護します。これらのホワイトペーパーは、Topics API を使用して適切に処理していることを示しています。サードパーティ Cookie よりもプライバシーが厳格で、ユーザーを保護するだけでなく、ユーザーが利用するサイトをサポートします。
Topics の分類が細分化されていない	広範なトピック分類には、地域特有の分類など、より細かいトピックは含まれていません。	エコシステムから寄せられた以前のフィードバックにお応えして、6 月 15 日にブログ投稿を公開しました。このブログ投稿では、エコシステムからのフィードバックに基づいて多数の改善を取り入れた、分類の更新について詳しく説明しました。分類を改訂する取り組みの一環として、Google はエコシステムに含まれる Raptive（旧 CafeMedia）や Criteo など複数の企業と提携しました。新しい分類では、有用性が低いカテゴリが削除され、広告主の興味により適したカテゴリが優先されます。また、デリケートなトピックを除外するという Google の取り組みは継続されます。エコシステムにおいては、最新の分類を確認し、変更に関するフィードバックを提供するようお願いしております。
分類と分類器の更新プロセス	Topics の分類と分類器のリリース頻度、および企業がそのような更新に備える方法について詳しくは、	最新のブログ投稿でお知らせしたとおり、分類は時間の経過とともに進化し、最終的には業界全体の関係者を代表する外部関係者に移行されることが見込まれます。topics-announce グループでも、拡大計画を共有しました。
自社シグナルへの影響	最新の分類の更新でトピック数が増加したことで、他のファーストパーティのインタレストベースシグナルの価値が損なわれる可能性があります。	2023 年第 1 四半期のレポートで CMA は次のように述べています。「Google は、広告テクノロジーサプライチェーンの複数の市場参加者と、提案される新しい分類法について議論してきたことを理解しています。トピックの有用性が増すと、自社データに基づくソリューションに対する競争圧力が高まるだろうと一部の大手パブリッシャーが言っていますが、暫定的な見解としては、有用性が高いほど競争全体にとっては優れており、特に、サードパーティ Cookie の廃止後も広告枠を収益化し続けることができるのが現状です。」私たちの見解は、CMA が行ったこのコメントと一致しています。
さまざまなタイプの関係者にとっての有用性	SSP や DSP として機能する広告テクノロジーには、他のエコシステム企業よりも大きなメリットがある。	対応はこれまでの四半期と変わりません。「Google は、プライバシーサンドボックスの提案を、Google 自身のビジネスを自己評価することで競争をゆがさないように設計し、実装することを CMA に約束しました。また、規模に関係なく、デジタル広告やパブリッシャーや広告主に対する競合への影響を考慮しています。Google は引き続き CMA と緊密に連携して、Google の取り組みがこれらのコミットメントを遵守するようにしています。プライバシーサンドボックスのテストが進むにつれ、Google が評価する主な質問の一つは、新しいテクノロジーがさまざまなタイプの関係者に対してどのように機能するかということです。この点においてフィードバックは重要です。特に、技術設計のさらなる改善に役立つ具体的で実用的なフィードバックは重要です。私たちは CMA と協力して定量テストに対するアプローチを開発してきました。また、市場参加者により多くの情報を提供し、提案されたアプローチについてコメントする機会を提供するために、CMA がテスト設計に関する注記を発表するのを支持しています。」
子孫トピック	トピックの選択基準をブラウザへのアクセス頻度とした場合、セグメントの断片化によって子孫トピックが上位に表示されることはありませんか？	Chrome では現在、他のランキング方式を検討しており、ランキングを改善する可能性のある他のシグナルを調査しています。改訂後の計画は、いずれはエコシステムにお伝えします。
機密性	Topics API の目標は、Topics API によって取得または導出されるユーザー情報が、現在のトラッキング方法で得られるものよりも、個人情報の機密性が低いようにすることです。	Topics API は、現在のテクノロジーよりもはるかにプライバシーに配慮しており、ユーザーの再識別が大幅に制限されており、デリケートなトピックを除外するように設計されています。Google は、トピックを自社データと関連付けたり組み合わせたりすることで、デリケートなカテゴリが作成される可能性があることを認識しています。Topics API はユーザーのプライバシーに対する一歩であり、今後もこの API の改善に取り組んでまいります。
分類構造	トピックの分類に ID、バージョニング、その他のメタデータ構造を追加する	現在、API レスポンスには分類 ID が含まれています。長期的なガバナンスに向けて、Topics オブジェクトを確認し、必要に応じてバージョニングに関する追加のメタデータを含めることは理にかなっています。
パブリッシャーの管理設定	パブリッシャー様は、サイトをどのようなトピックに分類するかについて決定を下す必要があります。	サイトが誤って分類されると、Topics シグナルの有用性が全体的に低下する可能性がありますが、分類ミスによって他のサイトに比べて害が軽減されることもありません。これは、サイトのコンテキスト情報がサイト上のオークションで常に利用可能であるため、誤った分類があっても、適切なトピックと比較可能な情報を提供できるからです。このトピックに関するフィードバックをお待ちしております。パブリッシャーが分類を管理できるようにすることにはリスクが伴います。サイトが意図的にサイトを誤って分類して、すべてのユーザーに対して有用性を低下させたり、あまり一般的でないトピックにデリケートな意味をエンコードして、ユーザーのプライバシーを損なったりする可能性があります。
Chrome 拡張機能	現在の Cookie 管理拡張機能と同様に、Chrome 拡張機能でトピックの管理とフィルタを行えるようにする	これは GitHub で説明しているように、すでに可能になっているはずですが、エコシステムからのさらなるフィードバックもお待ちしています。
一般提供に移行する	オリジントライアルから一般提供に移行した場合、Topics API に影響はありますか？	オリジントライアルから一般提供に移行したユーザーのデータが失われることはありません。
プライバシー	ホスト名には Topics API により公開される可能性がある個人情報が含まれている可能性があります	Google は、プライバシーを確保するためにさまざまな対策を講じています（概要の説明を参照）。
不正行為や不正使用	不正なアクセスによる Topics の改ざんを防ぐ方法	リスクの軽減については、こちらで説明しています。
Topics 分類器	ウェブサイトが Topics 分類の変更をリクエストすることはありますか？	このトピックに関するエコシステムの声、およびフィードバックをお待ちしています。
Topics プロバイダサイト	多くのトピックのコンテンツをホストする特定のウェブサイトを「特別なトピックプロバイダサイト」として指定し、ウェブページで提供されるタグに基づいて分類器をトレーニングします。	この提案についてはこちらでご説明しています。ぜひフィードバックをお寄せください。

Protected Audience API（旧 FLEDGE）

フィードバックのテーマ	概要	Chrome レスポンス
トラフィックシェーピング	秒間クエリ数（QPS）の負荷を最適化する SSP に基づくフィルタリングがパフォーマンスに与える影響	トラフィックシェーピングについては、かなりの時間を費やしてきましたが、SSP ではキャッシュを活用することをおすすめします。
テスト時のボリューム	SSP や DSP が大量のトラフィックの獲得に苦戦しているため、Protected Audience のテストが困難。	Google は、Protected Audience の導入とテストについて、常に SSP および DSP のパートナーと連携しています。一般提供が開始され、PA が有効になっているトラフィックの割合により、パートナー様がテストしやすくなると確信しています。
複雑さ	Protected Audience ソリューションの実装には、多大な労力と費用が必要です。	Google は、プライバシーサンドボックスを含む新しいテクノロジーの導入が難しいことを認識しています。プライバシーサンドボックスチームは、幅広い関係者と緊密に連携して取り組みの伝達とサポートを行うとともに、エコシステムの採用をサポートするために他の推進要因を継続的に評価しています。
信頼できる実行環境	非パブリッククラウド環境での高信頼実行環境（TEE）のサポート	Google は、クラウドベースのソリューション以外のサポート方法を検討していますが、プライバシーサンドボックスの評価に時間がかかるようなオンプレミスのセキュリティ上の制限を考えると、現時点ではオンプレミスの TEE をサポートすることは現実的ではありません。プライバシーサンドボックスのセキュリティ要件とオンプレミスでのデプロイがもたらす大きな課題を考慮すると、クラウドベースのデプロイを継続的に拡大、改善すること（たとえば、AWS に加えて GCP をサポートするなど）が、エコシステムにとって最も有益であると考えています。しかしながら、このような要件が必要な理由について、追加のフィードバックをお待ちしております。
費用構造	入札とオークションサービスの提案では、クライアントサイドのモデルと比較して、広告テクノロジーのコストと複雑さが増す。	現在、入札とオークションサーバーでの入札とオークションのワークフローをサポートする費用の見積もりガイドを作成しています。このガイドは、Google の設計の目標の 1 つを達成するため、広告技術の使用状況と相関しています。
K-Anon のタイムライン	計画された k-匿名性の制約は、いつ「renderUrl」に適用されますか？	現在、ポリシーの施行スケジュールをご説明すべく取り組んでおります。そのスケジュールは近日公開予定です。
runAdAuction の制限	`runAdAuction` をトップページからのみ呼び出せるように制限できますか？	Google の設計は `runAdAuction` をトップページから呼び出せるように完全にサポートしていますが、トップレベルドメインからのみ呼び出せるように制限した方が、パブリッシャーにとっては有害であると考えられます。プライバシーサンドボックスはパブリッシャーと広告主の負担を最小限に抑える必要があるという、エコシステムのより具体的な声が寄せられていました。このフィードバックは、サイト所有者がサードパーティのツールを使用してサイトを運用できる、というウェブ開発の一般的な原則に沿ったものです。プライバシーサンドボックスは、パブリッシャーや広告テクノロジーの仕組みを規定することなく、健全なエコシステムの実現を目指しています。 Google は、サイト上で `runAdAuction` を呼び出す方法を、誰がどのように選択するかをパブリッシャーが選択できるようにすることで、要件に最適な方法を柔軟に選べるようにしています。
実装サポート	Chrome で複数の販売者オークションのオープンソース実装を構築または貢献することはできますか？	プライバシーサンドボックスは、サードパーティ Cookie やその他のクロスサイト識別子に依存しないプライバシー保護技術の開発を目的としている。Google は、広告テクノロジーの仕組みを規定することなく、健全なエコシステムを実現したいと考えています。 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 パートナーから詳細をお伺いし、より多くの事例を拝見したいと考えています。
更新の頻度	`dailyUpdate` からの通話の頻度（インタレストグループ 1 つにつき 1 日あたり最大 1 回）では、商品情報の更新などの特定のユースケースでは十分でない場合があります。	フィードバックをお寄せいただきありがとうございます。K/V ルックアップなど、さまざまな頻度で更新されるシグナルを広告テクノロジーが使用できるようにするソリューションが他にもあります。
広告品質管理	パブリッシャーが広告品質管理を実装する方法	現在、Protected Audience API には、オークション設定の一環として事前入札の一部として設定できる特定のコントロール（広告に関連付けられたラベルに基づく拒否リスト）をパブリッシャーが SSP に知らせるための機能が用意されています。エコシステムで必要となる追加機能がありましたら、フィードバックをお寄せください。
デバッグ	`forDebuggingOnly` の機能はいつ削除されますか？	サードパーティ Cookie のサポート終了により、損失イベントの `forDebuggingOnly` は廃止される予定です。早ければ 2026 年の勝利イベントで `forDebuggingOnly` を廃止する予定です。
クロスデバイスインタレストグループ	認証されたユーザーエージェントに対してクロスデバイスインタレストグループを有効にする提案	Google はこの提案を評価していますが、こちらの GitHub のイシューで説明されているように、クロスデバイスターゲティングの限定性が高いため、プライバシーに関する重大な懸念が生じます。
（第 1 四半期にもレポート）動的リマーケティング	サードパーティ Cookie のサポートが終了した後も、Protected Audience API で動的リマーケティングは引き続き利用できますか？	こちらで説明されているように、Protected Audience を使用することで、このようなユースケースが可能であると考えています。
クリック関連データ	クリック関連のデータを `browserSignals.` に追加する	現在、仮の掲載順位を決定するために、クリックが発生した時期について明確にお尋ねしています。
（2022 年第 4 四半期にもレポート）Protected Audience のユーザー定義関数	Protected Audience API でのユーザー定義関数（UDF）はどのようにサポートされますか？エンドユーザーがプログラムして API の機能を拡張できる関数です。	また、この問題を提起した広告テクノロジーは、UDF で何ができるかを検討中であるため、少なくとも一般提供までは対応すべき実用的なフィードバックはまだないと述べています。
通貨	通貨の金額は、浮動小数点数を使用して表すことはできません。	この問題については、こちらで詳しく説明しています。
DSP 以外の広告選択機能	Protect Audience API オークションで広告サーバーはどのような役割を果たしますか。	広告サーバーに、入札後の広告選択やダイナミッククリエイティブ最適化サービスを引き続き提供してほしいというご要望を認識しています。現在、現在の Protected Audience API とこれらのリクエストとの間に存在している詳細なギャップ分析を評価しています。
GenerateBid	`generateBid` から広告インタレストグループごとに複数の広告候補を返し、それらの候補が「scoreAd」にスコア付けされるという Google 広告の提案のサポート。	これは現在評価中です。こちらからフィードバックをお寄せください。
オークションの順序	Protected Audience API のオークションは、他のすべてのオークションの結果から入力を受け取るために、最後に実施するオークションである必要がありますか？	Protected Audience API を最後に実行するための技術的な要件はありません。
ユーザー開始ではないナビゲーション	ユーザーが開始していないナビゲーションを公開する	Google でこのリクエストを審査し、こちらで検討し、追加のフィードバックをお待ちしています。
キャッシュ	ユーザーの状態が変化した場合、SSP は特定の DSP の perBuyerSignals をキャッシュからビルドすべきではありません。	Google は、perBuyer シグナルにおいて、すべてのユースケースでキャッシュが機能するとは限らないことを理解しており、さらなるオプションを検討しています。キャッシュがユースケースに有効かどうかについて、エコシステムからのさらなるフィードバックをお待ちしています。
Attribution Reporting と Protected Audience	Attribution Reporting API と Protected Audience API はどのように連携できますか？	Protected Audience API の統合は現在、Attribution Reporting API モード（イベントレベルレポートと概要レポート）の両方で利用できます。6 月 1 日に、改善された Protected Audience API と Attribution Reporting の統合に関する詳細情報を公開しました。詳しくは、こちらをご覧ください。
サーバーエンドポイント	最終的な設計で、サーバーエンドポイントを信頼できる集計サーバーとして使用するか？	サーバーエンドポイントは広告テクノロジーが維持するエンドポイントで、収集および変換されたレポートの処理に使用される信頼できる集計サーバーから独立しています。現時点では、レポートエンドポイントに対する変更の予定はありません。現在の設計は、（暗号化されたペイロードを含む）集計可能レポート自体がクロスサイトデータを漏洩しないようにすることを目的としているため、信頼できるエンドポイントは必要ありません。さらに、広告テクノロジーによって望ましいバッチ処理戦略が異なる可能性があります。こちらからフィードバックをお寄せください。
WebIDL	現在の Protected Audience API 仕様は WebIDL 仕様に対応していません。	お寄せいただいたフィードバックを評価し、こちらで議論しています。
同意の管理	同意シグナルの受け渡しは Protected Audience API でどのように処理されますか？	コンテキスト情報は Protected Audience API の範囲外です。現在、この問題について議論しており、追加のフィードバックをお待ちしています。
アカウントベースのマーケティング	アカウントベースのマーケティングのユースケースは可能か？	Protected Audience API は、オーディエンスベースのさまざまなマーケティングのユースケースに対応しています。Google は、このようなユースケースに Protected Audience API を最適に活用するための取り組みを続けています。この問題に関するエコシステムからの追加のフィードバックをお待ちしています。
コンポーネントオークション	コンポーネントオークションの参加者のスコアは？	コンポーネントオークションでは、インタレストグループが直接スコア付けされるわけではありません。代わりに、DSP が `generateBid` 関数から送信する広告と入札単価をスコア付けします。`generateBid()` 関数はインタレストグループごとに実行され、generateBid を実行すると DSP から次のメッセージが返されます。 return { 'ad': adObject, 'adCost': optionalAdCost, 'bid': bidValue, 'render': renderUrl, 'adComponents': [adComponent1, adComponent2, ...], 'allowComponentAuction': false, 'modelingSignals': 123}; }
外部提供	Key-Value サーバーの GitHub コードベースでの外部コントリビューションのサポートリクエスト。	GitHub コードへの外部貢献をサポートするために、関連プロセスを更新する予定です。
インタレストグループの規模	IG がサポートできる鍵の最大数はいくつですか？	現在の上限は 1 つの IG のサイズに関する 50 KB であり、キーはその一部としてカウントされます。サイズ制限については、お気軽にお問い合わせください。
バッチ処理	K/V サーバーの呼び出し数を減らすにはどうすればよいですか。	HTTP Cache-Control ヘッダーを使用して K/V 呼び出しの回数を減らせます。たとえば、コンポーネントのオークションや、単一ページの広告スロットをまたいでキャッシュに保存できます。
バージョン管理	アドテックコードの複数のバージョンをサポート	入札サービスとオークションサービスは、広告技術コードの複数のバージョンをサポートします。Bidding and オークション 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 会議で議論しており、妥当な上限額についてのフィードバックを募集しています。イベントレベルレポートを含むアトリビューションレポートの説明に、ブラウザがソースサイトで表される「デスティネーション」eTLD+1 の数を制限できることを説明しました。（pull リクエストを参照）。
Attribution Reporting と Protected Audience	Attribution Reporting API と Protected Audience API はどのように連携できますか？	Protected Audience API の統合は現在、Attribution Reporting API モード（イベントレベルレポートと概要レポート）の両方で利用できます。6 月 1 日に、改善された Protected Audience API と Attribution Reporting の統合に関する詳細情報を公開しました。詳しくは、こちらをご覧ください。
イベントレベルの柔軟な構成	パラメータが構成できるようになったため、ノイズシミュレーションのベストプラクティスを共有する。	GitHub でコードを共有して、誰でもテストしたい柔軟なイベントレベル設定の情報獲得とノイズの影響を評価できるようにしています。コードを使用したテストを選ばれた方、フィードバックをお寄せいただけると幸いです。
アプリとウェブにわたるアトリビューション測定	アプリとウェブにわたるアトリビューション測定はいつ利用できるようになりますか？	Google は 5 月 9 日に Attribution Reporting API を使ったクロスアプリとウェブのアトリビューション測定のテストを発表しました。Chrome 115 では関連性と測定に関する API の一般提供を予定していますが、現在のところ Chrome 115 ではクロスアプリとウェブアトリビューション測定の一般提供は予定されていません。
コンバージョンの重複を除去する	独立した測定ソリューションと ARA との違いは？	現在の標準的な手法と同様に、広告主様は独立した第三者の測定プロバイダと連携し、コンバージョンレポートの重複を排除する必要があります。イベント単位のレポートでコンバージョンの重複を排除する方法についてのリソースを提供しています。
Attribution Reporting データベース更新中のデータ損失	発表されたとおり、Chrome で Attribution Reporting データベースが更新された場合、データが失われることはありますか？	Chrome Stable 115 以降、一部の Chrome ユーザーに対し、デフォルトで Relevance API と Measurement API が有効になります。Google が潜在的な問題をモニタリングしている間、一般提供が開始される予定です。2023 年第 3 四半期までに数週間かけて 100% の可用性を実現することを目標としています。これは、関連性と測定のオリジントライアルも同時に終了します。7 月から、テスターは一般提供としてこれらの API にアクセスするための登録を行えるようになります。これにより、オリジントライアルの可用性と登録による一般提供が重複することになります。オリジントライアルトークンは 9 月 19 日まで有効ですが、進行中のテストを中断することなくオリジントライアルからシームレスに移行するために、有効期限が切れる前に API に登録することをおすすめします。こちらのお知らせに記載のとおり、古いバージョン（M113 以前）から登録されたデータは更新後に移行されないため、データが失われる可能性があります。このデータ損失はデバッグレポートには表示されません。Google では、114 ～ 115 のデータ損失を回避するよう努めています。
請求	コンバージョン単価の課金に Attribution Reporting を使用する	こちらの記事に記載のとおり、Attribution Reporting API は、イベントレベルレポートと概要レポートにノイズが付加されるため、コンバージョン単価課金のニーズには適さない場合があります。エコシステムの関係者の皆様には、GitHub の Attribution Reporting API によるさまざまな課金モデルへの影響について、フィードバックを共有していただければ幸いです。

集計サービス

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

Private Aggregation API

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

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

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

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

IP 保護（旧 Gnatcatcher）

フィードバックのテーマ	概要	Chrome レスポンス
不正行為、不正使用	企業はどのようにして IP 保護で不正行為対策を設定できますか？	Google は、不正防止ユースケースの重要性と、そのユースケースに起こりうる影響を理解しています。不正防止のサポートについては、今年の夏の後半にさらに詳しく公表する予定です。不正防止のユースケースをより適切にサポートする方法について、エコシステムからのフィードバックをお待ちしています。
GeoIP	GeoIP のテストと導入のタイムラインの詳細	Chrome は先ごろ、GeoIP に関する計画の詳細を示す新しい情報を公開しました。導入スケジュールの詳細は第 3 四半期に公表する予定です。IP 保護は、まずはユーザーのオプトイン機能として、ごく一部のトラフィックを対象にリリースする予定です。これは、この提案には企業にとって重大な変更が生じる可能性があることを認識しており、機能を広く展開する前にエコシステムが調整を行い、フィードバックを提供する時間を設けるためです。
アカウント認証	プロキシサーバーを使用したアカウント認証は正確にどのように機能しますか？	アカウント認証の詳細については、今年の夏の後半に発表する予定ですが、最初の考慮事項はすでにお伝えしています。

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

フィードバックのテーマ	概要	Chrome レスポンス
テストのガイダンス	バウンストラッキング対策のテスト方法に関する情報	バウンストラッキング対策のテスト方法について詳しくは、5 月にブログ記事を公開しました。
ドキュメント	バウンストラッキング提案のわかりやすさ	現在の提案は現在開発中であり、Chrome ではエコシステムに明確さと情報を提供するため、継続的に提案を更新しています。引き続き詳しい情報を提供するよう取り組んでおりますので、ぜひフィードバックをお寄せください。
Cookie の削除	バウンストラッキング対策ではドメイン内のすべての Cookie が削除されますか？	バウンストラッキング対策（BTM）は、こちらの説明のように、すべてのストレージとすべてのキャッシュを消去します。
バウンストラッキング対策の回避	ポップアップや新しいタブでリダイレクトすることで、バウンストラッカーの分類が回避されることがあります。	バウンストラッキング対策の仕様は現在開発中です。これまでは、同一タブへのリダイレクトに重点を置いてきましたが、今後はポップアップフローにも対応する予定です。こちらからフィードバックをお寄せください。

プライバシーバジェット

フィードバックのテーマ	概要	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 に登録する必要があります	Google では提案を検討しております。こちらからご意見、ご感想をお寄せください。

Fenced Frames API

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

Shared Storage API

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

チップ

フィードバックのテーマ	概要	Chrome レスポンス
パーティションの上限	パーティショニングされたサイトあたり 10 KiB という十分な量はまだあるため、さらに削減する必要があります。	Firefox はすでに CHIPS で肯定的な位置付けを示しています。Webkit のサポートについては、こちらの GitHub の問題について、直接 Apple にフィードバックをお寄せください。その際、パーティション化されたストレージよりもパーティション化された Cookie が好まれるユースケースについてフィードバックをお寄せください。
認証済み埋め込み	認証済み埋め込みに影響するさまざまなパーティショニングがあるため、CHIP が現在の SSO ログインフローに影響する可能性があります。	Google は、Storage Access API（ユーザープロンプトを使用）を活用して、認証済み埋め込みのユースケースをサポートする予定です。また、先日、インテントからプロトタイプへの変換についてもお送りしました。
永久ポリシー	潜在的なライフタイムポリシーはファーストパーティの Cookie に適用されますか？	現時点では、ファーストパーティの Cookie に全期間の制限を課す予定はありません。

FedCM

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

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

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

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

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