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