プライバシー サンドボックスの提案についてエコシステムから寄せられたフィードバックと Chrome の回答をまとめた、2022 年第 2 四半期の四半期レポート。
Google は CMA へのコミットメントの一環として、プライバシー サンドボックスの提案に関するステークホルダーのエンゲージメント プロセスについて、四半期ごとに公開レポートを提供することに同意しています（コミットメントの第 12 項と第 17 項（c）（ii）を参照）。これらのプライバシー サンドボックスのフィードバック概要レポートは、フィードバックの概要に記載されているさまざまなソース（GitHub の問題、privacysandbox.com で公開されているフィードバック フォーム、業界関係者とのミーティング、ウェブ標準フォーラムなど）から Chrome が受け取ったフィードバックを集計して生成されます。Chrome はエコシステムから寄せられたフィードバックを歓迎し、学んだことを設計上の意思決定に統合する方法を積極的に模索しています。
フィードバック テーマは、API ごとの発生頻度でランク付けされます。これは、特定のテーマについて Chrome チームが受け取ったフィードバックの量を集計し、量の降順で整理することで行われます。一般公開のミーティング（W3C、PatCG、IETF）、直接のフィードバック、GitHub、Google の社内チームと公開フォームから寄せられたよくある質問の議論のトピックを確認することで、一般的なフィードバック テーマを特定しました。
具体的には、ウェブ標準団体の会議の議事録が確認され、直接的なフィードバックについては、Google のステークホルダーとの 1 対 1 の会議の記録、個々のエンジニアが受け取ったメール、API メーリング リスト、一般公開のフィードバック フォームが検討されました。Google は、これらのさまざまなアウトリーチ アクティビティに関与するチーム間で調整を行い、各 API に関連して浮上したテーマの相対的な普及度を判断しました。
Chrome のフィードバックへの対応に関する説明は、公開されているよくある質問、関係者から寄せられた問題に対する実際の回答、およびこの公開レポートの目的のために特別に決定された立場に基づいて作成されています。現在の開発とテストの重点を反映して、特に Topics、Fledge、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
- W3C
- World Wide Web Consortium
- WIPB
- IP の故意の無視
一般的なフィードバック、特定の API/テクノロジーなし
| フィードバック テーマ （発生頻度順） |
質問と懸念事項の概要 | Chrome の対応 |
| より明確なタイムライン | プライバシー サンドボックス テクノロジーのリリース スケジュールをより明確かつ詳細に示します。 | デプロイ スケジュールに関する現在の計画は privacysandbox.com に掲載されており、毎月更新されます。これらのポリシーは、Chrome デベロッパーとウェブデベロッパーの両方の開発時間と、新しいテクノロジーのテストと導入に必要な時間について、幅広いエコシステムから寄せられたフィードバックを考慮して策定されています。各テクノロジーは、テストからリリース（リリース）まで複数のステップを経ます。各ステップのタイミングは、前のステップで得られた知見に基づいて決定されます。現時点ではリリースの予定はありませんが、privacysandbox.com で公開されているタイムラインを更新いたします。 |
| さまざまなタイプのステークホルダーにとっての有用性 | プライバシー サンドボックス テクノロジーが大規模なデベロッパーに有利であり、ニッチな（小規模な）サイトが一般的な（大規模な）サイトよりも貢献するという懸念。 | プライバシー サンドボックス技術の影響について懸念されているデベロッパーの皆様も多いと存じます。Google は、CMA に対して、Google 独自のビジネスを優先することで競争を歪める形でプライバシー サンドボックスの提案を設計または実装しないことと、デジタル広告における競争、パブリッシャーと広告主への影響、プライバシーの成果とユーザー エクスペリエンスへの影響を考慮することを約束しています。Google は、これらの取り組みが CMA の要請に準拠していることを確認するため、引き続き CMA と緊密に連携していきます。
プライバシー サンドボックスのテストが進むにつれて、Google は、さまざまなタイプの関係者にとって新しい技術がどのように機能するかを評価する重要な質問の 1 つとして、この点において、フィードバックは非常に重要です。特に、技術的な設計のさらなる改善に役立つ、具体的で実用的なフィードバックは重要です。 |
| サードパーティ Cookie のサポート終了のタイムライン | サードパーティ Cookie のサポート終了のさらなる遅延を回避するためのリクエスト | Chrome でサードパーティ Cookie のサポート終了を遅らせてほしくない、というご意見をいただいた一方で、プライバシー サンドボックス技術のテストと導入にもう少し時間が必要であるというご意見もいただきました。Google は、技術の複雑さと、エコシステムにとっての正確性の重要性を考慮し、責任を持って取り組んでまいります。このプロセスでは、業界や規制当局からのフィードバックが重要でした。 |
| サードパーティ Cookie のサポート終了のタイムライン | サードパーティ Cookie のデプリケーションの延期と、API のテストにさらに時間を確保するためのリクエスト。 | Chrome でサードパーティ Cookie のサポート終了を遅らせてほしくない、というご意見をいただいた一方で、プライバシー サンドボックス技術のテストと導入にもう少し時間が必要であるというご意見もいただきました。Google は、技術の複雑さと、エコシステムにとっての正確性の重要性を考慮し、責任を持って取り組んでまいります。このプロセスでは、業界や規制当局からのフィードバックが重要でした。 |
| ドキュメントのリクエスト | テスト、分析、実装を管理する方法について詳しく説明しているリソースの追加リクエスト。 | デベロッパーの皆様が現在の資料を役に立つと評価してくださっていることを感謝いたします。今後数週間から数か月の間に、デベロッパーが新しいテクノロジーを活用する方法を理解できるよう、デベロッパー向けの相談時間や技術ドキュメントなど、より多くの資料を提供していく予定です。
また、外部デベロッパー向けの公開オフィスアワー セッションも開催し、ベスト プラクティスやデモを共有しました。また、プロダクト リードとエンジニアリング リードとの Q&A セッションも開催し、ライブでのディスカッションや質問を可能にしました。 |
| 業界の専門知識 | 標準化団体と連携している Chrome チームには、プライバシーと有用性の適切なバランスを取るために必要な広告エコシステムに関する専門知識がありません。 | Google は、大きな責任を負っていることを認識しており、適切に機能するよう具体的なフィードバックをお待ちしております。また、プライバシーと有効性の両方を、重要な設計基準と考えています。ウェブ向けプライバシー サンドボックスの開発チーム全体で、広告エコシステムでの経験年数は合計で数百年に上ります。 |
関連性の高いコンテンツと広告を表示する
トピック
| フィードバック テーマ （発生頻度順） |
質問と懸念事項の概要 | Chrome の対応 |
| さまざまなタイプのステークホルダーにとっての有用性 | サイトのトラフィックのレベルやコンテンツの専門性によっては、サイトが創出する価値とその価値の分配について懸念が提起されています。 | API の有用性はテストを通じて確認されます。Chrome では、分類とその他のパラメータがテスト結果に基づいて進化することが想定されています。分類やパラメータの進化に伴い、下位互換性のない変更が必要になる場合があります。また、サードパーティ Cookie のサポート終了後も、フィードバックが Topics API の進化に影響を与え続けることが予想されます。 |
| 分類 | 業界関係者は、分類に影響を与える意見を述べたいと考えています。 | Chrome では、分類に関する入力を受け付けています。Chrome は、分類の変更に関するガバナンス モデルに関するフィードバックと、他の業界団体が分類の長期的な開発と維持においてより積極的な役割を果たす方法に関する議論に非常に関心を持っています。 |
| 閲覧履歴が十分でない | ユーザーの閲覧履歴が十分で、直近の 1 週間のトピックを 5 つ作成できない場合に、呼び出し元が過去に閲覧したトピックを表示するプロポーザル | 現在の設計では、ランダムに選択されます。過去のトピックとの関連性を調査し、これを組み込む可能性を検討しますが、関連性によっては、考慮すべきプライバシーに関する悪影響が生じる可能性があります。 |
| パブリッシャーに代わって Topics を呼び出す | サードパーティのサービス プロバイダは、パブリッシャーと Topics を共有できますか？ | はい。Topics は、そのように使用することを想定しています。 |
| 潜在的な攻撃ベクトル | ノイズの多いトピックの特定 | Chrome は、エコシステム内の多くのユーザーからのフィードバックに基づいて、トピックをフィルタしてノイズを導入することを選択しました。これらの決定は、プライバシーを念頭に置いて行われました。つまり、情報へのアクセスを、それ以外ではアクセスできないユーザーに限定し、ユーザーに合理的な否認の余地を与えることを目的としています。こうした決定には、こちらに記載されている攻撃ベクトルなど、デメリットがあることを認識しています。ただし、プライバシー上のメリットが潜在的なリスクを上回ると判断しています。この決定について、公開討論を歓迎いたします。 |
| オリジン トライアルの利用資格 | ユーザーがオリジン トライアルの対象かどうかを検出する方法はありますか？ | 有効なトライアル トークンを提供するウェブページにアクセスしていて、トライアルが有効になっているグループにブラウザが含まれている場合でも、ブラウザの設定などの要因により、ユーザーがオリジン トライアル機能を利用できない場合があります。 そのため、オリジン トライアル機能を使用しようとする前に、必ず機能検出を使用して、その機能が利用可能かどうかを確認する必要があります。 |
| パフォーマンスへの影響 | Topics のオーバーヘッドとレイテンシに関する懸念事項 | 費用と時間のかかる x-origin iframe を回避する方法と、トピックの取得によってブラウジング状態が変更されないように Topics API を分離する提案について、フィードバックを募集しています。 |
| Topics API の機能の分割 | API の 3 つの異なる側面をより細かく制御できる | Google はユースケースを理解しており、GitHub 内でこの問題を解決するための方法を提案しています。現在、この機能を構築するかどうかについて、エコシステムからのフィードバックを待機しています。進行中のディスカッションについては、こちらをご覧ください。 |
| 分類器のタイムラインとドキュメント | デベロッパーから分類システムに関する詳細情報が求められています。 | 分類システムについて詳しくは、こちらをご覧ください。 こちらもご覧ください。 こちらもご覧ください。 |
| ユーザー コントロールと安全性 | 特定のトピックはデリケートなグループの代用となる可能性があるため、ユーザーはネガティブな結果を防ぐためにより多くの管理を必要とします。 | Topics は、ユーザーによる管理と透明性の向上に向けた大きな一歩です。ユーザーは、トピックの無効化、割り当てられたトピックの確認、トピックの削除、特定のページでトピックを操作している企業の確認を行うことができます。また、ユーザーは閲覧履歴を削除することで、トピックに影響を与えることもできます。デベロッパーから提案されたような、より高度なユーザー コントロールについて引き続き議論を歓迎しますが、このバグで提起された懸念事項について、実際にリスクが除去されるようにする必要があります（たとえば、トピック「外国語学習」のみを削除し、そのトピックを生成するウェブサイトをブラウジング履歴から削除しても、ユーザーは完全に保護されません）。 |
| prebid.js を使用するサイトでのトピックの使用 | prebid.js を使用しているウェブサイトで Topics API を使用できますか？ | 簡潔に言うと、はい。詳しくは、こちらをご覧ください。 |
| おすすめウィジェットでの Topics API の使用 | おすすめウィジェット（Outbrain など）で Topics API を使用できますか？ | API の呼び出し後に取得されたトピックのユースケースは制限されません（これは各デベロッパーのデータ ポリシーによって異なります）。 |
| プライバシー / ポリシー | 通話相手によって回答をフィルタする目的、一部のサードパーティが通話相手とトピックを共有するかどうかに関する質問。 | Chrome では、エコシステム内の多くのユーザーから寄せられたフィードバックに基づいて、情報へのアクセスを、本来はアクセスできないユーザーに限定する設計を選択しました。もちろん、Topics を受け取るパブリッシャーとサードパーティは、サイト上でどの情報を共有するかを自ら決定できます。このような共有を行う場合は、そのような共有についてユーザーに透明性を提供し、ユーザーが管理できるようにすることを強くおすすめします。 |
| ノイズの多いシグナル | 5% の確率でランダムなトピックを配信すると、ノイズや誤ったシグナルが多すぎる可能性があります。 | ノイズはユーザーのプライバシーを保護する重要な方法であり、ノイズレベルとトピックの有用性はテストを通じて検討されます。 |
FLEDGE
| フィードバック テーマ （発生頻度順） |
質問と懸念事項の概要 | Chrome の対応 |
| 調整のテスト | パフォーマンスと収益への影響をテストする | FLEDGE のパフォーマンスと、オリジン トライアルと一般提供中のエコシステム テストを最適にサポートする方法については、公開 WICG ミーティングで積極的に議論されています。 |
| FLEDGE の信頼できるサーバー | 信頼できるサーバーはいつからテストできますか？ | ご意見ありがとうございます。FLEDGE で信頼できるサーバーを使用する方法について、より詳細な計画を共有できるよう現在積極的に取り組んでおります。 |
| プロトコルの標準化 | SSP と DSP 間でデータを渡すための共通プロトコル（インタレスト グループの共通ラベルなど）はありますか？ | 仕様の標準化について、DSP、SSP、広告エコシステム全体からフィードバックをお待ちしております。現時点では、テストパートナーがさまざまなアプローチをテストしているため、最初のテストについては、テストパートナーと直接連携することをおすすめします。また、広告業界団体と連携して、メンバー企業にとって有用な場合は標準化を推進することも推奨し、今後も連携していく予定です。 |
| フリークエンシー キャップ | キャンペーンと広告グループ内のユーザーごとのフリークエンシー管理。 | FLEDGE は、オンデバイス オークションとコンテキスト / ブランディング キャンペーンのフリークエンシー キャップもサポートします。共有ストレージとサイト固有の上限を使用して、フリークエンシー キャップの追加の制御を行うこともできます。 |
| FLEDGE によるパフォーマンスへの影響 | FLEDGE オークションでの計算負荷の高いビッダー | Chrome は、サイトのパフォーマンスへの影響についてデベロッパーと積極的に協議しています。Chrome では、テスト中に詳細を確認する機会を歓迎しています。 |
| FLEDGE と他の機能のテスト | Attribution Reporting API と FLEDGE のイベントレベル レポートはどのように連携しますか？ | この問題は最近の WICG/conversion-measurement-api のコールでも議論されました。詳細な議事録へのリンクはこちらです。 ミーティングの概要は、フェンスド フレーム広告レポートの現在の設計では、フェンスド フレーム内で生成された ID をコンテキスト情報に関連付けることができるというものです。そのため、フェンスド フレーム内で生成されたイベントレベルのレポートは、サーバー上の同じコンテキスト情報に結合できます（1 つではなく 2 つのサーバーサイド結合を使用）。 |
| インプレッション数のカウント | 購入者と販売者の間で使用すべき、または使用できるインプレッション数のカウント方法 | FLEDGE API は、オークション中に販売者と購入者の間で手法の調整をサポートしています。現在の設計がエコシステムで機能しない理由に関するフィードバックなしで、代替の実装に関する提案が寄せられています。 |
| 複数の広告の表示 | 特定のフェンス付きフレーム内の 1 回のオークションで複数の広告を表示できるかどうか | 現在、コンポーネント広告（コンポーネント オークションとは異なります）でこのことができます。これを行うには、すべての広告が同じインタレスト グループに含まれている必要があります。 |
| 「Seller Defined Audiences（SDA）」の仕様と FLEDGE | FLEDGE は、広告リクエストで SDA からプロファイルを作成できないようにするメカニズムとして機能しますか？ | FLEDGE は、パブリッシャーが訪問者がどの SDA に属しているかをすでに把握しており、ターゲティングが同一サイトの場合に、関連性のない情報漏洩を回避するように設計されています。FLEDGE に組み込まれているすべての保護機能内で SDA での購入をサポートすることが重要である場合、販売者が SDA ラベルをデバイス上のオークションに渡し、購入側の広告テクノロジーが「オーディエンス X を購入したい」という入札ロジックを持つ独自のインタレスト グループを作成する方法が考えられます。 |
| 米ドル以外の通貨のサポート | 米ドル以外の通貨での FLEDGE テストのサポート | ご指摘いただきありがとうございます。他の通貨のサポートは、機能リクエストのバックログに追加されています。まもなくご利用いただけるよう取り組んでおります。 |
| インタレスト グループのターゲット除外のサポート | 除外 IG ターゲティングをサポートする API: ユーザーが IG に属していない場合にのみ広告を表示します。 | GitHub の問題で、サポートの提案されているオプションなど、継続的な議論が行われています。 |
| FLEDGE での複数の SSP | FLEDGE でマルチレベル オークションを実装する際に Google を優遇するリスク | 公平で平等な競争環境を実現するため、FLEDGE で複数の SSP のサポートが追加されました。Google は、自社の広告プロダクトとサービスを優先することで競争を歪める方法でプライバシー サンドボックスの提案を設計、開発、実装しないことを、このコミットメントで約束しています。Google はこうした懸念を真摯に受け止めており、技術の特定の側面についてステークホルダーが抱く懸念について、オープンに議論しています。なお、コンポーネント オークション メカニズムについては、こちらに公開ドキュメントがあります。 |
デジタル広告の測定
Attribution Reporting（およびその他の API）
| フィードバック テーマ （発生頻度順） |
質問と懸念事項の概要 | Chrome の対応 |
| マルチタッチ アトリビューション | マルチタッチ アトリビューションのサポートをリクエストしているパブリッシャー | 現在のマルチタッチ アトリビューションの方法では、複数のウェブサイトにわたるユーザーのインプレッション（および ID）を決定論的に関連付ける必要があります。そのため、現在の形では、この機能はクロスサイト トラッキングなしで主要な広告ユースケースをサポートすることを目的とするプライバシー サンドボックスの目標と合致していません。場合によっては、個々のユーザーをトラッキングしなくても、クレジットの割り当てを近似的に行うことができます（重み付けされたランダムな優先度を使用するなど）。 |
| ノイズ生成 | レポート内のノイズレベルに関する質問 | 最初のテストでは、デベロッパーが独自のエプシロン値を設定できるようにし、ノイズレベルに応じてレポートがどのように変化するかを体験できるようにしています。現在、デベロッパーは epsilon=64 までのエプシロン値を選択できます。これは、デベロッパーが API を簡単にテストし、適切なイプシロン値に関するフィードバックを Google に提供できるようにするためです。 また、このようなフィードバックを求める公開リクエストも行っています。 |
| 調整のテスト | ローカル テストツールを OT に使用できますか？ | はい。ローカル テストツールは OT 期間中も使用できます。ローカルテストツールは、サードパーティ Cookie が使用可能な限り、デバッグ レポートで使用できます。 |
| クエリのエルゴノミクス | キーの集計のクエリを有効にする | プライバシーに影響を与えることなく、API の使い勝手が向上すると思われます。提案を行い、サポートする価値があるという幅広いコンセンサスがあるかどうかを確認します。 |
| 小規模なサイトではデータの精度が低下する | サイトやキャンペーンの規模が小さい場合は、データの精度が低下する可能性があります。 | Chrome では、ノイズベースのプライバシー保護が小さいデータスライスに与える影響が大きいことを認識しています。ただし、長期にわたる集計などの方法でこの問題を解決できる可能性もあります。また、非常に小さなデータスライス（1 回または 2 回の購入など）に基づく結論が広告主にとって有意義であるかどうかも不明です。オリジン トライアルでは、幅広いプライバシー パラメータとノイズ パラメータをテストして、この問題についてより具体的なフィードバックを送信することをテスターにおすすめします。 |
隠れたトラッキングの制限
ユーザー エージェント文字列削減
| フィードバック テーマ （発生頻度順） |
質問と懸念事項の概要 | Chrome の対応 |
| bot 対策 | UA-R によるボット対策への影響 | ご意見ありがとうございます。Google は、今後の設計に反映できるよう、ボット対策のアプローチに関する情報を収集しています。 |
| デプロイの依存関係 | 構造化ユーザー エージェント（SUA）のデプロイの依存関係に対処する | 「フェーズ 4」をリリースしました。これは、バージョン 101 以降の Chrome ユーザーの 100% を対象としたマイナー バージョンの削減です。最新情報はこちらをご覧ください。 |
User-Agent Client Hints
| フィードバック テーマ （発生頻度順） |
質問と懸念事項の概要 | Chrome の対応 |
| サポートされているすべてのヒントを列挙する | ブラウザでサポートされているすべてのヒントをプログラマティックに把握できる方法に関心がある。 | フィードバックをお寄せいただきありがとうございます。現在、この機能リクエストを評価中です。これは一般的なユースケースであるかどうかを把握したいと考えています。 |
| UA-CH とユーザー エージェント ヘッダーの柔軟性 | UA-CH は、rfc7231 で定義されている User-Agent ヘッダーが提供する柔軟性と比較して、過度に規範的です。 | Chrome では、UA-CH ヘッダーの規範的な性質は、最終的なクロスブラウザ相互運用性とユーザーのプライバシー保護（高エントロピー識別子の任意の追加を防止）の両方の観点から、UA 文字列の柔軟性に対する重要な改善と見なしています。 他のユーザーもこの懸念を共有し、フィードバックを送信したい場合に備えて、この問題は引き続きオープンのままとなります。 |
| UA-CH: 不正行為 / 不正使用に関する懸念 | UA-CH で利用できなくなる機能: クリック リダイレクト トラッカー、不正なクリック。 | チームは、不正行為防止と測定の関係者と協力して、これらの潜在的な問題を調査しています。 |
| パフォーマンス | Critical-CH を介してヒントを取得する際のレイテンシ（最初のページ読み込み時）に関する懸念があります。 | Chrome では、パフォーマンスを改善する方法を調査しています。 |
Gnatcatcher（WIP）
| フィードバック テーマ （発生頻度順） |
質問と懸念事項の概要 | Chrome の対応 |
| レイテンシに関する懸念事項 | ホップを追加するとレイテンシに影響する可能性があります。 | YouTube は、2 ホップ プロキシを検討しており、ユーザーのプライバシーとレイテンシのバランスをとる方法を模索しています。フィードバックをお待ちしております。W3C フォーラムでさらにご意見をお聞かせいただければ幸いです。 |
| 不正行為や bot 攻撃の防止 | 不正行為や bot 攻撃の防止への影響（低開発国を含む） | Google は、IP アドレスのプロキシ化など、ユーザーのプライバシーを有意義に改善する方法を求めていますが、その際、安全性が主な要件となります。信頼できる企業と提携している 2 ホップ プロキシは、検証可能なユーザー プライバシーを提供します。また、ユーザーの信頼を示す新しいシグナルのアイデアも検討しています。 |
| 現地のプライバシー法への準拠 | 国レベルの地理データ レポートでは、より詳細なローカル規制への準拠が困難です。 | Google は、提案されている原則を公開しています。この原則には、ウェブサイトが現地の要件に準拠したまま維持できる可能性のあるアプローチが含まれています。 |
クロスサイト プライバシー境界の強化
ファーストパーティ セット
| フィードバック テーマ （発生頻度順） |
質問と懸念事項の概要 | Chrome の対応 |
| さまざまなタイプのステークホルダーにとっての有用性 | 小規模パブリッシャーと大規模パブリッシャーにおける FPS の影響 | プライバシー サンドボックスの主な目標は、現在の方法に代わるソリューションを導入し、クロスサイト トラッキング メカニズムに依存しない方法でユーザーのプライバシーを保護することです。Google は、これらのソリューションがさまざまな種類と規模のステークホルダーにできるだけ広く役立つようにしたいと考えています。これらのソリューションの改善方法について、具体的で実用的なご意見をお寄せください。これらのソリューションは、コミュニティでの議論とテストを通じて、引き続き進化していく予定です。 |
| プライバシーの強化 | 同じセットにサイトが多すぎると、サードパーティ Cookie と同様の結果になる可能性があります。 | Google は、このフィードバックに感謝いたします。Google は、適切な上限の有無や上限の設定について検討するとともに、ユーザーとデベロッパーの両方に、そのような上限に達したときに理解できるように処理やシグナルを提供しようとしています。現時点では具体的な提案はありませんが、近日中にご案内できる予定です。 |
| FPS のエコシステム サポート | プライバシー CG の外部で FPS の開発を継続するためのサポートと懸念事項の収集 | ファーストパーティ セットの提案は PrivacyCG に残しておきたかったのですが、WICG で提案を継続していく予定です。また、ファーストパーティ セットと、そのユースケースについて継続的に議論を重ねることへの多くの賛同の声もいただきました。Google は、ユーザーのプライバシーを保護し尊重しながら、ウェブの成長と繁栄を継続できるソリューションの開発に引き続き取り組んでまいります。 |
| ブラウザの相互運用性 | 他のブラウザによる実装 | Google は、デベロッパーにとってのブラウザの相互運用性の重要性を認識しており、FPS の標準化に向けて他のブラウザとも連携していきます。 |
| プライバシー ポリシーの一般的な要件 | すべてのプロダクトと、同じセットに含まれる必要がある法域で共通のプライバシー ポリシーを維持することは不可能です。 | Chrome では現在、ポリシー要件を定義しており、このフィードバックを参考にさせていただきます。 |
Fenced Frames API
| フィードバック テーマ （発生頻度順） |
質問と懸念事項の概要 | Chrome の対応 |
| ドキュメントのリクエスト | サンドボックス化された iframe との違い | フィードバックとご提案をお寄せいただきありがとうございます。現在、GitHub でこの件について議論しており、リクエストについて最終的な明確な結論を得て、完全に評価できるようにしたいと考えています。公開ディスカッションについては、こちらをご覧ください。 |
| クロス API 機能 | フェンスド フレームにおけるアトリビューション レポートのデフォルト サポート | フェンスされたフレームの「不透明広告モード」で Attribution Reporting API をデフォルトで許可するという提案について、フィードバックを求めています。この機能が有用と思われるデベロッパーの皆様は、ぜひこのディスカッションにご参加ください。 |
Shared Storage API
| フィードバック テーマ （発生頻度順） |
質問と懸念事項の概要 | Chrome の対応 |
| データの上限 | パーティションあたりに保存できるデータ量に制限はありますか？ | はい、制限があります。詳しくは、GitHub の問題をご覧ください。ストレージの割り当てが必要になります。現在の提案では、エントリあたりのサイズの上限を 4 KB とし、キーと値の両方を 1024 個の char16_t 文字に制限します。また、オリジンあたりのエントリの上限を 10,000 エントリとし、オリジンの容量がいっぱいになったときに追加のエントリが commit されないようにするメカニズムも用意します。こちらで提案されている具体的な上限について、フィードバックをお待ちしております。 |
| ユーザーに対する透明性 | データソースとデータ使用量に関するユーザーへの透明性 | フィードバックをお寄せいただきありがとうございます。このアプローチは検討に値する有望な方法であると考えています。特に、ユーザーに十分な透明性を提供できる方法でこの処理を行うことができるかどうかを評価しています。 |
CHIPS
| フィードバック テーマ （発生頻度順） |
質問と懸念事項の概要 | Chrome の対応 |
| 導入の障害 | CHIPS はホスト名にバインドする必要がありますか？（ドメインなしの要件） | この要件が複雑さを増し、CHIPS の導入の障害になっているという OT 参加者からのフィードバックに基づき、この要件を OT から削除します。
この要件については、標準化の初期段階として、プライバシー コミュニティ グループで議論します。 |
| CHIPS の広告のユースケース | CHIPS は、1 つのサイトでの Google 広告のユースケースに使用できますか？ | 1 つのサイト内のユーザー トラッキングは許可されたユースケースです。このユースケースを強調するため、 デベロッパー向けの記事を更新しました。 |
| 認証済みの埋め込み | CHIPS ではログイン状態が保持されますか？ | 現在、ログイン状態は保持されませんが、これは CHIPS の想定されるユースケースではありません。認証済みの埋め込みのユースケースについては認識しており、解決策を検討しています。 |
| 調整のテスト | パーティショニングをテストするために、ユーザーが行う必要がある追加の操作はありますか？ | OT トークンが有効で、アクセスしたページのヘッダーに存在する場合、ユーザーは追加の操作を行わなくてもこの機能を利用できます。 |
| ブラウザの互換性 | 他のブラウザがパーティション化された Cookie 属性をどのように処理しているかを理解したい。 | Chrome は、W3C などの公開標準グループ内で引き続き活動し、ブラウザ間で動作する設計と実装を特定しています。 |
FedCM
| フィードバック テーマ （発生頻度順） |
質問と懸念事項の概要 | Chrome の対応 |
| 潜在的な攻撃ベクトル | リンク装飾とタイミング攻撃による潜在的な攻撃ベクトル | Google は、一般の方からの意見を積極的に収集し、この問題に対処するための可能性のある方法を調査しています。 |
| 複数の IDP を許可する UX | 一度に提示できる IDP は 1 つだけです。 | Google は複数の IDP をサポートすることを重視しており、 |
| 表現力 | ブラウザが連携 ID フローの一部の処理を行うため、IDP がユーザーに提示したいニュアンスのすべてをキャプチャできないという懸念。 | Chrome では、ブランディングのカスタマイズ（ロゴ、色など）と文字列のカスタマイズ（「ログイン」ではなく「この記事にアクセス」など）の導入を検討しています。
Chrome はトレードオフを認識しており、できるだけ多くの範囲をカバーし、できるだけ表現力豊かにするために、エコシステムと連携して取り組んでまいります。 |
| 適用範囲と相互運用性 | 他のブラウザが FedCM を採用または実装しないのではないかという懸念。 | Chrome は、FedID コミュニティ グループで他のブラウザ ベンダーと連携して、連携のための共通ソリューションの検討にも取り組んでいます。 |
| 登録フローで個人データの要件を削除するよう提案 | （1）メールアドレス、写真、名前が共有されることをユーザーに示さずに、選択した IdP をユーザーに示す UX の方がプライバシーに配慮している （2）ユースケース - サインアップのユーザー エクスペリエンスと IdP からのクレームの選択が不十分です。 |
Google は、ユーザーのプライバシーに配慮しつつ、フィードバックをよりユーザー フレンドリーな方法で実装する方法を検討しています。 |
| ユーザーによる IdP の操作 | リスクしきい値を超えた場合に、ユーザーと IdP の間の直接的なやり取りが必要であること | このフィードバックについては現在調査中です。 |
ネットワーク状態パーティション
| フィードバック テーマ （発生頻度順） |
質問と懸念事項の概要 | Chrome の対応 |
| パフォーマンス | ネットワーク状態をパーティショニングすると、CDN へのリソース使用量の多い接続が増加する可能性があります。 | Google では、さまざまなキーング スキームの測定など、ネットワーク状態パーティショニングのパフォーマンス特性の調査を継続しています。Google は、パフォーマンス、セキュリティ、プライバシーのトレードオフについてまだ決定を下しておらず、さらにデータを収集する必要があります。 |
スパムや不正行為に対処する
Trust Tokens API
| フィードバック テーマ （発生頻度順） |
質問と懸念事項の概要 | Chrome の対応 |
| 規制に関するフィードバック | 長期的な存続可能性について規制当局から明確なシグナルがない状態で、トラスト トークンに時間とリソースを投資することへの懸念 | Google の目標は、エコシステムに役立つ技術を構築することであり、そのためには業界や規制機関からのフィードバックが不可欠です。Google は、プライバシー サンドボックスの開発と、信頼トークンを含む提案をデベロッパーに提供していくにあたり、引き続き世界中の規制機関と協議していきます。他の新しいテクノロジーと同様に、企業は規制要件に関する独自の評価に基づいて判断する必要があります。 |
| リリース時期 | Trust Tokens はいつ一般提供されますか？ | 現在のリリース予定については、privacysandbox.com の公開タイムラインでご確認ください。一般提供のリリース日について最終決定が下り次第、Chrome のリリース プロセスを通じて公開し、ウェブサイトのタイムラインを更新します。 |
| トラスト トークンとその他のトークン | プライベート アクセス トークンなど、標準化が進んでいる他のトークンがある場合、信頼トークンはどのような役割を果たしますか。 | Google は標準化の議論に積極的に参加しており、各技術が提供するさまざまなユースケースを可能にしながら、他の取り組みと可能な限り連携することを目標としています。たとえば、信頼トークンと限定公開アクセス トークンはどちらもプライバシー パス プロトコルに依存しています。 |
| データの上限 | トークン利用のカード発行会社はページあたり 2 社までで、制限される可能性があります。 | Google は、トークン利用へのアクセスを分割するなど、ユーザーのエントロピーを増やすことなく、企業がトークンを安全に利用できるようにする長期的なオプションを検討しています。 |
| アクセス制限 | 承認済み（および検証済み/なりすましではない参照元）のオリジンのみが、トークンの存在を確認して利用できます。 | トークンを表示および利用できるユーザーについて、現在検討中です。 |
| デバイスのサポート | JavaScript ランタイムの依存関係により、一部のデバイスでの使用が制限されます。TT のサポートを拡張して、他の種類のデバイスでも動作するようにすることはできますか？ | これは今後の開発で検討できる内容であり、W3C フォーラムでデベロッパーからフィードバックをいただければ幸いです。また、HTTP ヘッダーによってトリガーされるトークン利用について議論するオープンな問題もありますので、フィードバックをお寄せください。 |
| ユースケース | トラスト トークンの適切なユースケースが不明確です。想定される用途が明確でない。 | Google の目標は、不正行為防止分野におけるイノベーションを促進することです。各企業が独自の技術を信頼トークンとともに採用する可能性があることを理解しているため、Google は想定される用途について規定していません。ただし、テストや導入を検討しているパートナーの参考として、ドキュメントを拡充し、より多くの例を追加する予定です。 |
| トラスト トークンのサポート範囲 | この「trust-token-redemption」機能ポリシーを削除すると、信頼トークンのカバレッジが大幅に拡大します。 | これは、OT からフィードバックを収集し、次のステップについて決定する際に考慮されます。 |
| カード発行会社の信頼 | 信頼トークンを発行したウェブサイトを信頼する理由 | カード発行会社になるためのガイドラインはありません。誰でも発行できます。パブリッシャーは、信頼できるカード発行会社とのみ連携することが期待されます。また、広告エコシステム内の他の正当な事業者は、疑わしい発行元や不明な発行元に関連するトラフィックを最終的に割引（または購入を停止）することになります。 |
| サードパーティの埋め込みサービス | サードパーティの埋め込みサービスは、信頼トークンを取得またはリクエストできますか？ | はい。サードパーティの埋め込みサービスは、トラスト トークンを発行して利用できます。 |
| カード発行会社のエコシステム | 信頼シグナルを他の企業と共有できると、より多くのユーティリティを実現できます。 | Trust Tokens は低レベルのプリミティブとして設計されており、協力している発行者/利用者が信頼/評判のシグナルを共有するために使用できます。 |
| メンテナンスのオーバーヘッド | 信頼トークン オペレーションの基盤となる暗号実装は BoringSSL にあり、Google が唯一のメンテナです。ライブラリのメンテナンスはどのように管理されますか？ | トラスト トークンは、標準化された暗号操作（プライバシー パス プロトコルを参照）に依存しています。この操作は他のライブラリでも実装できます。デベロッパーは、選択したライブラリでこれらのオペレーションのサポートをリクエスト、開発、維持することをおすすめします。 |
| メンテナンスのオーバーヘッド | プロトコル バージョンがサポートされる期間が不明 | プロトコル バージョンのサポート期間について、詳細を検討し、文書化していく予定です。 |
| カード発行会社の上限 | チェーンの下位にいる場合、信頼トークンを実行する機会がない可能性があります。 | 信頼トークンを使用する組織が増えるにつれて、このようなタイミングの変化がますます顕著になる可能性があります。Google は、考えられる解決策を調査しています。前述のとおり、Google は、ユーザーのエントロピーを増やすことなく企業がトークンを安全に利用できるようにする長期的なオプションを検討しています。これにより、ページ上の位置や読み込み順序の重要性が最小限に抑えられます。 |
新しい不正行為防止ソリューション（開発中）
| フィードバック テーマ （発生頻度順） |
質問と懸念事項の概要 | Chrome の対応 |
| デバイスの完全性証明シグナル | プラットフォームによって証明され、ウェブで利用可能なデバイスの完全性シグナルの取得を一般的に強くサポートしている | 引き続きフィードバックを収集し、公開設計と反復処理を通じて提案を進めていきます。 |
| デバイスの完全性証明シグナル | 新しいシグナルを通じてユーザーのエントロピーをどの程度伝えることができるか、特定のユースケース（ユーザーが銀行にログインするなど）でエントロピーの高いシグナルを正当化できるかどうかに関する質問。 | Google は、ユーザーのプライバシーを保護するため、ユーザーのエントロピーを可能な限り抑えながら、価値の高いシグナルを提供することに重点を置いています。 |
| デバイスの完全性証明シグナル | このシグナルは、古いデバイスやオープンソース/変更済みプラットフォームへのアクセスを制限しますか？ | 新しいシグナルを開発する際は、ユニバーサル アクセスを重要な原則として考慮する必要があります。これは、インキュベーションを継続する際に最初に解決すべき重要な問題です。 |
| デバイスの完全性証明シグナル | 新しいシグナルによって、セキュリティや不正行為防止の企業がブラウザとプラットフォームに過度に依存するようになるのではないかという懸念がありました。
|
新しいシグナルは、ブラウザからの「信頼」の指標ではなく、補足データとして見なす必要があります。セキュリティ企業は、デバイス構成証明を追加入力として、引き続き独自の独占データ、モデル、意思決定エンジンに依存することが予想されます。新しいシグナルによって、エコシステム全体の検出機能が向上し、不正行為の実行が困難になることを願っています。 |
| Cookie の有効期間シグナル | 興味深いコンセプトですが、該当するユースケースについてさらに調査が必要と思われます。 | 関心の度合いによっては、Chrome はこのコンセプトについてさらにアイデア出しを行い、今後のエコシステム フィードバックのための説明資料としてまとめる可能性があります。 |
| 不正行為防止のための信頼できるサーバー | 興味深いコンセプトですが、該当するユースケースについてさらに調査が必要と思われます。 | 関心の度合いに応じて、Chrome はこのコンセプトについてさらにアイデア出しを行い、今後のエコシステム フィードバックのための説明資料としてまとめる可能性があります。 |