プライバシーサンドボックスの提案と Chrome の対応について受け取ったエコシステムフィードバックを要約した 2022 年第 1 四半期の四半期報告書。
英国公正取引委員会へのコミットメントの一環として、Google は、プライバシーサンドボックスの提案に関する利害関係者のエンゲージメントプロセスに関する四半期報告書を公に提供することに同意しました（コミットメントの段落 12 および 17(c)(ii) を参照）。 プライバシーサンドボックスに関するこれらのフィードバック要約報告書は、フィードバックの概要にリストされているさまざまなソースから Chrome が受け取った フィードバックを集計して生成されます。これらのソースには、GitHub の課題、privacysandbox.com で提供されているフィードバックフォーム、業界関係者との会議、Web 標準フォーラムが含まれますが、これらに限定されません。 Chrome は、エコシステムからフィードバックを受け取り、そこから得た情報を設計上の決定に統合する方法を積極的に模索しています。
フィードバックのテーマは、API ごとの普及率によってランク付けされます。 これは、Chrome チームが特定のテーマについて受け取ったフィードバックの量を集計し、量を降順に整理することによって行われます。 一般的なフィードバックのテーマは、公開会議（W3C、PatCG、IETF）、直接受けたフィードバック、GitHub、および Google の内部チームと公開フォームを通じて提示される一般的な質問からのディスカッションのトピックを確認することによって特定されました。
より具体的には、ウェブ標準機関の会議の議事録がレビューされ、直接フィードバックについては、Google の 1 対 1 で行われた関係者会議の記録、個々のエンジニアが受信したメール、API メーリングリスト、および公開フィードバックフォームが考慮されました。 次に、Google は、これらのさまざまなアウトリーチ活動に関与するチームの間で調整を行い、各 API に関連して出現するテーマの相対的な普及率を決定した。
フィードバックに対する Chrome の対応の説明は、公開された FAQ、関係者によって提起された課題に対する実際の対応、およびこの公開報告活動の目的のための位置決めの決定から作成されました。 開発とテストの現在の焦点を反映して、特に Topics、Fledge、アトリビューション レポートの API とテクノロジーに関しての質問とフィードバックが寄せられています。
最近受け取ったフィードバックについては、まだ Chrome の対応が検討されていない可能性があります。
頭字語（略字）の用語集
- W3C
- ワールドワイドウェブコンソーシアム
- PatCG
- プライベートアドテクノロジーコミュニティグループ
- IETF
- インターネットエンジニアリングタスクフォース
- DSP
- デマンドサイドプラットフォーム
- SSP
- サプライサイドプラットフォーム
- OT
- オリジンライアル
- UA
- ユーザーエージェント文字列
- UA-CH
- User-Agent Client Hints
- IP
- インターネットプロトコルアドレス
- WIPB
- Willful IP Blindness
- IAB
- Interactive Advertising Bureau
- openRTB
- リアルタイム入札
- CHIPS
- Cookies Having Independent Partitioned State
- FPS
- First Party Sets
- FedCM
- Federated Credential Management
- IDP
- ID プロバイダー
すべてのフィードバックソースに見られる共通のテーマ
ディスカッションとフィードバックチャネルに共通するテーマは、テストのタイミング、トラフィックレベル、および可用性に関する質問です。 特に、テスターは、API がいつテスト可能になるか、テストが世界的に利用可能になるかを常に確認したいと考えています。
このフィードバックに対処するために、Chrome はさまざまな伝達手段を使用してテストが世界的に公開されることを告知してきました。これと同じ内容については FAQ でも確認できるようにする意向です。 さらに、Chrome は CMA との協議の上、公開スケジュールを定期的に更新し続けたいと考えています。
関連するコンテンツと広告の表示
| API/テクノロジー | フィードバックのテーマ
（普及率でランク付け） |
質問と懸念事項の要約 | Chrome の対応 |
| Topics | 粗粒トピックの有用性 | 粗粒度の高いトピックの分類は、インタレストベース広告にはあまり有用でない可能性があるという懸念が提起されています。 | テストを通して API の有用性を探ります。 Chrome は、テスト結果に基づいて分類を進化させられることを期待しています。 |
| Topics | 分類 | 業界関係者は、分類に影響を与える発言権を持ちたいと考えています。 | Chrome は分類に関する意見を受け付けています。 Chrome は、分類法を変更するためのガバナンスモデルに関するフィードバックや、他の業界団体が長期的に分類法の開発と維持においてより積極的な役割を果たすことのできる方法についての議論に大きな関心を抱いています。 |
| Topics | さまざまなタイプのサイトでの有用性 | トラフィックのレベルやコンテンツの専門性に応じて、サイトの有用性について懸念が提起されています。 | テストを通して API の有用性を探ります。 Chrome は、テスト結果に基づいて分類法とその他のパラメーターを進化させられることを期待しています。 分類法またはパラメーターの進化には、下位互換性のない変更が不要な場合があります。 さらに、Chrome は、サードパーティCookie が廃止された後も、フィードバックから Topics API の進化への影響を得られ続けることを期待しています。 |
| Topics | サイト分類法 | サイトが Topics による分類を決定またはそれに影響を与えることができることが要求されています。 | Chrome はこの要求について調査していますが、サイトが「システムを悪用」してプライバシーを侵害する方法でユーザーをターゲットにしたり、広告の関連性を低下させたりする潜在的なリスクについての懸念を（ウェブブラウザコミュニティや DSP から）から耳にしています。 Chrome はフィードバックを求めており、潜在的な変更を検討しています。 |
| Topics | ノイズの多い信号 | ランダムなトピックを 5% 配信すれば、ノイズや誤った信号が増えすぎる可能性があります。 | ノイズはユーザーのプライバシーを保護するための重要な方法であり、ノイズのレベルとトピックの有用性はテストを通じて比較されます。 |
| Topics | サイト制御のサードパーティ権限 | サイドが Topics API を呼び出せるアドテクを選択できることが要求されています。 | 要求されているこの機能は、Explainer で述べられているとおり、「browsing-topics」権限ポリシーですでにサポートされています。 |
| Topics | Topics API がページのパフォーマンスに及ぼす影響 | Topics API に依存した結果、最初の広告が表示されるまでの遅延に関する懸念 | Chrome は、パフォーマンスを向上させるために HTTP リクエストヘッダーでの Topics のサポートの可能性について議論しています。 テストを通じて、そのような変更が必要かどうかを確認します。 |
| Topics | プライバシー /ポリシー | 一部のサードパーティがそれを呼び出す人とトピックを共有するかどうかを、呼び出し元別にレスポンスをフィルタリングする目的についての質問 | エコシステムの多くの人から受けたフィードバックに基づいて、Chrome は、情報へのアクセスを、他の方法ではその情報にアクセスできなかった者に制限するこの設計を選択しました。 もちろん、Topics を受け取るサイト運営者とサードパーティはそれぞれに、どの情報をサイトで共有するかを決定することができます。 このような共有を行う場合、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 | インタレストグループの制限 | ユーザーを追加できる、またはオークションに含められるインタレストグループの数に制限はありますか？ | Chrome は、フィードバックと測定されたレイテンシーの影響に基づいて、テスト期間中のウェブページのパフォーマンスやユーザーエクスペリエンスの理由から、これらの制限を調整することができます。 バイヤーとセラーがリソースの使用量を調整できるようにする追加の方法について、テスターの間で継続的な議論が行われています。 |
| FLEDGE | クロス API 機能 | アトリビューション レポートは FLEDGE とどのように連携しますか？ | 完全な詳細はまだ未定であり、Chrome は第 2 四半期にこれに関する更新を行う予定です。 Chrome は、オリジントライアルの期間中、オークションの結果（勝ち負け）に関するイベントレベルのレポートを引き続き提供する予定です。 |
デジタル広告の測定
| API/テクノロジー | フィードバックのテーマ
（普及率でランク付け） |
質問と懸念事項の要約 | Chrome の対応 |
| Attribution Reporting（およびその他の API） | トラフィックのテスト | テストに十分なトラフィックがあるかどうかが懸念される | Chrome は、ユーザーコントロールに重大なバグやイシューがないことを確認するために、非常に少ないトラフィックでオリジントライアルを開始しています。 初期のテスターは、API が技術的な観点から意図したとおりに機能していることを確認する上で重要な役割を果たします。これにより、より大きなトラフィックに迅速に立ち上がることが可能です。 API が期待どおりに機能しているという確信が持てれば、Chrome はユーティリティテストをサポートできるよう、オリジントライアルを増やす意向です。 |
| アトリビューション レポート | イベント登録のための人間工学 | サポートされているイベントの登録方法に関する質問。 | Chrome は、現在サポートされている登録方法を明確に示した回答を GitHub に公開しました。 Chrome は、エコシステムから現在の設計に関するフィードバックを収集し、提案された変更がこれらの懸念に十分に対応しているかどうか、またはさらなる更新が必要かどうかを確認しています。 |
| アトリビューション レポート | ノイズ生成 | 集計レポートでノイズがどのように生成されるかについてもっと詳しく知りたい。 | Chrome は、ノイズが生成される体系的な方法の詳細を提供するために、GitHub に回答を公開しました。 Chrome は、ノイズをシミュレートし、OT 中にさまざまなパラメーターでテストするためのライブラリを提供する予定です。 Chrome では、集計レポートモードに関する追加の開発者向けドキュメントとガイドも提供する予定です。 |
| アトリビューション レポート | 小規模サイトではデータの精度が低い | 小規模なサイトやキャンペーンでは、より精度の低いデータを受け取るのではないかと懸念されています。 | Chrome は、ノイズベースのプライバシー保護が小さなデータスライスに大きな影響を与えることを認識しています。 ただし、長期間にわたる集計などの方法でこの問題を解決できる可能性があります。また、非常に小さなデータスライス（1 つまたは2 つの購入など）に基づく結論が広告主にとって意味があるかどうかも不明です。 オリジントライアル中、Chrome は、テスターがこのイシューについてより具体的なフィードバックを提供できるように、さまざまなプライバシーとノイズのパラメーターを試す機能を活用することを推奨しています。 |
| アトリビューション レポート | コンバージョン遅延によるユーティリティへの影響 | コンバージョンの遅延がキャンペーンの設定と検証、またはキャンペーンの最適化を妨げるのではないかという懸念。 | Chrome は、コンバージョンレポートの遅延の影響について、相反するフィードバックを聞いています。 ただし、Attribution Reporting API では、ユーザーのプライバシーを保護するためにレポートにランダムな遅延が生じるため、Chrome はテスト期間中に特定のユースケースや懸念事項がより明確になることを期待しており、追加のデバッグサポートまたは開発者ガイダンスによって対処される可能性があります。 |
| アトリビューション レポート | 長い集計期間 | 30 日間の集計期間の延長に関するリクエスト | Chrome は、データの最小化と有用性の両方を考慮して、集計期間の長さに関するフィードバックを求める回答を公開しました。 |
| アトリビューション レポート | 視認できないインプレッション | 視認できないインプレッションがビュースルーコンバージョンレポートにカウントされるかどうかに関する質問。 | Chrome は、表示可能なインプレッションをより明確に説明する回答を Git Hub に公開しました。 |
隠されたトラッキングの制限
| API/テクノロジー | フィードバックのテーマ
（普及率でランク付け） |
質問と懸念事項の要約 | Chrome の対応 |
| ユーザーエージェントの削減 | パフォーマンス | Critial-CH（最初のページ読み込み時）を介してヒントを取得するレイテンシーが懸念されています。 | Chrome は、パフォーマンスを向上させる方法を検討しています。 |
| ユーザーエージェントの削減/User-Agent Client Hints | 不正防止/乱用防止に関する懸念 | サービス拒否を含む特定の種類の攻撃をデバッグする際には、できるだけ多くの情報を持つことが重要です。 UA 文字列からいくつかの情報を失うと、問題が発生する可能性があります。 | Chrome は、デバッグに役立つ十分な情報を提供しながら、プライバシーを維持する方法を議論し、評価しています。 |
| ユーザーエージェントの削減 | OT セットアップに関する混乱 | 複数のオリジントライアル参加者が、オリジントライアルへの登録方法の例を含むドキュメントを改善することを推奨しました。 | Reduced UA のオリジントライアルは終了しますが、Chrome はデプリケーション トライアルの指示（サンプルデモをより目立たせることを含む）を改善する予定です。 |
| ユーザーエージェントの削減 | 特定のヒントの価値に関する懸念 | Sec-CH-UA-Model がユーザーエージェント文字列の <deviceModel> と同じかどうかに関する質問。 | Sec-CH-UA-Model は、ユーザーエージェント文字列の <deviceModel> と同じです。 Chrome は、今後のドキュメントでこれをより明確にする予定です。 |
| ユーザーエージェントの削減 | デプリケーション トライアルへの登録に関する懸念 | 多数のドメインをデプリケーション トライアルに登録する方法に関する質問 | Chrome はデプリケーション トライアルを設計する際に集中型のアプローチを検討しましたが、Chrome はすべてのコントロールを開発者に与える既存のオリジントライアルが最良の選択肢であると考えています（開発者はヘッダーを送信するかどうかを選択できるため）。 |
| User-Agent Client Hints | UA-CH の規範的性質に関する懸念 | rfc7231 で定義されているように、User-Agent ヘッダーが提供する柔軟性と比較すると、UA-CHが過度に規範的であるという懸念があります。 | Chrome は、UA-CH ヘッダーの規範的な性質を、最終的なブラウザ間の相互運用性とユーザーのプライバシー保護（高エントロピー識別子の任意の追加を防ぐことによる）の両方の観点から、UA 文字列の柔軟性に対する重要な改善と見なしています。
ただし、他の人もこの懸念を抱えており、フィードバックの提供を希望する場合に備えて、イシューは未解決のままとなっています。 |
| User-Agent Client Hints | 特定のブラウザをブロックするために API が使用されているという懸念 | サイトが API を使用して「Google Chrome」または「Microsoft Edge」を探し、他のすべてのブラウザをブロックしているという懸念。 | ブランドリストのコンセプトは、このケースを処理するために設計されました。ブラウザは、自社のブランドに加えて「Google Chrome」を送信できます。 |
| User-Agent Client Hints | サポートされているすべてのヒントを列挙するメソッドのリクエスト | ブラウザでサポートされているすべてのヒントをプログラム的に知る方法に関心があります。 | Chrome は機能リクエストを評価中です。 |
| ユーザーエージェントの削減/User-Agent Client Hints | 不正防止/乱用防止に関する懸念 | クライアントヒントは HTTP1 の初回ロードでは利用できません | Client Hints Reliability API（ACCEPT_CH）の 1 つは、HTTP2 と HTTP3 でのみ使用できます。 まだ HTTP1 経由でサービスを提供しているサーバーの場合、Critial-CH のみに依存する必要があります。 |
| ユーザーエージェントの削減 | Android 版 Chrome への影響 | これが特に Android の Chrome にどのように影響するかについての質問 | UA Reduction と UA-CH は、デスクトップ版のほかに、Android 版の Chrome にも出荷されます。 Android 版 Chrome の場合、変更は Chrome 110 で現在予定されている「フェーズ6」でのみ行われます。 |
| Gnatcatcher（WIPB） | 不適合な用途と方法 | 不適合な使用と不適合な方法についての明確な説明 | Chrome は Explainer の詳細を更新する予定です。 |
| Gnatcatcher + ユーザーエージェントの削減 | 不正防止シグナルの軽減 | IP と UA アクセスを同時にに軽減した場合の不正防止の影響 | Willful IP Blindness 不正防止ポリシーの規定（不正防止のユースケースで IP を使用できるようにする）により、IP プロキシに関する防御性の懸念が解決されることが期待されています。 |
| ナビゲーショントラッキング | 将来の破損に関する懸念 | 広告主は潜在的な破損を懸念しており、ID プロバイダーも Chrome の計画に関心を示しています。 | Chrome は差し迫った変更を行っておらず、まだユースケースを模索中です。 |
| SameSite Cookie | 他のブラウザとの相互運用性 | crbug.com/1221316 は Chrome の実装が他のブラウザと異なる領域であるため、Chrome によるその修正計画に関する質問です。 | Chrome はメトリクスにバグを発見し、その結果新しいメトリクスを公開しました。 Chrome は、バグ修正の影響をよりよく理解するためにデータを収集しています。 |
| ストレージ分割 | メッセージチャネルの分割に関する懸念 | メッセージングチャネル（SharedWorker と BroadcastChannel）を分割する必要があるかどうかに関する質問。 | Chrome はフィードバックを評価していますが、隠されたトラッキングを防ぐには、ストレージとともにメッセージングチャネルを分割する必要があると考えています。 |
サイト間プライバシーの境界の強化
| API/テクノロジー | フィードバックのテーマ
（普及率でランク付け） |
質問と懸念事項の要約 | Chrome の対応 |
| First Party Sets | 共通のプライバシーポリシー要件 | すべての製品、および同じセットの一部である必要がある管轄区域にわたって共通のプライバシーポリシーを維持することは不可能です。 | Chrome はまだポリシー要件を定義中です。このフィードバックを念頭に置いておきます。 |
| First Party Sets | Independent Enforcement Entity（IEE）は、FPS の有効性に関する多数の課題を受ける可能性が高い | FPS の有効性を判断するための予測可能な課題の要約: テキストまたはプライバシーポリシーがセットメンバー間で一致しない、ユーザーが自明なセットメンバーシップの定義方法に関する明確さ、帯域幅とタイミングの課題、および企業構造に関する専門知識。 | Chrome はまだポリシー要件を定義中です。このフィードバックを念頭に置いておきます。 |
| First Party Sets | ブラウザの FPS リストを維持するプロセス | 非西欧諸国のウェブサイトへの参入障壁、更新ケイデンスの違いによるブラウザ間での FPS リストのバージョンの一貫性の欠如、および小型または新しいブラウザがリストを使用する能力に関する懸念。 | Chrome では、ポリシー要件、承認プロセス、リストの使用権をまだ定義中です。このフィードバックを念頭に置いておきます。
Chrome は、Public Suffix List など、ウェブプラットフォームで使用されている他の静的リストからの情報も調べる予定です。 |
| First Party Sets | サイトごとの動的アサーションの設計 | 動的設計（静的リストとは対照的）は、共通所有権の誤った主張や、ページ読み込みの遅延/失敗の傾向が強くなる可能性があります。 | Chrome は現在、静的リストアプローチを追求中です。 署名付きアサーションアプローチが将来的に再評価された場合は、このフィードバックを念頭に置いておきます。 |
| First Party Sets | First Party Sets の潜在的なユースケース（信頼できる公平なバージョンの FPS リストを作成できる場合） | シングルサインオン、カスタマイズ可能なデータプロンプト、ユーザーへの透明性レポートの強化の可能性。 | Chrome は、First Party Sets の次のステップを検討する際に、このフィードバックを考慮する予定です。 |
| CHIPS | ブラウザとの互換性 | 他のブラウザが分割された Cookie 属性をどのように処理したかを理解することへの関心 | Chrome は、複数のブラウザで動作する設計と実装を特定するために、W3C などの公開標準グループ内で取り組みを続けます。 |
| CHIPS | 設計要件 | __Host- 名の接頭辞を含めるのが現実的ではないかもしれないという懸念 | Chrome は、オリジントライアルでの命名要件を削除しました。テスト期間の終了時にこの削除を恒久的にするかどうかを検討します。 |
| CHIPS | 広告のユースケースでの CHIPS の使用 | 広告のユースケースで CHIPSを使用できるかどうかについての質問 | CHIPS では、サードパーティがトップレベルサイト（またはその First-Party Sets）に分割されたクライアントサイド Cookie を作成するができます。 ユースケースがクロスサイト状態ではなく分割の状態を必要とする場合、そのユースケースには CHIPS を使用できます。 |
| CHIPS | CHIPS と FPS の統合 | First Party Sets など、他のプライバシーサンドボックスの提案と並行して CHIPS をテストに使用することは不可能かもしれないという懸念 | Chrome は、そのようなテストを可能にするテスト環境を促進する方法を積極的に模索しています。 FPS のローカルテスト用の指示と、CHIPS に関する指示も公開しており、暫定的に使用することができます。 |
| FedCM | 明示性 | ブラウザは ID 連携フローの一部をレンダリングするため、IdP がユーザーに提示したいと思うニュアンスをすべて把握するのは困難であるという懸念 | Chrome はこのトレードオフを認識しており、エコシステムと連携して、可能な限り多くの分野をカバーし、可能な限り明示できるようにすることに取り組み続ける意向です。 Chrome は、ブランディングのカスタマイズ（ロゴ、色など）や文字列のカスタマイズ（「～でログイン」ではなく「この記事にアクセス」など）といったアイデアを検討中です。 |
| FedCM | ブラウザの関与 | ブラウザが以前よりも ID 連携フローに関与しているため、ユーザーがどのウェブサイトに（どの IDP を使って）ログインしているかをより明確に認識することが懸念されます。 | Chrome は、ブラウザがより積極的な役割を果たしていることを認識していますが、ID 連携をサポートしながら、ブラウザがクロスサイトトラッキングを区別して防止するには、この追加レベルの関与が必要です。 |
| FedCM | 適用性と相互運用性 | 他のブラウザが FedCM を採用または実装しないことへの懸念。 | Chrome は、FedID コミュニティグループで ID 連携のための共通ソリューションを見つけるために、他のブラウザベンダーとの協力にも努めています。 |
| FedCM | さまざまな API の課題 | FedCM はまだ早期段階または未熟であり、エコシステムが必要とするすべての機能を提供するのに長い時間がかかるだろうという懸念。 | Chrome は、エコシステムテストの一環としてこれをさらに調査する予定です。 |
| FedCM | エンタープライズポリシーとユーザーコントロール | 企業が ID 連携の展開を変更せずに維持できるようにするコントロール（エンタープライズポリシーやユーザー設定など）が提供されるかどうかに関する懸念 再デプロイまたは変更が特別に困難である ID 連携のオンプレミスデプロイが多いため、IdP の再デプロイを必要とする新しいブラウザ API に対して多くの抵抗があります。 | Chrome は、これらの懸念に対処できると考えているエンタープライズ管理者とユーザーのためのコントロールを模索中です。 Chrome は、特定のユースケースに関する企業からのフィードバックを歓迎しています。 |
スパムと詐欺への対抗
| API/テクノロジー | フィードバックのテーマ
（API ごとの普及率でランク付け） |
質問と懸念事項の要約 | Chrome の対応 |
| トラストトークン API | 償還限度 | 特に、同じページに数回埋め込まれている場合や、組織内に別の発行者ドメインがあるシナリオでは、1 ページあたり 2 個では制限が強すぎるという懸念があります。 他の市場参加者を考慮しなくても、自社で限界に達する可能性があります。 | Chrome は、採用が増えれば 1 ページあたりの償還上限をわずかに拡大する可能性がありますが、過剰なエントロピーを導入するためには比較的低く抑える必要があります。 さらに、償還レコードをキャッシュすることで、1 つの発行者が 1 人のユーザーに対して短期間で複数のトークンを引き換える必要性を減らすことができます。 |
| トラストトークン API | レイテンシー | 通常、入札リクエストには 10 ミリ秒以内に応答する必要があるため、最初のページの読み込み時にトークンを引き換えると、入札前の無効なトラフィックの決定を含めることがほぼ不可能になります。 | Chrome は、テストを通じて、レイテンシーが入札前のユースケースにどのように影響するかを理解しようとしています。 |
| トラストトークン API | OpenRTB の採用 | 入札前のユースケースでは、広告の決定に使用するために、引き換えられたトークン情報を SSP と DSP に渡すことが重要です。 | IAB は新しいデフォルトフィールドを追加するための標準を所有していますが、IAB と協力して、有用な不正防止/不正使用防止シグナルが OpenRTB を介して伝播できるようにすることに前向きです。 |
| トラストトークン API | プライバシー | エントロピーは少ない（約 2.5 ビット）にもかかわらず、あらゆる形態のクロスサイトデータ伝播の存続可能性が長期であることに関する質問 | ユニークユーザーの識別可能性を回避するための堅牢なユーザー保護を考えると、Chrome はエコシステムが受け入れるのに適したケースがあると考えています。 Chrome は主な関係者と緊密に協力して、長期的な存続可能性を確保することに努めています。 |
| プラットフォームアテステーションシグナル | 新しいアイデア/提案への関心を測定する | プラットフォームが提供できるデバイスインテグリティシグナルの伝達など、さまざまな実現可能な（および実行不可能な）シグナルの強力なサポート | Chromeは、フィードバックの新しいアイデアとして、このアイデアを W3C の不正防止コミュニティグループに持ち込む予定です。 |
| 不正防止のための信頼できるサーバー | 新しいアイデア/提案への関心を測定する | 興味深いコンセプトだが、おそらく適用可能なユースケースをさらに調査する必要がある | 関心の度合いに応じて、Chrome はこのコンセプトについてさらにアイデアを練り、今後のエコシステムフィードバックで使用する Explainer に含める可能性があります。 |