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

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

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

CMA へのコミットメントの一環として、Google はプライバシーサンドボックスに対する関係者のエンゲージメントプロセスに関する四半期レポート第 12 条および第 17 条（c）（ii）を参照コミットメントを参照）。プライバシーサンドボックスのフィードバック概要レポートは、フィードバックに記載のとおり、さまざまなソースから Chrome に寄せられたフィードバック（GitHub を含むがこれらに限定されない）の概要フィードバックフォームは、 privacysandbox.com、業界関係者とのミーティング、ウェブ標準フォーラムなどが挙げられますChrome はお客様から寄せられたフィードバックを歓迎するエコシステムから得た知見を活用しており、学んだことを生の態度で重要な役割を果たします

フィードバックのテーマは API ごとに普及率によってランク付けされています。これを行うには、TensorFlow で過去 90 日にわたって Chrome チームが受け取ったフィードバックの数量の多い順に整理します。一般的なフィードバック公開ミーティングの議論トピックを見直して、テーマを特定（W3C、PatCG、IETF）、直接フィードバック、GitHub、よくある質問 Google の社内チームや公開フォームを通じて公開できます。

具体的には、ウェブ標準団体の会議の議事録には、 Google が実施した 1 対 1 の関係者会議の記録を確認し、直接のフィードバックを得るため各エンジニアが受信したメール、API メーリングリスト、確認しました。その後 Google がチーム間で調整し、さまざまなアウトリーチ活動に関わる各 API に関連する新たなテーマの普及率を確認できます。

フィードバックに対する Chrome の回答の説明は、公開されているよくある質問、ステークホルダーが提起した問題に対して実際に行われた対応、特にこの公開レポート演習の目的のために適切な立場に立ちます現在の開発とテストの焦点、質問、フィードバックを反映する特に Topics、Protected Audience、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 API
W3C: World Wide Web Consortium
WIPB: 意図的な IP ブラインドネス

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

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

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

トピック

フィードバックのテーマ	概要	Chrome のレスポンス
プライバシー保護	プライバシー保護に関する Topics API を評価する研究	Google は研究コミュニティと積極的に関わっており、Topics API のプライバシー特性に関する研究を論文、レポート、ワークショップのプレゼンテーションなどで発表しています。研究コミュニティの外部メンバーがこの分野に関わってくれることを嬉しく思います。 Topics API により、ユーザーを大規模にトラッキングすることは困難になり、ウェブ上の一般的なトラッキングからユーザーを保護します。これらの論文からわかるとおり、Topics API を使用してこれを実現できました。Cookie はサードパーティ Cookie よりもプライバシーが保護されており、ユーザーを保護すると同時に、ユーザーが快適に利用できるサイトをサポートします。
トピックの分類が不十分な場合	広義トピックの分類には、リージョン固有など、より詳細なトピックは含まれません。	エコシステムから寄せられた以前のフィードバックにお応えして、6 月 15 日にブログ投稿を公開し、エコシステムからのフィードバックを踏まえた多くの改善を反映した新しい分類の更新について詳しくお伝えしました。分類の見直しに関する取り組みの一環として、Raptive（旧 CafeMedia）や Criteo など、エコシステム全体の複数の企業と連携しています。今回の分類の更新では、有用性が低いと言われているカテゴリを削除して、広告主様の興味 / 関心により合致するカテゴリを優先するとともに、デリケートなトピックは除外するよう努めています。 Google は、エコシステムにおいて最新の分類を確認し、変更に関するフィードバックを提供することをおすすめします。
分類と分類の更新プロセス	Topics の分類と分類のリリースサイクルの詳細と、今回の更新への各企業様の準備方法についてご確認ください。	最近のブログ投稿でもお伝えしたように、分類は時間の経過とともに進化し、分類のガバナンスは最終的には業界全体の関係者を代表する外部団体に移行していくことが予想されます。また、topics-announce グループでも拡大プランを公開しました。
ファーストパーティシグナルへの影響	今回の分類の更新で増加した Topics は非常に価値が高いため、結果として、他のファーストパーティのインタレストベースのシグナルは価値が低くなる可能性があります。	CMA は 2023 年第 1 四半期のレポートで次のようにコメントしています。「Google は、広告テクノロジーのサプライチェーン全体にわたる複数の市場参加者と、提案された新しい分類法について議論してきました。大手パブリッシャーの中には、トピックの有用性が高まると、ファーストパーティデータに基づくソリューションに対する競争圧力が高まるという声もありますが、Google の暫定的な見解は、サードパーティ Cookie のサポートが終了した後も小規模のパブリッシャーが広告枠を収益化できるという点で、有用性が高いほうが競争全体にとってはなおさらであるとのことです。」Google の見解は CMA のこのコメントと合致しています。
さまざまなタイプのステークホルダーに対する有用性	SSP や DSP として機能する広告テクノロジーは、他のエコシステム企業よりも大きな優位性を持っている可能性があります。	回答は前の四半期と同じです: 「Google は CMA に対して、プライバシーサンドボックスの提案の策定と実施において、Google 自身のビジネスを自ら優先することで競争が妨げられないようにし、規模に関係なく、デジタル広告における競争への影響を考慮に入れることを約束しています。YouTube は引き続き CMA と緊密に連携し、YouTube の取り組みがこれらのコミットメントに沿ったものとなるよう努めてまいります。プライバシーサンドボックスのテストが進むにつれて、新しいテクノロジーがさまざまなタイプの関係者に対してどのように機能するかを評価する重要な質問の 1 つになります。この点でフィードバックは非常に重要です。特に、技術設計のさらなる改善に役立つ具体的で実用的なフィードバックが重要となります。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 によって公開される可能性のある個人情報が含まれている可能性があります	こちらの概要に記載されているように、プライバシーを確保するためのいくつかの緩和策があります。
不正行為と悪用	不正なアクセスによる Topics の不正操作を防ぐ方法	軽減策についてはこちらで説明しています。
トピック分類器	ウェブサイトは Topics の分類の変更をリクエストできますか？	このトピックに関して、エコシステムの皆さんからのご意見をお待ちしています。フィードバックがございましたら、ぜひお寄せください。
トピックプロバイダサイト	多数のトピックのコンテンツをホストする特定のウェブサイトを「特別なトピックプロバイダサイト」として指定しますウェブページで提供されたタグに基づいて分類器をトレーニングします。	この提案についてこちらで検討中です。追加のフィードバックをお待ちしています。

Protected Audience API（旧 FLEDGE）

フィードバックのテーマ	概要	Chrome のレスポンス
トラフィックパターン	SSP を利用したフィルタリングによる秒間クエリ数（QPS）負荷の最適化によるパフォーマンスへの影響	トラフィックパターンの検討にはかなりの時間を費やしてきましたが、この推奨事項は SSP がキャッシュを活用することを推奨しています。
ボリュームのテスト	SSP と DSP が大量のトラフィックを獲得するのに苦戦しているため、Protected Audience をテストすることは困難です。	Google は、常に SSP および DSP パートナーと連携し、Protected Audience の導入とテストを行っています。一般提供が開始されました。PA が有効なトラフィックの割合によって、パートナー様がテストしやすくなります。
複雑さ	Protected Audience ソリューションを実装するには、多大な労力と費用が必要です。	Google は、プライバシーサンドボックスを含め、新しいテクノロジーの導入が難しいことは認識しています。プライバシーサンドボックスチームは、さまざまな関係者と緊密に連携して取り組みを啓蒙、サポートしています。また、エコシステムの採用をサポートする他の推進要因を継続的に評価しています。
高信頼実行環境	非パブリッククラウド環境での高信頼実行環境（TEE）のサポート	クラウドベースのソリューション以外のサポートオプションを検討中ですが、プライバシーサンドボックスの評価に時間がかかるオンプレミスのセキュリティ制限があるため、現時点ではオンプレミス TEE のサポートは現実的ではありません。プライバシーサンドボックスのセキュリティ要件とオンプレミスデプロイに伴う大きな課題を考慮すると、クラウドベースのデプロイを継続的に拡張、改善すること（AWS に加えて GCP をサポートするなど）が、エコシステムにとって最も有益なものであると考えています。ただし、このような要件が必要な理由について、追加のフィードバックをお待ちしています。
費用構造	入札とオークションサービスの提案により、クライアントサイドのモデルよりも広告テクノロジーの費用と複雑さが増大する。	Google では現在、入札およびオークションのワークフローをサポートする費用見積もりガイドを広告技術の利用と関連付けられるオークションサーバー。当社の設計上の目標を達成する。
k-匿名性のタイムライン	予定された k-匿名性の制約が「renderUrl」に適用されるのはいつですか？	現在、適用スケジュールの説明に取り組んでおり、近日中に公開する予定です。
runAdAuction の制限	Chrome で `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 回まで）では、商品情報の更新などの特定の用途では不十分な場合があります。	フィードバックをお寄せいただきありがとうございます。K/V ルックアップなど、さまざまな頻度で更新されるシグナルを広告テクノロジーが使用できるようにするソリューションは他にもあります。
広告の品質管理	パブリッシャーによる広告品質管理の実装方法	現在、Protected Audience API には、オークション設定の一部として確立できる特定のコントロール、入札前（つまり、広告に関連付けられたラベルに基づく拒否リスト）についてパブリッシャーが SSP に通知できる機能が提供されています。エコシステムで必要な追加機能がありましたら、ぜひフィードバックをお寄せください。
デバッグ	`forDebuggingOnly` の機能はいつ削除されますか？	サードパーティ Cookie のサポート終了による損失イベントについては、`forDebuggingOnly` を廃止する予定です。`forDebuggingOnly` は、早くとも 2026 年に成約イベントで廃止する予定です。
クロスデバイスインタレストグループ	認証済みユーザーエージェントに対してクロスデバイスインタレストグループを有効にする提案	Google はこの提案を評価していますが、こちらの GitHub Issue で説明のとおり、クロスデバイスターゲティングの具体性が高いため、プライバシーに関する重大な懸念が生じます。
（第 1 四半期に報告あり）動的リマーケティング	サードパーティ Cookie のサポートが終了した後も、Protected Audience API で動的リマーケティングは可能ですか？	こちらで説明するように、Protected Audience を使用すればこのようなユースケースが可能になると考えています。
クリック関連データ	クリック関連データを `browserSignals.` に追加する	現在、クリックが暫定的な位置付けとなったのがいつ発生したかについて、詳細な説明を求めています。
（2022 年第 4 四半期に報告あり）Protected Audience のユーザー定義関数	Protected Audience API では、ユーザー定義関数（UDF）はどのようにサポートされますか？これらの機能は、エンドユーザーがプログラムして API の機能を拡張できます。	この問題を報告した広告テクノロジーは、UDF でできることはまだ評価中であるため、対応すべき実用的なフィードバックはまだないと述べています。少なくとも一般提供されるまでは対応できません。
通貨	通貨の金額は浮動小数点数で表すことはできません。	この問題への対処については、こちらをご覧ください。
DSP 以外の広告選択機能	Protect Audience API のオークションで広告サーバーはどのような役割を果たしますか？	Google は、入札後の広告選択 / ダイナミッククリエイティブ最適化サービスを引き続き提供したい広告サーバーのリクエストを認識しています。現在、現在の Protected Audience API とこれらのリクエストの間に存在する詳細なギャップ分析を評価しています。
GenerateBid	Google 広告のサポート`generateBid` から広告インタレストグループごとに複数の広告候補を返し、それらの候補を「scoreAd」でスコア付けするという提案です。	これは現在評価中です。追加のフィードバックをお待ちしています。
オークションの順序	他のすべてのオークションの結果から情報を取得できるようにするには、Protected Audience API オークションを最後に実施する必要がありますか？	Protected Audience API を最後に実行するための技術的要件はありません。
ユーザーが開始しないナビゲーション	ユーザー開始型ではないナビゲーションを公開する	現在このリクエストを審査し、こちらで検討しております。追加のフィードバックをお待ちしています。
キャッシュ	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 仕様に対応していません。	お寄せいただいたフィードバックを評価し、こちらで問題について検討しています。
同意の管理	同意シグナルの受け渡しは 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 サーバーの GitHub コードベースに対する外部からのコントリビューションのサポートをリクエストします。	Google は、GitHub コードへの外部貢献をサポートするために、関連プロセスを更新していく予定です。
インタレストグループのサイズ	Instagram がサポートできる鍵の最大数はいくつですか？	現在の上限は 1 つの IG のサイズで 50 KB で、キーはその一部としてカウントされます。サイズ制限についてのディスカッションをお待ちしています。
バッチ処理	K/V サーバーの呼び出し回数を減らすにはどうすればよいですか。	HTTP Cache-Control Headers を使用して、K/V 呼び出しの数を減らすことができます。たとえば、コンポーネントのオークション全体や、単一ページの広告スロットにまたがってキャッシュできます。
バージョン管理	広告技術コードの複数バージョンのサポート	入札サービスとオークションサービスでは、複数のバージョンの広告技術コードがサポートされます。Bidding and Auction API では、`SelectAd` リクエストでオークションリクエスト（入札 / オークションとレポート作成）に使用されるコードのバージョンを指定できます。
共有ストレージ	入札およびオークションサービスの共有ストレージへの書き込みをサポートします。	現在、入札とオークションサービスは共有ストレージをサポートしていませんが、このようなユースケースがエコシステムにとって重要である理由について、追加のフィードバックをお待ちしています。
ウェブからアプリ	インタレストグループのウェブからアプリへの共有をサポートします。	現在のところ、ウェブからアプリへの広告配信は、Chrome と Android での Protected Audience API のデプロイの範囲外ですが、このユースケースの重要性についてエコシステムからのご意見を伺いたいと思います。
k-匿名性	k-匿名性フォールバックの処理方法	現在この事象について検討しておりますので、追加のフィードバックをお待ちしています。

デジタル広告の測定

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

フィードバックのテーマ	概要	Chrome のレスポンス
VTC イベントレベルのレポートの代替設定	代替の VTC イベントレベルのレポート設定に関するフィードバック	現在のイベントレベルの構成が最適ではないというフィードバックをいただきましたので、最適なグローバル構成についてフィードバックをお寄せください。YouTube では、この件に関する追加のフィードバックを受け付けています。イベント単位の柔軟な説明も、この問題の解決に役立つと考えています。
柔軟なイベントレベルの設定	柔軟なイベントレベルの設定機能はどのような状態ですか？	柔軟なイベントレベルの設定に関するドキュメントも共有しています。この機能はまだ提案段階にあり、エコシステムにとって有益であるかどうかについては、より多くのフィードバックをお待ちしています。
柔軟なイベントレベルの設定	異なる関係者からの競合するレポートを調整するには	ほとんどのレポートシナリオには集計レポートが使用されますが、イベントレベルの柔軟な設定の提案は、最適化のユースケースによく使用されるイベントレベルレポートの柔軟性を高めるためのものです。このシナリオについて、エコシステムに関する追加のコメントやフィードバックをお待ちしています。
ソースの登録	トリガーの登録後にソースの登録が行われた場合はどうなりますか？	現時点では、トリガーの登録後にソースの登録が発生した場合、ソースとトリガーを相互に関連付けることはできません。これはエッジケースのシナリオであると考えられます。この問題に関して、さらにフィードバックがありましたら、ぜひお寄せください。多くの広告テクノロジーが直面していると考えられるシナリオがある場合は、対処いたします。
複数の広告代理店との連携	広告主が複数の広告代理店と提携している場合、DSP は Attribution Reporting API をどのように使用できますか。	この API はリダイレクトをサポートしているため、広告主が複数の広告代理店と連携している場合でも使用できます。また、API のプライバシー保護を強化するために、リダイレクトに関していくつかの制限が設けられています。また、広告テクノロジーが提起した特定のシナリオに対して、Shared Storage API を利用した回避策を検討しました。このシナリオについて、他にフィードバックがありましたら、ぜひお寄せください。いただいたフィードバックをもとに引き続き取り組んでまいります。
宛先の上限	自動更新広告のユースケースは、リンク先の上限を設定することにより影響を受ける場合があります。	この問題は 5 月 1 日の WICG 会議で議論し、妥当な上限についてフィードバックを求めています。イベントレベルレポートを使用したアトリビューションレポートの説明に、ブラウザがソースサイトによって表される「リンク先」の 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 に共有コードがあり、テストしたいイベントレベルの柔軟な設定について、誰でも情報利得とノイズの影響を評価できます。コードのテストにご協力いただき、フィードバックをお寄せいただけると幸いです。
アプリとウェブをまたいだアトリビューション測定	アプリとウェブをまたいだアトリビューション測定はいつ利用できるようになりますか？	Google は 5 月 9 日に、Attribution Reporting API によるクロスアプリとウェブのアトリビューション測定のテストを発表しました。関連性と測定の API は Chrome 115 で一般提供される予定ですが、現在のところ、クロスアプリとウェブのアトリビューション測定は Chrome 115 で一般提供になる予定はありません。
コンバージョンの重複除去	独立した測定ソリューションと ARA は、どのように調整できますか？	現行の標準的な手法と同様に、コンバージョンレポートの重複を排除するために、広告主は独立した第三者測定プロバイダと提携する。イベント単位のレポートでコンバージョンの重複を除去する方法に関するリソースもご用意しています。
Attribution Reporting データベースの更新中のデータ損失	発表されたとおり、Chrome でアトリビューションレポートデータベースが更新される際にデータが失われることはありますか？	Chrome Stable 115 以降、一部の Chrome ユーザーに対して Relevance API と Measurement API がデフォルトで有効になります。この一般提供は、Google が潜在的な問題をモニタリングするにつれて徐々に進んでいきます。目標は、2023 年第 3 四半期までに数週間で 100% の可用性を達成することです。これは、関連性と測定のオリジントライアルの終了と同時に行われます。7 月から、テスターの皆様は登録してこれらの API の一般提供を開始できるようになります。これにより、オリジントライアルの提供と登録を通じた一般提供が重複します。オリジントライアルトークンは 9 月 19 日まで有効ですが、進行中のテストを中断することなくオリジントライアルからシームレスに移行できるように、有効期限までに API を登録することをおすすめします。こちらのお知らせでご案内したとおり、古いバージョン（M113 以前）で登録されたデータは更新後も移行されないため、データが失われる可能性があります。このデータ損失はデバッグレポートには表示されず、114 ～ 115 のデータ損失は回避されます。
課金	コンバージョン課金型でアトリビューションレポートを使用する	こちらの記事でご説明したとおり、イベントレベルレポートとサマリーレポートにノイズが追加されるため、Attribution Reporting API はコンバージョン単価ベースの請求には適さない場合があります。エコシステム関係者の皆様には、GitHub の Attribution Reporting API によるさまざまな課金モデルへの影響についてフィードバックをお寄せください。

集計サービス

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

Private Aggregation API

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

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

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

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

IP 保護（旧 Gnatcatcher）

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

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

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

プライバシーバジェット

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

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

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

フィードバックのテーマ	概要	Chrome のレスポンス
（以前の四半期でも報告）ドメインの上限	関連ドメイン数の拡張リクエスト	Chrome では、特定されたユースケースに対するプライバシーと有用性のバランスを取るために、関連するサブセットについて適切な数値制限を評価しています。当初、Chrome では関連するサブセットの正確な数はまだ確定していません。
埋め込みのユースケース	ファーストパーティセット、CHIP、共有ストレージを必要とする埋め込みのユースケースをサポート	Chrome はこのユースケースに関するフィードバックを受け取りました。チームが調査中です。追加のフィードバックをお待ちしています。
リポジトリ管理	差異や見落としがあった場合に、GitHub リポジトリからファーストパーティセットを削除するポリシーに関する情報	Chrome はこのユースケースに関するフィードバックを受け取りました。担当チームが現在調査中です。追加のフィードバックをお待ちしています。
ユーザーへの説明	Chrome でファーストパーティセットに関するユーザーの認知度と理解を深め、導入を促進する必要がある。	Chrome では、ファーストパーティセットについてユーザーに周知することに尽力しており、これに関するヘルプセンターの記事（Chrome の管理画面からリンクしています）を公開しています。また、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 に積極的に参加し、この提案を支持し、フィードバックを求め、導入を促進していきます。
出力ゲート	共有ストレージの出力ゲートが制限が多すぎる。	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 の問題で、パーティション化されたストレージよりもパーティション化された Cookie が好まれるユースケースについて、Apple に直接フィードバックを提供することをおすすめします。
認証済み埋め込み	CHIP は、異なるパーティショニングが認証済み埋め込みに影響するため、現在の SSO ログインフローに影響する可能性があります。	認証された埋め込みのユースケースをサポートするには、Storage Access API（ユーザープロンプトあり）を活用する予定です。先日、インテントからプロトタイプへの変換をお送りしました。
全期間ポリシー	ライフタイム Cookie に関するポリシーはファーストパーティの Cookie に適用されますか？	現時点では、ファーストパーティの Cookie に全期間の制限を課す予定はありません。

FedCM

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

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

Private State Token API（およびその他の API）

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

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