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

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

2022 年第 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、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 レスポンス
明確なスケジュール	プライバシーサンドボックステクノロジーのリリーススケジュールがより明確で詳細になりました。	privacysandbox.com で現在の導入スケジュールを策定し、毎月更新しています。これには、Chrome デベロッパーとウェブデベロッパーの両方の開発期間に加え、新しいテクノロジーのテストと導入に要する時間について、より広範なエコシステムから寄せられたフィードバックも考慮されています。各テクノロジーはテストからリリース（リリース）まで複数のステップを経て、各ステップのタイミングは前のステップで学習して明らかになった内容に基づいて決まります。現時点では確約したリリースはありませんが、privacysandbox.com で公開スケジュールは随時更新されます。
さまざまなタイプの関係者にとっての有用性	プライバシーサンドボックステクノロジーは大規模なデベロッパーに好まれ、ニッチな（小規模な）サイトが汎用的な（大規模な）サイトよりも多くの貢献をするのではないかという懸念。	デベロッパーによっては、プライバシーサンドボックス技術が及ぼす影響について懸念があることも理解しています。Google は CMA に対し、Google 自身のビジネスを自己優先することで競争をゆがめるような形でプライバシーサンドボックスの提案を設計または実装しないことを約束しています。また、デジタル広告とパブリッシャーおよび広告主との競争や、プライバシーの成果やユーザーエクスペリエンスへの影響も考慮に入れています。YouTube は、今後も CMA と緊密に連携し、Google の取り組みがこれらのコミットメントを遵守できるようにしていきます。プライバシーサンドボックスのテストが進むにつれ、Google が評価する主な質問の一つは、新しいテクノロジーがさまざまなタイプの関係者に対してどのように機能するかということです。この点においてフィードバックは重要です。特に、技術設計のさらなる改善に役立つ具体的で実用的なフィードバックは重要です。
サードパーティ Cookie のサポート終了スケジュール	サードパーティ Cookie のサポート終了に伴うさらなる遅延を回避するリクエスト	Chrome でサードパーティ Cookie の廃止を遅延なく進めてほしいという関係者から、プライバシーサンドボックス技術のテストと導入にさらに時間が必要だという意見も寄せられています。テクノロジーは複雑であり、物事を正しく行うためのエコシステムにとって重要なため、Google は責任を持って取り組みを進めています。このプロセスには、業界と規制当局からのフィードバックが不可欠です。
サードパーティ Cookie のサポート終了スケジュール	サードパーティ Cookie のサポート終了を延期し、API のテスト期間延長のリクエスト。	Chrome でサードパーティ Cookie の廃止を遅延なく進めてほしいという関係者から、プライバシーサンドボックス技術のテストと導入にさらに時間が必要だという意見も寄せられています。テクノロジーは複雑であり、物事を正しく行うためのエコシステムにとって重要なため、Google は責任を持って取り組みを進めています。このプロセスには、業界と規制当局からのフィードバックが不可欠です。
ドキュメントのリクエスト	テスト、分析、実装の管理方法について詳しく説明したリソースのリクエストです。	現在公開している資料が皆様のお役に立てば幸いです。Google は今後数週間から数か月かけて、デベロッパーオフィスアワーや技術ドキュメントなど、より多くの資料を提供していく予定です。これにより、デベロッパーは新しいテクノロジーがどのように役立つかを理解できます。また、ベストプラクティスやデモを共有する一般公開の外部デベロッパーオフィスアワーセッションや、プロダクト/エンジニアリングリーダーとの Q&A セッションを実施し、ライブでディスカッションや質問を行う機会を設けました。
業界の専門知識	標準化団体に関与する Chrome チームには、プライバシーと実用性の適切なバランスに必要な広告エコシステムに関する専門知識が不足しています。	Google には大きな責任があると認識しており、これを適切に進めるには個別のフィードバックに依存しています。また Google は、プライバシーと有効性の両方を重要かつ必要な設計基準と考えています。ウェブ版プライバシーサンドボックスに取り組んでいるチーム全体では、広告エコシステムで働いた総年数は数百年にも満たないでしょう。

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

トピック

フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
さまざまなタイプの関係者にとっての有用性	サイトのトラフィックレベルやコンテンツの特化度に応じた価値の創出や、その価値の分布について懸念が高まっています。	API の有用性は、テストを通じて検証されます。Chrome では、テスト結果に基づいて分類やその他のパラメータが進化することが想定されています。分類やパラメータの進化によって、下位互換性のない変更が不要になる場合があります。また Chrome では、サードパーティ Cookie のサポートが終了した後も、Topics API の進化に影響を与えるフィードバックが引き続き続くと予想しています。
分類	業界の関係者は、分類法に影響を与える声を求めています。	Chrome では分類に関する入力を受け付けています。Chrome では、分類を変更するためのガバナンスモデルに関するフィードバックや、長期的な分類法の開発と保守において他の業界団体がより積極的な役割を果たす方法に関する議論に大変興味を持っています。
十分な閲覧履歴がない	ユーザーの閲覧履歴が過去数週間の 5 つのトピックを作成できない場合に、発信者が過去数週間に閲覧したトピックを表示する提案	現在のデザインでは、ランダムに選択されます。Google は過去のトピックとの相関関係を調査して、これを組み込む可能性がないか検討しますが、相関関係はプライバシーへの悪影響を及ぼし、考慮に入れる必要があります。
パブリッシャーを代表して Topics を呼び出す	サードパーティサービスプロバイダはパブリッシャーと Topics を共有できますか？	はい、そのとおりに Topics が使用されることが想定されています。
潜在的な攻撃ベクトル	ノイズの多いトピックの特定	エコシステムの多くのユーザーからのフィードバックに基づき、Chrome ではトピックをフィルタしてノイズを取り入れることにしました。これらの決定はプライバシーに配慮して行われており、情報へのアクセスを、他の方法ではアクセスできない者に限定し、それぞれがユーザーにとってもっともらしい否定的なものとなるようにしています。Google は、このような決定には、こちらで説明されている攻撃ベクトルなどの欠点があることを認識しています。しかしながら、Google の評価では、プライバシーに関するメリットは潜在的なリスクを上回ると判断しています。この決定に関する公開討論を歓迎します。
オリジントライアルの利用資格	ユーザーがオリジントライアルの対象者かどうかを確認する方法はありますか？	ユーザーは、有効なトライアルトークンを提供するウェブページにアクセスし、そのブラウザがトライアルが有効になっているグループに含まれている場合でも、ブラウザの設定などの要因により、オリジントライアル機能をご利用いただけない場合があります。そのため、オリジントライアル機能を使用する前に必ず機能検出を使用して、オリジントライアル機能が利用可能かどうかを確認する必要があります。
パフォーマンスへの影響	Topics に関するオーバーヘッドとレイテンシの懸念事項	高額で遅い x-オリジン iframe を回避するアプローチや、トピックの取得によって閲覧状態が変化しないように Topics API の解明の提案について、フィードバックを募集しています。
Split Topics API 機能	API の 3 種類の機能をより詳細に制御	Google はユースケースを理解しており、GitHub 内でこれを解決するための方法を提案しています。この機能を組み込むかどうかについては、現在、エコシステムからのフィードバックを待っています。現在進行中の議論についてはこちらをご覧ください。
分類器のタイムラインとドキュメント	この分類器について、デベロッパーから詳しい情報のリクエストがありました。	分類器についての詳細情報は、こちらで公開されています。こちらのほか、こちらをご覧ください。
ユーザーコントロールと安全	あるトピックが機密グループのプロキシである場合があり、ユーザーは、ネガティブな結果を回避するためにより詳細な制御を必要とします。	トピックは、ユーザーによる制御と透明性のために大きな前進となります。ユーザーは、トピックをオプトアウトしたり、自分に割り当てられているトピックを確認したり、トピックを削除したり、特定のページでユーザーがトピックを利用している企業を把握したりできるようになります。また、ユーザーが閲覧履歴を削除して Topics に影響を与えることも可能です。より高度なユーザーコントロール（デベロッパーが提案したものなど）については引き続き議論を望みますが、このバグで提起された懸念について、実際にリスクが排除されることを確認する必要があります（たとえば、トピックの「外国語研究」のみを削除し、そのトピックを生成したウェブサイトがユーザーを完全に保護しないようにするなど）。
prebid.js を使用するサイトでトピックを使用する	prebid.js を使用するウェブサイトで Topics API を使用できますか？	一言で言えばイエスです。詳しくは、こちらをご覧ください。
レコメンデーションウィジェットでの Topics API の使用	おすすめウィジェットで Topics API を使用できますか（Outbrain など）。	API が呼び出された後で取得されるトピックのユースケースは制限されません（これは各デベロッパーのデータポリシーによって異なります）。
プライバシー / ポリシー	一部のサードパーティが通話の相手とトピックを共有する場合、発信者で応答をフィルタする目的に関する質問。	エコシステムの多くのユーザーからのフィードバックに基づき、Chrome では情報へのアクセスが、他の方法ではアクセスできないユーザーのみに限定されるようにこの設計を採用しました。もちろん、Topics を受け取るパブリッシャーやサードパーティは、サイトでどの情報をパーティと共有するかを自身で決めることができます。共有する場合は、ユーザーに対して透明性を確保し、ユーザーが自分で管理できるようにすることを強く推奨します。
ノイズとなる信号	5% の確率でランダムなトピックを配信すると、ノイズが多くなりすぎたり、誤ったシグナルが生成されたりする可能性があります。	ノイズはユーザーのプライバシーを保護するための重要な手法です。ノイズレベルとトピックの有用性については、テストを通じて検証していきます。

FLEDGE

フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
テストの調整	パフォーマンスと収益への影響をテストする	FLEDGE のパフォーマンス、およびオリジントライアル中のエコシステムテストや一般提供の最適なサポート方法については、公開の WICG 会議で活発に議論されています。
FLEDGE の信頼できるサーバー	信頼できるサーバーがテストに利用できるようになるのはいつですか？	Google は、こうしたフィードバックに感謝しています。FLEDGE で信頼できるサーバーを使用するための詳細な計画を現在公開中です。
プロトコルの標準化	インタレストグループの共通ラベルなど、SSP と DSP 間でデータを受け渡すための共通プロトコルはありますか？	仕様の標準化の可能性について、DSP や SSP、そしてより広範な広告エコシステムからのフィードバックを歓迎します。現時点では、テストパートナーがさまざまなアプローチをテスト中であるため、初期テストではテストパートナーと直接連携することをおすすめします。Google はまた、広告取引団体がメンバー企業に役立つ場合に備えて、標準化の策定に加わることを奨励し、今後も連携していく予定です。
フリークエンシーキャップ	キャンペーンと広告グループにおけるユーザーごとのフリークエンシー管理。	FLEDGE は、デバイス上のオークションとコンテキスト / ブランディングキャンペーンでもフリークエンシーキャップをサポートします。共有ストレージとサイトごとの上限は、追加のフリークエンシーキャップ制御にも使用できます。
FLEDGE がパフォーマンスに及ぼす影響	FLEDGE オークションで計算負荷の高いビッダー	Chrome では、サイトのパフォーマンスに及ぼす影響について、デベロッパーと活発に議論しています。Chrome では、テスト中により多くのことを学ぶ機会を歓迎します。
他の機能との FLEDGE のテスト	Attribution Reporting API と FLEDGE のイベントレベルレポートはどのように連携しますか？	この件については、最近の WICG/conversion-measurement-api 内の通話で、詳しい議事録へのリンクをこちらから説明しました。今回の会議をまとめると、現在の Fenced Frames Ad Reporting の設計では、Fenced Frame 内で生成された ID をコンテキスト情報に関連付けることが可能となっています。したがって、フェンス付きフレーム内で生成されたイベントレベルレポートを、サーバー上の同じコンテキスト情報に結合できるようになります（サーバー側の結合を 1 つではなく 2 つ使用します）。
インプレッション数のカウント	購入者と販売者の間で使用すべき、または使用できるインプレッションのカウント方法はどれですか。	FLEDGE API は、オークションにおいて販売者と購入者の間で行われる手法の調整をすでにサポートしています。他の実装についての提案もいただいていましたが、現在の設計がエコシステムで機能しない理由についてはフィードバックを提供していません。
複数の広告の表示	特定のフェンス付きフレームの 1 つのオークションで複数の広告を表示できるかどうか	現時点ではコンポーネント広告を介して行うことができます（コンポーネントオークションとは異なります）。そのためには、すべての広告が同じインタレストグループに含まれている必要があります。
「販売者定義オーディエンス（SDA）」の仕様と FLEDGE	FLEDGE は、購入者が広告リクエストで SDA からプロファイルを作成するのを防ぐことができるメカニズムになるのでしょうか？	FLEDGE は、パブリッシャーがすでにサイト訪問者の SDA を把握し、ターゲットが同じサイトである場合に、関係のない情報漏洩を防ぐように設計されています。FLEDGE に組み込まれているすべての保護設定で SDA での購入をサポートすることが重要な場合は、販売者が SDA ラベルをデバイス上のオークションに渡すという解決策と、バイサイド広告テクノロジーが入札ロジックに「オーディエンス X を購入したい」という独自のインタレストグループを作成するという解決策があるかもしれません。
米ドル以外の通貨のサポート	米ドル以外の通貨での FLEDGE のテストをサポート	このコールアウトは、機能リクエストのバックログに他の通貨のサポートを追加しています。近日中にご利用いただけることを願っております。
除外インタレストグループターゲティングのサポート	除外 IG ターゲティングをサポートする API: ユーザーが IG に属していない場合にのみ広告を表示します。	GitHub の問題で、サポートするための提案されたオプションを含む継続的な議論。
FLEDGE の複数の SSP	FLEDGE でマルチレベルオークションを実装するときに Google が優先されるリスク	公正かつ公平な競争の場を提供するために、FLEDGE で複数の SSP のサポートを追加しました。Google はコミットメントに基づき、広告プロダクトおよびサービスを自己評価することで競争をゆがめるようなプライバシーサンドボックスの提案を設計、開発、実装しないことを約束しました。Google はこれを真摯に受け止めており、このテクノロジーの特定の側面に関するステークホルダーの懸念事項について、率直に話し合うことができます。詳細については、Chrome のコンポーネントオークションメカニズムをこちらで公開しています。

デジタル広告の測定

Attribution Reporting（とその他の API）

フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
マルチタッチアトリビューション	マルチタッチアトリビューションのサポートをリクエストするパブリッシャー	現在のマルチタッチアトリビューションの方法では、異なるウェブサイト間でユーザーのインプレッション（ひいてはアイデンティティ）を決定論的に関連付ける必要があります。そのため、現在の形式のこの機能はプライバシーサンドボックスの目標に合致しません。プライバシーサンドボックスは、クロスサイトトラッキングなしの主要な広告ユースケースをサポートすることを目的としています。個々のユーザーを追跡することなく、（重み付けされたランダム化された優先度を使用するなどして）クレジット割り当てを概算できる場合があります。
ノイズ生成	レポート内のノイズのレベルに関する質問	最初のテストでは、デベロッパーは独自のイプシロン値を設定して、ノイズのレベルに応じてレポートがどのように変化するかを体験できます。現在のところ、デベロッパーは epsilon=64 までのイプシロン値を選択できます。これは、特にデベロッパーが API を簡単にテストし、適切なイプシロン値について Google にフィードバックを提供できるようにするためです。また、そのようなフィードバックを求める一般公開リクエストもお送りしました。
テストの調整	ローカルテストツールを OT に使用できますか。	はい。OT の間はローカルテストツールを使用できます。ローカルテストツールは、サードパーティ Cookie が利用できる限り、デバッグレポートで使用できます。
クエリのエルゴノミクス	キーの集計のクエリを有効にする	プライバシーコストがほとんど、またはまったくない状態で、API のエルゴノミクスが改善されているように思えると思います。Google 側で提案を行い、それをサポートする価値があるという幅広いコンセンサスがあるかどうかを検討します。
小規模サイトのデータの精度は低下	小規模のサイトやキャンペーンでは、データの精度が低下する可能性があります。	Chrome では、ノイズベースのプライバシー保護は小さいデータスライスに大きな影響を与えることを認識しています。しかし、長期間にわたって集計するなどの手法で、この問題が解決する可能性があります。また、非常に小さなデータスライス（1、2 回の購入など）に基づく結論が広告主にとって有意かどうかも不明確です。Chrome では、オリジントライアル中、プライバシーとノイズに関する幅広いパラメータを試す機能を活用して、この問題に関してより具体的なフィードバックを提供できるようにテスターに推奨しています。

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

User-Agent の情報量削減

フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
bot 対策	UA-R による bot 対策への影響	お寄せいただいたフィードバックに感謝申し上げますとともに、今後の設計の参考にするため、現在、bot 保護アプローチに関する情報収集を進めております。
デプロイの依存関係	構造化ユーザーエージェント（SUA）のデプロイの依存関係への対応	Google では「フェーズ 4」をリリースしました。これは、Chrome 101 以降のすべてのユーザーに対してマイナーバージョンを削減するものです。更新情報はこちらをご覧ください。

User Agent Client Hints API

フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
サポートされているすべてのヒントの列挙	ブラウザでサポートされているすべてのヒントをプログラマティックに把握するための関心。	いただいたフィードバックに感謝いたします。現在、機能リクエストの審査を進めています。Google では、これが一般的なユースケースであるかどうかを把握したいと考えています。
UA-CH と User-Agent ヘッダーの柔軟性	rfc7231 で定義されているように、ユーザーエージェントヘッダーが提供する柔軟性に比べると、UA-CH は過度に規定的です。	Chrome は、最終的なブラウザ間の相互運用性とユーザーのプライバシー保護（高エントロピー識別子の任意の追加を防ぐことによる）の両方の観点から、UA-CH ヘッダーの規範的な性質が UA 文字列の柔軟性に対する重要な改善であると考えています。他のデベロッパーもこの事象を共有し、フィードバックを提供できるよう、事象は未解決のままです。
UA-CH: 不正防止 / 不正使用対策への懸念	UA-CH を介して利用できなくなる可能性がある機能: クリックリダイレクトトラッカー、不正なクリック。	担当チームが不正防止と測定の関係者と連携して、これらの潜在的な問題を調査しています。
パフォーマンス	Critical-CH 経由でのヒントの取得に遅延（最初のページの読み込み時）が懸念されています。	Chrome はパフォーマンスを改善する方法を調査しています。

Gnatcatcher（WIP）

フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
レイテンシに関する懸念	余分なホップを追加すると、レイテンシに影響する可能性があります。	Google では、2 ホッププロキシについて検討し、ユーザーのプライバシーとレイテンシの適切なバランスを見出す方法を模索しています。Google はフィードバックを歓迎し、さらに W3C フォーラムでディスカッションを歓迎します。
不正行為と bot からの保護	発展途上国を含む不正行為と bot 対策への影響	安全性は中核的な要件であり、Google では、IP アドレスのプロキシといった意味のある方法でユーザーのプライバシーを向上させる方法を探っています。評判の良い企業と提携している 2 ホッププロキシが検証可能なユーザープライバシーを提供します。また、ユーザーの信頼を伝えるための新しいシグナルのアイデアも検討しています。
地域のプライバシー法の遵守	国レベルの地理データレポートでは、より詳細な現地の制度へのコンプライアンスが困難になります。	Google は、提案する原則を公開しています。その中には、ウェブサイトが地域の要件に準拠し続けるための可能性のあるアプローチも含まれています。

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

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

フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
さまざまなタイプの関係者にとっての有用性	規模の大きいパブリッシャーと小規模のパブリッシャーにおける FPS の影響	プライバシーサンドボックスの主な目的は、現在の手法をクロスサイトトラッキングメカニズムに依存しないソリューションに置き換えることで、ユーザーのプライバシーを向上させることです。Google は、これらのソリューションが、さまざまな種類と規模のステークホルダーにできるだけ広く役立つことを願っています。これらのソリューションを改善する方法について、具体的かつ実用的なご意見をお待ちしています。今後もコミュニティでの議論とテストによって進化していくことが期待されます。
プライバシーの向上	同じセットに含まれるサイトが多すぎると、サードパーティ Cookie と同様の結果になる可能性があります	いただいたフィードバックに感謝いたします。現在、適切な制限について、あるいはどのような制限が必要かを検討しているところです。同時に、上限に達した場合の扱い方やシグナルを、ユーザーとデベロッパーの両方に提供するよう努めています。具体的な提案はまだありませんが、間もなく発表できる予定です。
FPS のエコシステムのサポート	プライバシー CG 以外の FPS の開発の継続に対するサポートと懸念事項	ファーストパーティセットの提案は PrivacyCG に残しておきたいところですが、引き続き WICG で提案を進めていきたいと考えています。また、ファーストパーティセットとそれが対処すべきユースケースの継続的な議論を支持する声明が多数寄せられたことからも刺激を受けました。Google は、ユーザーのプライバシーを保護し、尊重しながら、ウェブの成長と成功を支えるソリューションを見つけられるよう今後も尽力していきます。
ブラウザの相互運用性	他のブラウザでの実装	Google はデベロッパーにとってのブラウザの相互運用性の重要性を認識しており、引き続き他のブラウザと連携して FPS の標準化を追求していきます。
一般的なプライバシーポリシーの要件	すべてのサービスや地域の適用法令で共通のプライバシーポリシーを維持することは不可能です。	Chrome では現在もポリシー要件を定義しており、今後もフィードバックを念頭に置いて取り組んでまいります。

Fenced Frames API

フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
ドキュメントリクエスト	サンドボックス化された iframe との違い	フィードバックとご提案に感謝いたします。これについては GitHub で現在ディスカッション中です。リクエストについて最終的に明確化してから、リクエストを完全に評価できるようにしたいと考えています。公開ディスカッションはこちらでご覧になれます。
クロス API 機能	フェンス付きフレームでの Attribution Reporting のデフォルトサポート	Google は、Attribution Reporting API をデフォルトでフェンスフレームの「不透明広告モード」で可能にする提案についてフィードバックを募集しています。よろしければ、デベロッパーの皆様にも、ぜひディスカッションに参加されることをおすすめします。

Shared Storage API

フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
データの上限	パーティションごとに保存できるデータの量に制限はありますか？	はい、上限があります。詳しくは、GitHub の問題をご覧ください。ストレージの割り当てが必要です。現在の提案では、エントリごとのサイズ上限を 4 KB、キーと値の両方を 1,024 文字に制限し、送信元ごとのエントリ数の上限を 10,000 エントリとしています。これは、送信元の容量がいっぱいになったときに追加のエントリが commit されないようにするメカニズムを備えています。こちらで提案されている具体的な上限について、フィードバックを積極的に求めています。
ユーザーに対する透明性	データソースとデータ使用についてのユーザーの透明性	皆様からのフィードバックをお待ちしております。このアプローチは、検討する価値のある有望なアプローチであると考えております。具体的には、ユーザーに対して十分な透明性を提供する方法でこれが可能かどうかについて検討しています。

チップ

フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
導入の障害	CHIPS をホスト名にバインドする必要がありますか？（ドメイン不要の要件）	Google は、この要件によって複雑さが増し、CHIPS の採用の妨げとなっているという OT 参加者からのフィードバックに基づき、この要件を OT から削除します。この要件については、こちらで、標準策定の一環としてプライバシーコミュニティグループで検討します。
CHIPS の広告ユースケース	1 つのサイトの広告ユースケースに CHIPS を使用できますか？	1 つのサイト内でのユーザートラッキングは許可されたユースケースです。このユースケースに焦点を当てるため、デベロッパー向け記事を更新しました。
認証済み埋め込み	ログイン状態は CHIPS で保持されますか？	ログイン状態は現在保持されませんが、CHIPS の想定されたユースケースではありません。Google は、認証済み埋め込みのユースケースを認識しており、解決に向けて取り組んでおります。
テストの調整	パーティショニングのテストに必要な追加のユーザー操作はありますか。	OT トークンが有効で、訪問したページのヘッダーに含まれている限り、ユーザーが追加の操作を行わなくても、そのトークンをユーザーが利用できるようにする必要があります。
ブラウザの互換性	分割された Cookie 属性が他のブラウザでどのように扱われているか知りたい。	Chrome は、W3C などのパブリック標準グループ内で引き続き、複数のブラウザをまたいだ設計と実装の検討に取り組みます。

FedCM

フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
潜在的な攻撃ベクトル	リンクデコレーション攻撃やタイミング攻撃による潜在的な攻撃ベクトル	Google では現在、この問題への対応策をできる限り公開して調査しています。
複数の IDP に対応する UX	同時に表示できる IDP は 1 つのみです	Google は複数の IDP をサポートすることを信条とし、サポートするアプローチに積極的に取り組んでいます。
表現手段	ブラウザはフェデレーション ID フローの一部をレンダリングするため、IDP がユーザーに提示したいニュアンスをすべて把握することは困難です。	Chrome では、ブランディングのカスタマイズ（ロゴ、色など）や文字列のカスタマイズ（たとえば、「ログイン ID」ではなく「この記事にアクセス」など）を検討しています。 Chrome はこのトレードオフを認識し、引き続きエコシステムと連携しながら、可能な限り多くの分野をカバーし、可能な限り表現力豊かなものにしていきます。
適用性と相互運用性	他のブラウザで FedCM が導入または実装されないことが懸念されます。	Chrome では、他のブラウザベンダーとも協力して、FedID Community Group で連携のための一般的なソリューションを探しています。
登録フローでの個人データ要件の削除に関する提案	（1）メールアドレス、写真、名前が共有されることを通知せずに、選択する IdP をユーザーに示す UX の方がプライバシーに優しい（2）ユースケースの登録では、ユーザーエクスペリエンスや IdP からのクレーム選択がスパースである	Google はこの内容に同意しており、よりユーザーとプライバシーに配慮した方法でフィードバックを実装するための方法を模索しています。
IdP でのユーザー操作	リスクしきい値を超えた場合にユーザーと IdP が直接やり取りする必要がある	このフィードバックについては、現在調査中です。

ネットワーク状態パーティショニング

フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
パフォーマンス	ネットワーク状態をパーティショニングすると、リソースを大量に消費する CDN への接続が増加する可能性があります。	現在、考えられるさまざまなキーイングスキームの測定など、ネットワーク状態パーティショニングのパフォーマンス特性について調査中です。パフォーマンス、セキュリティ、プライバシーのトレードオフについてはまだ決定していないため、より多くのデータを収集する必要があります。

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

Trust Tokens API

フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
規制に関するフィードバック	規制機関から長期的な実行可能性に関する明確な兆候がないのに、トラストトークンに時間とリソースを投資することに対する懸念	Google の目標は、エコシステムで機能するテクノロジーを構築し、そのプロセスに不可欠な業界や規制当局からのフィードバックを得ることです。Google は、引き続き世界中の規制当局と協議しながら、プライバシーサンドボックスを開発し、トラストトークンを含む提案をデベロッパーに提供しています。すべての新しいテクノロジーと同様に、企業は規制要件の独自の評価に基づいて意思決定を行う必要があります。
リリースのタイミング	トラストトークンはいつ一般提供されますか？	現時点で提供予定については、privacysandbox.com で公開スケジュールが公開されています。一般提供日について最終決定が終わり次第、Chrome のリリースプロセスを通じて公開し、タイムラインをウェブサイトで更新します。
トラストトークンとその他のトークン	プライベートアクセストークンなど、標準化が進んでいる他のトークンに対して、トラストトークンが果たす役割	Google は標準化に関する議論に参加しており、それぞれの技術で実現するさまざまなユースケースを実現しながら、他の取り組みとできる限り連携することを目指しています。たとえば、トラストトークンとプライベートアクセストークンはどちらもプライバシーパスプロトコルに依存しています。
データの上限	トークンを利用する発行者が 1 ページあたり最大 2 人に制限される可能性がある。	Google は、トークンの利用に対するアクセスを分割することで、企業がユーザーエントロピーを増加させることなく安全にトークンを利用できるよう、長期的なオプションを探しています。
アクセス制限	トークンの存在を確認でき、利用できるのは、承認されている（検証済み/なりすましではない）オリジンのみです。	Google は、誰がトークンを表示して利用できるかについて、アプローチを検討しています。
デバイスのサポート	JavaScript ランタイムの依存関係は、特定のデバイスでの使用が制限されます。TT のサポートを他の種類のデバイスにも拡大できますか？	Google は今後の開発においてこの機能を検討しております。W3C フォーラムでデベロッパーの皆様からのフィードバックをお待ちしています。また、HTTP ヘッダーによってトリガーされたトークンの利用に関する未解決の問題もあります。フィードバックをお寄せください。
ユースケース	トラストトークンの適切なユースケースがどのようなものかが明確でない。使用目的が明確でない。	Google の目標は、不正防止分野でのイノベーションを促進し、各企業がトラストトークンを使用する独自の手法を使用している可能性があることを理解することです。そのため、使用目的に関する規定を定めていませんでした。試験運用や導入を検討されているパートナー様向けの出発点として、今後ドキュメントを拡張し、より多くの例を含める予定です。
トラストトークンのカバレッジ	この「trust-token-redemption」機能ポリシーを削除すると、トラストトークンの対象範囲が大幅に拡大します。	これは、OT からのフィードバックを収集して次のステップについて決定する際に考慮されます。
カード発行会社の信頼	トラストトークンを発行したウェブサイトを信頼すべきなのはなぜですか。	カード発行会社になるためのガイドラインはありません。誰でも発行できます。ニュースメディアは、信頼できる発行元のみと提携することを想定しています。さらに、広告エコシステムの他の正当な行為者が、疑わしいまたは不明な発行元に関連付けられたトラフィックを最終的に割引（または購入停止）する可能性もあります。
サードパーティの埋め込みサービス	サードパーティの組み込みサービスでトラストトークンを利用またはリクエストすることはできますか？	はい。サードパーティの埋め込みサービスでもトラストトークンの発行と利用を行うことができます。
カード発行会社のエコシステム	信頼シグナルを他の企業と共有できれば、より大きな実用性が得られる	トラストトークンは低レベルプリミティブとして設計されており、連携するカード発行会社/利用者が信頼/評価シグナルを共有するために使用できます。
メンテナンスのオーバーヘッド	トラストトークンオペレーションの基盤となる暗号実装は BoringSSL にあります。BoringSSL は Google が単独で保守しています。ライブラリのメンテナンスをどのように管理するか。	トラストトークンは、他のライブラリでも実装される可能性のある、標準化された暗号オペレーション（プライバシーパスプロトコルを参照）に依存しています。デベロッパーには、選択したライブラリでこれらのオペレーションのサポートをリクエスト、開発、維持することをおすすめします。
メンテナンスのオーバーヘッド	プロトコルバージョンがいつまでサポートされるかが明確でない	Google は、プロトコルバージョンの予想されるサポート期間について、より具体的な内容を作成、文書化する予定です。
カード発行会社の上限	より下位の階層では、トラストトークンを実行できない可能性があります。	トラストトークンを使用する組織が増えるにつれ、この種のタイミングの動きが顕著になり、考えられる解決策を調査しています。Google は、前述したように、ユーザーエントロピーを増大させることなく企業がトークンを安全に利用できるようにし、ページでの位置情報や読み込み順序の重要性を最小限に抑えることができる長期的なオプションを探しています。

インキュベーションにおける新しい不正対策ソリューション

フィードバックテーマ（有病率によるランク付け）	質問や懸念事項の概要	Chrome レスポンス
デバイスの完全性証明書シグナル	プラットフォームで証明され、ウェブで利用できる、デバイスの完全性シグナルを追求するための一般的に強力なサポート。	Google はこれからもフィードバックを収集し、公開設計とイテレーションを通じて提案追求していきます。
デバイスの完全性証明書シグナル	新しいシグナルを通じてユーザーエントロピーをどの程度伝達できるか、特定のユースケース（ユーザーが銀行にログインしている場合など）でエントロピーシグナルを増加させることが正当かどうかに関する質問。	Google では、ユーザーのプライバシー保護のため、ユーザーエントロピーをできるだけ少なくし、価値の高いシグナルを提供することを目指しています。
デバイスの完全性証明書シグナル	このシグナルによって、古いデバイスやオープンソース/改変されたプラットフォームへのアクセスが制限されますか？	新たなシグナルでは、開発における主要原則としてユニバーサルアクセスを考慮する必要があります。こうした点は、インキュベーションを続けるなかで事前に対処すべき重要な課題です。
デバイスの完全性証明書シグナル	新たなシグナルによって、セキュリティや不正防止の企業がブラウザやプラットフォームに過度に依存するかどうかが懸念されていました。	新しいシグナルはあくまで補足データであり、ブラウザからの「信頼」を示すものではありません。Google は、セキュリティ会社が引き続き独自のデータ、モデル、意思決定エンジンに頼り、デバイス認証を追加のインプットとして今後も活用することを期待しています。新しいシグナルが、エコシステム全体での検出機能を改善し、不正行為をより一層困難にすることを願っています。
Cookie のエイジシグナル	興味深いコンセプトですが、適用可能なユースケースについてさらなる調査が必要になる可能性があります。	関心レベルに応じて、Chrome ではこのコンセプトをさらに考案し、今後のエコシステムのフィードバック用に説明内容を作成する場合もあります。
不正防止のための信頼できるサーバー	興味深いコンセプトですが、適用可能なユースケースについてさらなる調査が必要になる可能性があります。	関心レベルに応じて、Chrome ではこのコンセプトをさらに考案し、今後のエコシステムのフィードバック用に説明内容を作成する場合もあります。

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