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

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

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

競争市場庁に対する取り組みの一環として、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、Fledge、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 は広く情報を発信しています。Chrome では、よくある質問を投稿して、今後世界中でテストを実施する予定であることを認めています。また、Chrome は今後も CMA と定期的に協議して公開スケジュールを更新します。

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

API / テクノロジー	フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
トピック	大まかなトピックの有用性	インタレストベース広告の場合、大まかなトピック分類では有用でない可能性があるという懸念が寄せられています。	API の有用性は、テストを通じて検証されます。Chrome では、テスト結果に基づいて分類が進化することが想定されています。
トピック	分類	業界の関係者は、分類法に影響を与える声を求めています。	Chrome では分類に関する入力を受け付けています。Chrome では、分類を変更するためのガバナンスモデルに関するフィードバックや、長期的な分類法の開発と保守において他の業界団体がより積極的な役割を果たす方法に関する議論に大変興味を持っています。
トピック	さまざまなタイプのサイトでの利便性	サイトのトラフィック量やコンテンツの特化度に応じたサイトの有用性について懸念が寄せられています。	API の有用性は、テストを通じて検証されます。Chrome では、テスト結果に基づいて分類やその他のパラメータが進化することが想定されています。分類やパラメータの進化によって、下位互換性のない変更が不要になる場合があります。また Chrome では、サードパーティ Cookie のサポートが終了した後も、Topics API の進化に影響を与えるフィードバックが引き続き続くと予想しています。
トピック	サイト分類手法	サイトが Topics の分類を決定したり、処理したりできるようにリクエストします。	Chrome ではこのリクエストについて検討していますが、プライバシーを侵害する手法でユーザーをターゲティングしたり広告の関連性を低下させたりする目的でサイトが「システムを操作」する可能性があるという潜在的なリスクについて（ウェブブラウザコミュニティと DSP から）懸念が寄せられています。Chrome はフィードバックを求め、起こりうる変化を比較検討しています。
トピック	ノイズとなる信号	5% の確率でランダムなトピックを配信すると、ノイズが多くなりすぎたり、誤ったシグナルが生成されたりする可能性があります。	ノイズはユーザーのプライバシーを保護するための重要な手法です。ノイズレベルとトピックの有用性は、テストを通じて検証されます。
トピック	サイト管理によるサードパーティの権限付与	サイトから Topics API を呼び出すことができる広告テクノロジーをサイトが選択できるようにリクエストします。	リクエストされた機能は、説明で説明したように、「browsing-topics」権限ポリシーを介してすでにサポートされています。
トピック	Topics API がページのパフォーマンスに及ぼす影響	Topics API への依存による、最初の広告までの時間の遅れに関する懸念	Chrome では、パフォーマンス向上のために HTTP リクエストヘッダーでのトピックのサポートの可能性について検討しています。Google では、テストによって、こうした変更が必要かどうかを確認しています。
トピック	プライバシー / ポリシー	サードパーティがトピックを共有する場合、発信者で応答をフィルタする目的に関する質問。	エコシステムの多くのユーザーからのフィードバックに基づき、Chrome では情報へのアクセスが、他の方法ではアクセスできないユーザーのみに限定されるようにこの設計を採用しました。もちろん、Topics を受け取るパブリッシャーやサードパーティは、サイトでどの情報をパーティと共有するかを自身で決めることができます。共有する場合は、ユーザーに対して透明性を確保し、ユーザーが自分で管理できるようにすることを強く推奨します。
トピック	ドキュメント	これまで FLoC で行ったように、Chrome で使用された分類器モデルと分類の詳細（分類器と分類が変更される頻度など）について記載したドキュメントへの関心	Chrome では、オリジントライアルの一環として使用される分類がすでに提供されています。また、ウェブサイトをトピックに分類する分類モデルは、オープンソースコードの一部として Chrome のコードベース内で利用可能になっています。オリジントライアルの一環として、Chrome はフィードバックや機能についての学習情報を収集し、必要に応じて変更を加える権限を有します。
FLEDGE	フリークエンシーキャップ	キャンペーンまたは広告グループ内でユーザーごとのフリークエンシーを制御できること。	FLEDGE は、オンデバイスオークションのフリークエンシーキャップに対応しています。FLEDGE でもコンテキスト/ブランディングキャンペーンをサポートするため、この問題の対象となる未解決の問題があります。共有ストレージ、別の開発 API、サイト固有の上限を使用して、フリークエンシーキャップをさらにコントロールすることもできます。
FLEDGE	FLEDGE がパフォーマンスに及ぼす影響	計算負荷の高いビッダーが FLEDGE オークションに及ぼす影響について懸念が寄せられています	Chrome では、サイトのパフォーマンスに及ぼす影響について、デベロッパーと活発に議論しています。Chrome では、テスト中により多くのことを学ぶ機会を歓迎します。
FLEDGE	他の機能との FLEDGE のテスト	他の機能（k-匿名性サーバー、Key-Value サーバーなど）を使用したテストは、いつ、どのように実施されるか。	Chrome では、テストを容易にするために、最初のオリジントライアルで機能を段階的にリリースしています。Chrome では、他の機能のタイムラインを明確にすることが重要であると認識しており、可能な場合は明確にしています。
FLEDGE	テストの調整	複数の広告テクノロジー間のテストを調整する方法。	Chrome では、異なる広告テクノロジーが同じユーザーを対象にテストを行えるよう、テストの調整を支援する追加サポートの提供を検討しています。これは Chrome パートナーシップによるアウトリーチの重点的な取り組みでもあります。業界団体からも、その役割を果たすことに興味を示しています。
FLEDGE	インタレストグループの上限	1 人のユーザーを追加できるインタレストグループやオークションに参加できるインタレストグループの数に制限はありますか？	Chrome では、フィードバックと測定されたレイテンシの影響に基づき、テスト期間中、ウェブページのパフォーマンスまたはユーザーエクスペリエンス上の理由からこれらの制限を絞り込んでいきます。現在、テスターの間で、購入者と販売者によるリソース使用量の調整を可能にする新たな方法が検討されています。
FLEDGE	クロス API 機能	FLEDGE では、アトリビューションレポートはどのように機能しますか？	詳細はまだ未定であり、Chrome では第 2 四半期にこの点について更新する予定です。Chrome では、オリジントライアル中もオークション結果（勝敗）のイベントレベルのレポートを引き続き提供する予定です。

デジタル広告を測定する

API / テクノロジー	フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
Attribution Reporting（とその他の API）	トラフィックのテスト	テストに十分なトラフィックがあるかどうかの懸念	Chrome では、ユーザーコントロールに重大なバグや問題がないことを確認するために、非常に少ないトラフィックでオリジントライアルを開始します。早期テスターは、API が技術的な観点から意図したとおりに機能していることを確認するうえで重要な役割を果たします。これにより、より大きなトラフィックを迅速に増やせるようになります。API が想定どおりに機能していると確信できる時点で、Chrome はユーティリティテストをサポートするためにオリジントライアルを増やします。
Attribution Reporting	イベント登録のエルゴノミクス	サポートされているイベント登録形式に関する質問。	現在サポートされている登録形式を明確にするため、Chrome の回答が GitHub で公開されています。Chrome では、現在の設計に関するフィードバックをエコシステムから収集し、提案された変更がこれらの懸念事項に十分対応できるかどうかや、さらなる更新が必要かどうかを確認します。
Attribution Reporting	ノイズ生成	集計レポートでノイズがどのように生成されるかの詳細。	Chrome では、GitHub で回答が公開されており、体系的なノイズの生成方法に関する詳細が提供されています。Chrome では、OT 時にノイズをシミュレートし、さまざまなパラメータを使用してテストするためのライブラリを提供する予定です。Chrome では、集計レポートモードに関するデベロッパー向けドキュメントやガイドも追加で提供する予定です。
Attribution Reporting	小規模サイトのデータの精度は低下	小規模なサイトやキャンペーンで提供されるデータの精度が低下するのではないか。	Chrome では、ノイズベースのプライバシー保護は小さいデータスライスに大きな影響を与えることを認識しています。しかし、長期間にわたって集計するなどの手法で、この問題が解決する可能性があります。また、非常に小さなデータスライス（1、2 回の購入など）に基づく結論が広告主にとって有意かどうかも不明確です。Chrome では、オリジントライアル中、プライバシーとノイズに関する幅広いパラメータを試す機能を活用して、この問題に関してより具体的なフィードバックを提供できるようにテスターに推奨しています。
Attribution Reporting	コンバージョン達成までの遅れが公益事業会社に及ぼす影響	コンバージョン達成までの所要時間によって、キャンペーンの設定と確認、またはキャンペーンの最適化が妨げられる可能性がある。	Chrome では、コンバージョンレポートの遅延が及ぼす影響について、矛盾するフィードバックが寄せられています。ただし、Attribution Reporting API では、ユーザーのプライバシーを保護するためにレポートがランダムに遅延することから、Chrome では、特定のユースケースや懸念事項がテスト期間中に明らかになり、追加のデバッグサポートまたはデベロッパーガイダンスによって対処できるものと想定しています。
Attribution Reporting	アトリビューション期間が長い	30 日間のアトリビューション期間延長リクエスト	Chrome は、データの最小化と有用性の両方を考慮し、アトリビューション期間の長さについてより多くのフィードバックを求める回答を公開しています。
Attribution Reporting	視認範囲外のインプレッション数	視認範囲外のインプレッションがビュースルーコンバージョンレポートでカウントされるかどうかに関する質問。	Chrome では、視認範囲のインプレッションをより明確に把握するため、GitHub でレスポンスを公開しています。

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

API / テクノロジー	フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
ユーザーエージェントの情報量削減	パフォーマンス	Critical-CH 経由でのヒントの取得に遅延（最初のページの読み込み時）が懸念されています。	Chrome はパフォーマンスを改善する方法を調査しています。
User-Agent の情報量削減 / User-Agent Client Hints API	不正防止 / 不正使用対策への懸念事項	サービス拒否攻撃を含め、特定の種類の攻撃をデバッグする際には、できるだけ多くの情報を得ることが重要です。UA 文字列から一部の情報が失われた場合、問題が発生する可能性があります。	Chrome では現在、デバッグに役立つ十分な情報を提供しながらプライバシーを維持する方法を検討し、検討しています。
ユーザーエージェントの情報量削減	OT 設定に関する混乱	複数のオリジントライアル参加者から、オリジントライアルへの登録方法の例を記載したドキュメントを改善するよう推奨されました。	Reduced UA オリジントライアルは終了しますが、Chrome ではサポート終了トライアルの手順を改善する予定です（サンプルデモをよりわかりやすくするなど）。
ユーザーエージェントの情報量削減	特定のヒントの値に関する懸念	Sec-CH-UA-Model が User-Agent 文字列の <deviceModel> と同じかどうかに関する質問。	Sec-CH-UA-Model は、ユーザーエージェント文字列の <deviceModel> と同じです。Chrome では、今後のドキュメントでこの点を明確にする予定です。
User-Agent の情報量削減	サポート終了トライアルへの登録に関する懸念	サポート終了トライアルに多数のドメインを登録する方法に関する質問	Chrome では、非推奨トライアルの設計時に一元化されたアプローチを検討しましたが、デベロッパーは既存のオリジントライアルですべての制御を行える（ヘッダーを送信するかどうかをデベロッパーが選択できるため）最適なオプションであると考えています。
User-Agent Client Hints API	UA-CH の規範的性質に関する懸念	rfc7231 で定義されているように、ユーザーエージェントヘッダーが提供する柔軟性に比べ、UA-CH は過度に規範的なものである可能性があります。	Chrome は、最終的なブラウザ間の相互運用性とユーザーのプライバシー保護（高エントロピー識別子の任意の追加を防ぐことによる）の両方の観点から、UA-CH ヘッダーの規範的な性質が UA 文字列の柔軟性に対する重要な改善であると考えています。ただし、他のデベロッパーもこの懸念を共有し、フィードバックを提供したい場合に、この問題は未解決のままです。
User-Agent Client Hints API	API を使用して特定のブラウザがブロックされることへの懸念	サイトが API を使用して「Google Chrome」または「Microsoft Edge」を検出し、他のすべてのブラウザをブロックしていないか。	ブランドリストのコンセプトは、こうしたケースに対応するために設計されたものです。つまり、ブラウザでは自社のブランドに加えて「Google Chrome」を送信することができます。
User-Agent Client Hints API	サポートされているすべてのヒントを列挙するメソッドのリクエスト	ブラウザでサポートされているすべてのヒントをプログラマティックに把握するための関心。	Chrome は機能リクエストを評価しています。
User-Agent の情報量削減 / User-Agent Client Hints API	不正防止 / 不正使用対策への懸念事項	HTTP1 の最初の読み込みではクライアントヒントを使用できません。	Client Hints Reliability API（ACCEPT_CH）の一つは HTTP2 と HTTP3 でのみ使用できます。依然として HTTP1 経由で配信されるサーバーについては、Critical-CH のみを使用する必要があります。
User-Agent の情報量削減	Chrome for Android への影響	特に Android 版 Chrome への影響に関する質問。	UA Reduction と UA-CH は、パソコンに加えて Android の Chrome でも利用できるようになります。Android 版 Chrome については、「フェーズ 6」（現在 Chrome 110 で実施予定）でのみ変更が適用されます。
Gnatcatcher（WIPB）	非準拠の用途と方法	不適合な用途や方法に関する明確さ。	Chrome で説明が更新され、詳細が追加されます。
Gnatcatcher + User-Agent の情報量削減	不正防止のシグナルを減らす	IP と UA のアクセスが同時に減少することによる不正行為の影響。	不正防止のユースケースに IP の使用を許可するために、意図的な IP ブラインドネス不正防止ポリシーの規定が適用されることを期待すれば、IP プロキシに関する防御性の懸念は解消されます。
ナビゲーションのトラッキング	将来の破損に対する懸念	広告主は破損の可能性を懸念しており、ID プロバイダからも Chrome の計画に関心を示しています。	Chrome では、互換性に対応しない変更が差し迫っているわけではなく、現在もユースケースを検討中です。
SameSite Cookie	他のブラウザとの相互運用	crbug.com/1221316 は Chrome の実装が他のブラウザから異なっている領域であるため、Chrome の crbug.com/1221316 の修正計画に関する質問。	Chrome では指標のバグが発見され、その結果として新しい指標が表示されました。Chrome では、バグの修正による影響を詳しく把握するためにデータを収集しています。
ストレージパーティショニング	メッセージチャネルのパーティショニングに関する懸念	メッセージチャネル（SharedWorker と BroadcastChannel など）は分割する必要があります。	Chrome ではフィードバックを評価していますが、隠れたトラッキングを防ぐために、ストレージとともにメッセージチャネルをパーティショニングする必要があると考えています。

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

API / テクノロジー	フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
ファーストパーティセット	一般的なプライバシーポリシーの要件	すべてのサービスや地域の適用法令で共通のプライバシーポリシーを維持することは不可能です。	Chrome では現在もポリシー要件を定義しており、今後もフィードバックを念頭に置いて取り組んでまいります。
ファーストパーティセット	Independent Enforcement Entity（IEE）は、FPS の有効性に関する多くの課題を受ける可能性があります。	FPS の有効性を判断する際に予想される課題のまとめ: テキストまたはプライバシーポリシーがセットメンバー間で一致しない、ユーザーが認識できるセットメンバーシップ、帯域幅とタイミングの課題を定義する方法の明確さ、企業構造に関する専門的な専門知識。	Chrome では現在もポリシー要件を定義しており、今後もフィードバックを念頭に置いて取り組んでまいります。
ファーストパーティセット	ブラウザの FPS リストを管理するプロセス	非西洋諸国におけるウェブサイトの参入障壁、更新頻度の違いによる FPS リストのバージョンがブラウザ間で統一されていないこと、小さいブラウザと新しいブラウザでリストを使用できることが懸念されている。	Chrome のポリシー要件、承認プロセス、リストの使用権の定義は継続中であり、このフィードバックを念頭に置いていきます。 Chrome では、ウェブプラットフォームで使用されている他の静的リスト（Public Suffix List など）から学習した内容も確認します。
ファーストパーティセット	サイトごとの動的なアサーション設計	（静的なリストとは対照的に）動的なデザインでは、共通の所有権を誤って主張し、ページの読み込みレイテンシやエラーが発生しやすくなる可能性があります。	Chrome は現在、静的リストアプローチを追求しています。署名付きアサーションアプローチが今後再評価される際は、このフィードバックを念頭に置いてください。
ファーストパーティセット	ファーストパーティセットの考えられるユースケース（信頼性と公平性を備えた FPS リストを作成できる場合）	シングルサインオン、カスタマイズ可能なデータプロンプト、ユーザーに対する透明性の高いレポートの可能性。	Chrome では、ファーストパーティセットの次のステップを検討する際に、このフィードバックが考慮されます。
チップ	ブラウザの互換性	分割された Cookie 属性が他のブラウザでどのように扱われているか知りたい	Chrome は、W3C などのパブリック標準グループ内で引き続き、複数のブラウザをまたいだ設計と実装の検討に取り組みます。
チップ	設計要件	__ホスト名の接頭辞を含められないことが懸念される	Chrome では、オリジントライアルの命名要件が廃止されました。テスト期間の終了時に、この機能を恒久化するかどうかを検討します。
チップ	広告ユースケースでの CHIPS の使用	広告ユースケースで CHIPS を使用できるかどうかに関する質問。	CHIPS を使用すると、サードパーティは、トップレベルサイト（またはそのファーストパーティセット）に分割されたクライアントサイド Cookie を作成できます。ユースケースにクロスサイト状態ではなくパーティション状態が必要な場合は、CHIPS をそのユースケースに使用できます。
チップ	CHIPS と FPS の統合	CHIPS によるテストが、ファーストパーティセットなどの他のプライバシーサンドボックスの提案と並行して実施できないことへの懸念	Chrome では、そのようなテストを実行できるようにするテスト環境を促進する方法を積極的に検討しています。Chrome では FPS と CHIPS のローカルテストの手順も公開しており、その間にご使用いただけます。
FedCM	表現手段	ブラウザはフェデレーション ID フローの一部をレンダリングするため、IDP がユーザーに提示したいニュアンスをすべて捕捉することが困難である。	Chrome はこのトレードオフを認識し、引き続きエコシステムと連携しながら、可能な限り多くの分野をカバーし、可能な限り表現力豊かなものにしていきます。Chrome が検討しているアイデアには、ブランディングのカスタマイズ（ロゴ、色など）や文字列のカスタマイズ（たとえば「ログイン ID」ではなく「この記事にアクセス」など）があります。
FedCM	ブラウザの関与	ブラウザが以前よりも ID 連携フローへの関与を深めたため、ユーザーがどのウェブサイト（どの IDP で）にログインしているかをより明確に認識できるようになったことが懸念されます。	Chrome は、ブラウザがよりアクティブな役割を果たすようになったことを認識していますが、ブラウザがクロスサイトトラッキングを識別して防止しながら連携をサポートするには、このさらなる関与が必要です。
FedCM	適用性と相互運用性	他のブラウザで FedCM が導入または実装されないことが懸念されます。	Chrome では、他のブラウザベンダーとも協力して、FedID Community Group で連携のための一般的なソリューションを探しています。
FedCM	API に関するさまざまな課題	FedCM はまだ初期段階 / 未熟であり、エコシステムに必要な機能をすべて提供するのに時間がかかることを懸念しています。	Chrome では、エコシステムテストの一環としてこれをさらに調査する予定です。
FedCM	企業ポリシーとユーザーコントロール	企業が変更なしでフェデレーション ID のデプロイを維持できる管理機能（エンタープライズポリシーやユーザー設定など）が用意されるかどうか。オンプレミスにはフェデレーション ID のデプロイが多くあり、再デプロイや変更が極めて困難であるため、IDP の再デプロイを必要とする新しいブラウザ API には多くの抵抗があります。	Chrome は、こうした懸念に対処できると考える企業の管理者やユーザーを対象とした管理機能を検討しています。Chrome では、具体的なユースケースについて企業からのフィードバックを歓迎しています。

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

API / テクノロジー	フィードバックテーマ（API ごとの普及率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
Trust Token API	利用制限	特に、同じページに複数回埋め込まれる場合や、組織に 2 つ目の発行元ドメインがある場合に、1 ページあたり 2 つ程度の制限が多すぎることが懸念されます。他の市場参加者を考慮せずに、自力で上限に達してしまう可能性があります。	Chrome では、導入が増えると見込まれる場合はページあたりの利用制限をわずかに引き上げることに抵抗がありませんが、過剰なエントロピーが発生するためには、上限を比較的低くする必要があります。さらに、クーポン利用記録をキャッシュに保存することで、1 つのカード発行会社が 1 人のユーザーの複数のトークンを短期間に利用する必要性を低減できます。
Trust Token API	レイテンシ	通常、入札リクエストには 10 ミリ秒以内に応答する必要があるため、最初のページの読み込み時にトークンを利用すると、入札前の無効なトラフィックの判断に含めることはほぼ不可能になります。	Chrome では、遅延が入札前のユースケースに及ぼす影響をテストを通じて把握しようとしています。
Trust Token API	OpenRTB の導入	事前入札のユースケースでは、取得されたトークンの情報を広告決定で使用するために SSP と DSP に渡すことが重要です。	Chrome は IAB と連携して、有用な不正防止/不正使用対策のシグナルが OpenRTB を通じて確実に伝達されるようにします。ただし、IAB は新しいデフォルトフィールドを追加するための標準を所有しています。
Trust Token API	プライバシー	エントロピーの量は低い（2.5 ビット以下）が、あらゆる形式のクロスサイトデータ伝播の長期的な実行可能性に関する質問	ユニークユーザーが識別されないようにするため、堅牢なユーザー保護が提供されるため、Chrome はエコシステムで受け入れられる好条件であると判断しています。Chrome は主要な関係者と緊密に連携し、長期的な活用を可能にしています。
プラットフォーム構成証明シグナル	新しいアイデア/提案に対する関心の測定	プラットフォームが提供するデバイスの完全性シグナルなど、実現可能な（および実行不可能な）さまざまなシグナルを強力にサポート	Chrome では、この考え方を新たなフィードバックとして W3C 不正防止コミュニティグループに取り入れる予定です。
不正防止のための信頼できるサーバー	新しいアイデア/提案に対する関心の測定	興味深いコンセプトですが、適用可能なユースケースについてさらなる調査が必要になる可能性があります	関心レベルに応じて、Chrome ではこのコンセプトをさらに考案し、今後のエコシステムのフィードバック用に説明内容を作成する場合もあります。

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