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

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

2023 年第 1 四半期の四半期レポート。プライバシーサンドボックスの提案と 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 レスポンス
テストとトライアル	テストの関連性（テスト開始時までにプライバシーサンドボックス API が完了していない場合に CMA の評価に通知する）	プライバシーサンドボックス API の開発は、ペースで進んでいます。テスト用のオリジントライアルではすでに提供されており、今年の夏に 100% のトラフィックに対して一般提供される予定です。さらに、特定の機能（FLEDGE イベントレベルレポート、iframe を使用した FLEDGE レンダリングなど）のタイムラインを明確にしました。これらは 2026 年以降に影響が及ぶことはありません。サードパーティ Cookie のサポートが終了した時点で、テスターが何を期待しているかに基づいて API をテストし、CMA にフィードバックを提供することをおすすめします。これは、サードパーティ Cookie の廃止による影響を評価するうえで役立ちます。
ユーザーコントロール	プライバシーサンドボックス API によるユーザーコントロールへの影響に関する、エコシステムに対する明確なガイダンス	エコシステムで使用できるユーザーコントロールについて、Google から法的なアドバイスを提供することはできません。それと同時に Chrome では、プライバシーサンドボックス技術の改善に向けた継続的な取り組みの一環として、ごく一部のユーザーを対象に、最新のプライバシーサンドボックス（「高度な広告プライバシー」）のユーザーコントロールを表示するテストを行っています。今回の更新では、より明確で有用な表現とレイアウトが採用されています。Chrome はこうした絞り込みを評価し、対象を拡大するかどうかを決定した後に、エコシステムとより多くの情報を共有できます。
データ漏洩	ブラウザが侵害された場合に、自社データが Google や他の関係者に漏洩するリスク	FLEDGE の説明では、1 つの広告テクノロジーのデータが、その広告テクノロジー（ワークレットまたは信頼できるサーバー）とのみ共有されるか、その広告テクノロジーによって明示的に共有される（購入者が販売者に表示する広告 URL を販売者に表示するなど）ことが明らかになっています。例外として、k-匿名性のチェックは一元化されたグローバルなサーバーで行う必要があります。この分野は Google が引き続き多大なリソースを投入しています。プライバシーに対する Google の考え方について詳しくは、k-匿名性の説明をご覧ください。また、k-匿名性サーバーの設計で採用されている広告テクノロジーの保護の仕組みについても、詳しくご説明いたします。
その他のディスカッションフォーラム	技術に詳しくないエコシステムのプレーヤーにフィードバックを共有するための、W3C への追加フォーラムのリクエスト	プライバシーサンドボックスのフィードバックフォームは、一般的なコメントと具体的なコメントのほか、技術的なコメントと非技術的なコメントに適しています。ウェブ広告ビジネスの改善グループは、毎週電話によるディスカッションのフォーラムと GitHub リポジトリです。 developer.chrome.com にあるプライバシーサンドボックスのフィードバックページでは、フィードバックを提供し、ディスカッションに参加するためのその他のメカニズムについて説明しています。また、質問やコンテンツ共有を促進するために、公開オフィスアワーなどのイベントも引き続き開催します。また、Chrome は前四半期に 10 を超える業界イベントを開催し、参加してきました。
タイムラインの明確化	2023 年第 3 四半期の一般提供の正確な日付を明記	PrivacySandbox.com で公開されているタイムラインによると、Chrome バージョン 115 のリリースとともに一般提供が開始される予定です。
reCAPTCHA	サンドボックス API が reCATPCHA の迷惑メール検出ユースケースに及ぼす影響	Google は、プライバシーサンドボックスの提案がウェブの安全性や不正行為に大きく影響しないように、reCAPTCHA から定期的にフィードバックを受け取っています。サードパーティ Cookie の廃止に向けた準備と調整について、独自の計画を策定中であるため、この質問には対応することをおすすめします。
Chrome 拡張機能	不正トラッキング（ACT）対策などのプライバシーサンドボックステクノロジーは Chrome 拡張機能に適用されますか？	ACT が Chrome 拡張機能に適用されるかどうかについては、まだお知らせしていません。しかし、ある技術がユーザーの情報をひそかに収集する場合、Google のプライバシー原則に沿うものではありません。

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

トピック

フィードバックのテーマ	概要	Chrome レスポンス
TAG のデザインレビュー	TAG が Topics の Early Design Review をリリース。	Google は Topics に真摯に取り組んでおり、最新情報のページとこの問題の内容で、Topics に対するコミットメントの最新情報を共有しています。TAG の審査に対してポイントごとに回答し、こちらで大まかなビジョンをお伝えしました。 Topics API は、広告エコシステムが 2023 年も引き続きテストすべき API 群の一部であり、皆様から寄せられるテストに関するフィードバックや実装のユーザーエクスペリエンスが、この分野での今後のブラウザ間での標準化に向けた取り組みのお役に立てば幸いです。Google は、Topics API が合意されたブラウザ間の互換性を持つ標準となる可能性のある移行を容易にするために、引き続きエコシステムとの協力に取り組んでまいります。
トピックへの取り組み	Chrome の Topics API 開発におけるオープンなアプローチをサポート	Google は、お客様のご意見に感謝しています。引き続き業界グループと協力して、エコシステム全体に価値を提供する Topics API の開発に取り組んでまいります。
（2022 年第 3 四半期にも報告） Topics の分類が細分化されない	広範なトピック分類には、リージョン固有のものなど、より詳細なトピックは含まれません。	第 1 四半期の更新: 分類の改善は継続的な取り組みです。第 2 四半期には、Topics API の分類の更新について発表します。この新しい分類法を作成するにあたり、Google はエコシステム全体の企業と緊密に連携しました。 YouTube では、このエコシステムに最も有用な分類法についてのフィードバックを積極的に求めています。トピックの数を拡大するか、より詳細なトピックを含めるかを検討する際は、1）プライバシーへの潜在的な影響（トピックが増えるとフィンガープリントのリスクが高まる可能性がある）、2）以前に観測されたトピックを取得する機能（トピックが多いなど、広告テクノロジーが過去に選択したトピックを見る可能性が低い可能性）など、いくつかの考慮事項があります。
（2022 年第 4 四半期にもレポートされます）自社シグナルへの影響	Topics シグナルは非常に価値が高い場合があり、その結果、他のファーストパーティのインタレストベースシグナルは評価されません。	Google は、インタレストベース広告はウェブの重要なユースケースであると考えており、Topics はそのユースケースをサポートするように設計されています。大規模なパブリッシャー様の中には、Topics が自社データ戦略に悪影響を及ぼすことを懸念する方もいらっしゃいます。Topics がパブリッシャーに及ぼす影響について知見が得られるエコシステムテストに期待しています。
広告に関連しないトピックのユースケース	インタレストベース広告の表示以外の目的での Topics の使用	Topics はインタレストベース広告のユースケースに対応するために設計されており、Google はそれが自由でオープンなウェブにとって不可欠なユースケースであると考えています。現在、他のユースケースに関するフィードバックを募集しており、評価も行っています。
デフォルトのオプトインステータス	地域の法律が Topics の同意のデフォルト値に及ぼす影響	Google は法的な意見についてコメントする立場にありません。
（2022 年第 3 四半期にもレポート）。分類ミスがあるサイト	特定のサイトについて、トピックが誤って分類されている場合に広告のターゲットを設定する	第 1 四半期の更新: Google は第 2 四半期に、Topics API の新しい分類器について発表します。今後は、このエコシステムを活用していきましょう。現在のフィードバックを受け、サイトは、最も人気のあるサイトを含む人間がキュレートしたオーバーライドリストと、デバイス上の ML モデルを組み合わせて分類されます。Chrome では、Topics 分類にサイトを組み込む方法を引き続き評価しています。ユーティリティを改善する場合は、プライバシーや不正使用のリスクを比較検討する必要があります。たとえば、さまざまな（そして機密情報になり得る）意味をトピックにエンコードする方法として自己ラベル付けを行っているサイト、金銭的利益のためにトピックを偽装しているサイト、他者にとっての有用性を損なうためにトピックを攻撃するサイト（例: ユーザーのトピックに無意味なノイズでスパム行為をするサイト）などのリスクがあります。一般ユーザーは、`chrome://topics-internals` またはこの Colab を介して利用可能なツールを使用して、これらのコンポーネントを検査できます。テストを通じて分類の精度は徐々に向上することが期待されます。分類が不適切になっているサイトの例について、フィードバックをお寄せください。
トピック分類器	デバッグのために「No Topics」が呼び出し元に返された場合に、その理由を示す追加情報を返すリクエスト	Google は、Topics API をシステムに統合するデバッグツールがデベロッパーにとって有益であることを理解しています。ただし、追加情報（Topics が返されなかった理由など）を意図せず公開することで、意図したもの以外の追加情報（ユーザーがシークレットモードを使用している場合、API を無効にしている場合など）が明らかになり、ユーザーのプライバシーを損なう可能性があります。現時点では、追加のデバッグツールを提供する予定はありませんが、どのツールが役立つかについてのフィードバックをお待ちしております。
個人情報検索（PIR）	Topics API による個人情報取得の導入リクエスト	以前に PIR を使用して調査したことがあり、トレードオフをこちらで共有しました。
入札ストリーム	入札ストリームで、トピックは販売者定義のオーディエンスとは明確に区別されますか？	Topics API は Chrome が開発したプライバシーサンドボックスの提案で、IAB Tech Lab の販売者定義オーディエンスの提案とは異なります。入札ストリーム内では、この 2 つが明確に区別される必要があります。OpenRTB の入札リクエストで Topics が表される方法をご確認ください。

Protected Audience API（旧 FLEDGE）

フィードバックのテーマ	概要	Chrome レスポンス
FLEDGE の機能の提供状況	Fenced Frame の適用、K-匿名性など、FLEDGE 機能のテストと実装のタイムラインを明確にしました。	FLEDGE のさまざまなスコープの機能と、それらがサポートされる時期については、ブログ投稿を公開しました。Google は引き続き FLEDGE を開発しています。この発表について追加のフィードバックをお待ちしています。
プロダクトの表示に関する制限	FLEDGE フェンス付きフレームにおける、複数ピースで構成される広告の制限の緩和リクエスト	2 月に発表したとおり、フェンス付きフレームの使用は少なくとも 2026 年まで任意であり、iframe の動作は urn-iframes でサポートされます。このトピックに関するさらなる議論を歓迎します。
スケーラビリティの問題	使用量の増加に伴う FLEDGE のパフォーマンス	Google では、実用的な解決策を提案できるよう、フィードバックに対するフォローアップとコンテキストのさらなる把握を積極的に進めています。最初のステップはフィードバックを次の 2 つのカテゴリに分けることでした。 a）それ自体と b）DSP の両方で秒間クエリ数（QPS）の負荷を最適化する、SSP ドリブンのフィルタリング。インタレストグループの DailyUpdate ロジック。DSP の QPS 負荷を最適化します。
（2022 年第 3 四半期にも報告）入札ロジックの可視性	DSP 入札ロジックが JavaScript で公開されるのに対する懸念	第 1 四半期の更新: Google は、攻撃者が探索的（強制ブラウジング）の方法でサーバーにデータをリクエストする可能性を制限する提案を共有しました。この提案に対するフィードバックやサポートをエコシステムのプレーヤーに共有していただければ幸いです。
テストに関する問題	小規模な DSP でも FLEDGE を適切にテストできるため、広告主が大型の DSP でのテストのみに関心を持つというリスクが軽減される	Google は、より小規模な DSP との連携に取り組んでおり、FLEDGE の一般提供への移行に伴い、あらゆる規模の DSP と広告主間でテストを拡大することを強く推奨しています。そこで、エコシステムの他のメンバーとの FLEDGE のテストについて、私たちがどのような支援を提供できるかについてご意見を伺いたいと思います。また、広告主が小規模な DSP でテストを行うよう促すアイデアや業界の取り組みを歓迎します。
動的リマーケティング	サードパーティ Cookie のサポート終了後も FLEDGE で動的リマーケティングを利用することはできますか？	Google では、この質問への回答を検討しています。動的リマーケティングをどのように使用する予定かについて、エコシステムのプレーヤーの皆様から詳しい分析情報を共有していただければ幸いです。
不正行為/不正使用	エコシステムがリスクを軽減し、不正な行為者や購入者が自分たちを望ましい視聴者として位置付けるのを防ぐにはどうすればよいか。	Google は、不正行為や不正使用に関してエコシステムプレーヤーとの連携を深めることを楽しみにしています。この分野に関するフィードバックをお待ちしています。
ユーザーの好み	ユーザー設定を保存して広告選択で使用するプロセス	特定の広告の場合、関連する広告テクノロジーは、表示するクリエイティブやその選択方法を管理できる最適な当事者です。
定量的テストの提案	量的テストを公平に行うには、サードパーティ Cookie のないトラフィックと FLEDGE のみを使用する SSP のどちらでテストを実行すればよいですか？サードパーティ Cookie からのシグナルの混在を回避するにはどうすればよいでしょうか。	いただいたフィードバックに感謝するとともに、現在、CMA と協力して、サードパーティ Cookie の廃止とエコシステムへのプライバシーサンドボックスの提案の導入が及ぼす影響について信頼できる全体像を提供するテストを設計しています。CMA の定量的テストの提案に対する追加のフィードバックは、CMA に直接共有することをおすすめします。
ドキュメントの明確化	オークションの設定に関する明確なドキュメントのリクエスト	FLEDGE オークションレポートの概要については、今後数週間のうちにブログ投稿でお知らせいたします。
並列化	入札とオークション（B&A）サービスは並列化をサポートしていますか？	入札 / オークションサーバーを使用する広告テクノロジーは、並行して結果を配信できる複数のサーバーを起動できます。
不正行為の軽減	プライベートステートトークンを使用する FLEDGE の k-匿名性サーバーは、ユーザーのプライバシーを確保するのに十分ですか？	k-匿名性を使用する理由は、マイクロターゲティングよりも、FLEDGE でイベントレベルレポートを可能にする中間フェーズで支援を受けることにあります。Google では、これまで以上にご意見や追加のフィードバックをお待ちしています。
ES モジュールの競合	ES モジュールと競合するため、`generateBid` をグローバル関数として除外するリクエスト。	Google ではこのリクエストについて検討しており、追加のフィードバックをお待ちしています。
コンポーネントオークション	オークションデザインをより詳細に管理するためのリクエスト	デバイス上の Chrome と同様に、コンポーネントオークションをサポートする入札とオークションの計画。
B&A スケジュール	B&A サーバーのテストに関心のある広告テクノロジーのタイムラインの明確化	B&A の説明を更新し、タイムラインセクションを更新して、CMA との整合後、Chrome-B&A テストのさまざまなフェーズのタイムラインの明確な定義を追加しました。
タイムアウト制御スキーム	FLEDGE で現在利用可能なタイムアウト制御スキームの強化	これは興味深い提案です。これを研究提案のキューに追加し、開発状況について報告します。
クリエイティブの入札ストリーム	クリエイティブに基づいて落札した入札単価を確認し、フィルタする機能	これは興味深い提案です。これを研究提案のキューに追加し、開発状況について報告します。
`reportWin`	`reportWin` 関数で、落札者以外の別のインタレストグループオーナーからの最高スコアの入札に関する追加情報を提供する提案	これは興味深い提案です。集計レポートにシグナルを追加することを検討しています。ぜひフィードバックをお寄せください。
イベントタイプ	FLEDGE と統合すると、測定 API 間でイベントタイプを標準化する	これは興味深い提案です。これを研究提案のキューに追加し、開発状況について報告します。FLEDGE 以外のプライバシーサンドボックス API に影響する可能性があるため、この分野における Google の幅広い取り組みとの連携が必要になります。ぜひフィードバックをお寄せください。
イベントレベルレポートの長期的なソリューション	サードパーティ Cookie が廃止された後も、`highestScoringOtherBid` などの特定のデータを利用できるようにしておくことへの関心	2 月のブログ投稿でお知らせしたとおり、イベントレベルのオークション落札レポートは、「2026 年以降」までサポートされます。現時点ではこれ以上お伝えできる情報はございませんが、サードパーティ Cookie のサポート終了後も特定のデータを利用できるようにしておくことが重要である理由について、追加のフィードバックをお待ちしています。
インタレストグループの上限	1 つのオリジンが 1 つのブラウザに追加できるインタレストグループの数に制限はありますか？	Chrome では、オーナー 1 人につき最大 1,000 個のインタレストグループと、最大 1,000 人のインタレストグループオーナーを使用できます。これはガードレールとして使用されるもので、通常のオペレーションでヒットするものではありません。
イベントレベルのシグナル	ML のトレーニングで使用できる `generateBid` と `reportWin` のイベントレベルシグナルを含む提案のサポート	ブラウザ設計のシグナルと広告テクノロジーの定義シグナルの決定についてお知らせし、追加のフィードバックをお待ちしています。
入札スクリプト	入札スクリプトの URL にユーザー ID を含めます。	FLEDGE には、インタレストグループの所有者、入札スクリプト URL、レンダリングされるクリエイティブのタプルが k-匿名性であるという追加要件があるため、これはできません。
k-匿名性の適用	k-匿名性は (componentAd, size) ペアに適用されますか？	はい、あります。turtledove/issues/312 をご覧ください。
入札とオークションサービスの要件	B&A サービスは、オンデバイス FLEDGE と統合する参加者や、B&A サービスを使用するその他の参加者をどのようにサポートしますか？	引き続きデザインを調整中です。ぜひフィードバックをお寄せください。
ポストビューアトリビューション	ポストビューアトリビューションはサポートされますか？	現時点では、視認性の標準的な定義は存在せず、クリエイティブ自体によってビューイベントがマークされます。turtledove/issues/452 をご覧ください。
類似ターゲティング	プライバシーサンドボックスは「類似ターゲティング」をサポートできますか？	ここではユースケースについて説明し、追加の入力を歓迎します。
リアルタイムモニタリング API	リアルタイム FLEDGE モニタリングアプローチの提案	この提案についてご説明しており、ここからは追加のご意見をお寄せください。
FLEDGE レポート	過少報告または過少報告を防ぐために、`reportWin` と `reportResult` はランダムに作成する必要があります。	`reportResult()` は、最初に販売者が `reportWin()` の前に販売者によって実行され、`reportResult()` からの販売者シグナルを `reportWin()` に含めることができるようにする必要があります。詳細については、説明をご覧ください。
カスタム Key-Value（K/V）サーバー	カスタム K/V サーバーは今後サポートされますか？	この質問についてはこちらで議論しており、追加のご意見をお待ちしています。
トップレベルオークション	トップレベルのオークションメカニズムを実行するには、広告サーバーである必要がありますか？	FLEDGE API は、どの当事者がそれを呼び出す必要があるかを指定しません。FLEDGE の設計には、その意味で要件はありません。FLEDGE オークションは誰でも実施できます（複数販売者オークションを含む）。2022 年第 4 四半期レポートで説明したように、FLEDGE では、各パブリッシャーがトップレベルとコンポーネントの販売者の選択など、オークションの構造を選択できます。
API の範囲	FLEDGE は自社データを扱う予定ですか？	2023 年第 2 四半期にコンテンツを公開する予定です。具体的には、自社データが FLEDGE で使用可能であることを明確にします。1）インタレストグループメンバーシップの判断ロジックとして使用すること、2）後続の入札ロジック生成で使用するユーザー入札シグナルとしてフィードする。
クロスドメインのインタレストグループ	クロスドメインのインタレストグループを作成可能	ブラウザをインタレストグループに追加する際に利用可能な情報を使用して、そのオーディエンスに通知できます。サードパーティ Cookie が段階的に廃止されると、インタレストグループの作成に利用できるクロスサイトデータは制限されます。
クライアントサイドの入札ロジック	サーバーサイドの既存の入札ロジックをクライアントサイドに移植する	Google では、移行プロセスが難しい領域や現在不足している領域について詳しく知り、新たなフィードバックや分析情報があれば歓迎します。
K/V サーバーの値	K/V サーバーの値は文字列型にする必要がありますか？	値は文字列にする必要がありますが、オブジェクトを JSON またはプロトコルバッファに格納し、文字列にシリアル化できます。
広告主のブロックリスト	広告主のブロックリストへの購入者への提供に適したシグナルは、次のうちどれですか。	適切な場所は、`auctionSignals` または `perBuyerSignals` です。
入札ユニット	さまざまな単価調整単位（CPI、CPM など）に対応	現在の設計でこれが必要となる理由について、ご意見、ご要望をぜひお寄せください。
オークションロジック	オークションの落札者はブラウザまたは広告サーバーによって決定されますか？	落札者の選択はすべてサンドボックス内で行われ、すべての決定は販売者のコードによって行われます。ブラウザは、購入者と販売者のコードを実行するシールされたプライベート環境を提供するだけです。
権限ポリシー	オリジントライアル終了後も、現在の FLEDGE 権限ポリシーは引き続き適用されますか？	オリジントライアルの場合、両方の機能の現在のデフォルトの許可リストは一時的なものであり、変更されます。Google では、広告テクノロジーが変更の適用を開始する前に準備する期間について、どのくらいの期間が必要になるかについてお聞きしたいと考えています。
シグナルサイズの制約	信頼できる入札シグナルのリクエストは、同じ `trustedBiddingSignalsUrl` を持つ複数のインタレストグループ間で統合されます（サイズの上限が 2 MB です）。	この制約は、デバイス上のリソースが過負荷にならないように、デバイス上の呼び出し元に対して存在します。B&A サーバーからの呼び出し元には、制約がより緩和されます。
レポートシグナル	スクリプトエラーというシグナルを追加して、インタレストグループのオーナーごと、および `computeBid` または `reportWin` / `reportResult` ごとにクライアントサイドのエラー数を取得できるようにします。	Google は、この提案に対する潜在的なプライバシー上の懸念について検討しています。エコシステムのプレーヤーの皆様は、なぜその必要があるのか、さらなる知見の共有を歓迎します。
k-匿名性のウィンドウサイズ	現在の 7 日間の上限から K-匿名性のウィンドウサイズを増やします。	これは検討中であり、現時点ではエコシステムからの追加の入力を待っています（歓迎しています）。
デバイス単位の掲載結果	ユーザーが多数のインタレストグループに属している場合、FLEDGE はデバイスのパフォーマンスをどのように処理しますか？	FLEDGE は、SSP と DSP にわたっていくつかのタイムアウト、優先順位付け、制限のオプションを提供し、デバイスが多数のインタレストグループにあるときに、デバイスのパフォーマンスがオークションへの参加を制限する理由の 1 つになり得る状況において、広告テクノロジーがきめ細かな制御を可能にします。
B&A サービスのテスト	デバッグにより多くのログを利用できるように、テストフェーズでエコシステムプレーヤーが独自のサーバーを使用するようリクエストする	B&A では、ユーザーは承認済みのクラウドプロバイダからサーバーの起動とスケーリングを行うことができます。ユーザーのプライバシーを保護するため、実行は高信頼実行環境（TEE）内で行われます。Google は、B&A TEE のデバッグに関する説明をまもなくリリースし、それをサポートする機能を開発する予定です。このトピックについては、追加のフィードバックをお待ちしています。
規制要件	FLEDGE は、各国のクラウドプロバイダと連携して各国の規制要件を遵守できますか？	Google では、他のクラウドプロバイダに関するご提案をいつでも受け付けておりますが、現時点では、サードパーティ Cookie のサポート終了が強制された時点で、少なくとも GCP と AWS をサポートする予定です。詳しくは、こちらの説明をご覧ください。

デジタル広告の測定

Attribution Reporting（とその他の API）

フィードバックのテーマ	概要	Chrome レスポンス
ノイズの影響に関するデータ分析	ノイズの影響についてデータ分析を行う方法のガイダンス	ノイズが広告テクノロジーデータに与える影響を変更するために使用できる、ノイズと設計上の決定事項に関する追加ドキュメントを公開しています。詳細なガイドもあわせてご覧ください。
null レポート	null レポートの実装に関する明確化	Google では現在、null レポートの実装の提案に取り組んでおり、まもなく詳細をお知らせいたします。null レポートを実装することで、プライバシーを損なうことなくレポートの遅延を減らすことができます。
ノイズレベル	アトリビューション期間の長さに基づいてノイズレベルを調整する	Google はこの提案を歓迎し、仕様に追加することを検討中です。こちらからフィードバックをお寄せください。
トリガーのデータサイズ	トリガーのデータサイズが 3 ビットに制限されているのはなぜですか？	ユーザーに関するクロスサイト/コンテキスト情報の量を制限するために、サイズは 3 ビットと 8 つの異なる値に制限されています。イベントレベルレポートの現在のパラメータ化が妥当かどうかについて、エコシステムのプレーヤーにフィードバックをお寄せください。
イベントレベルのレポートトリガー	重複除去キー内での優先順位付けを可能にする	Google ではこの問題の解決策を調査しており、追加情報もお待ちしております。
デバッグサポート	サードパーティ Cookie のサポート終了後のデバッグの明確化	サードパーティ Cookie のサポートが終了した後もデバッグを行いたいと考えており、オプションを検討しています。その他のフィードバックやご提案をお寄せください。
クリックスルーコンバージョン	クリックスルーコンバージョンの代替手段についての詳細なガイダンスをリクエスト	Google はエコシステムにおいて、該当するコンバージョン測定ユースケースのために、持続可能なプライベート測定システムとして Attribution Reporting API を使用することを推奨しています。他の代替手段がある場合は、広告テクノロジープロバイダが、プライバシーとユーティリティに関する要望に基づいて適切なソリューションを決定する必要があります。
請求のユースケース	Attribution Reporting がコンバージョンベースの請求ユースケースをサポートするかどうかの明確化	Google は、課金に関する Attribution Reporting API の範囲を明確化するため、一般公開で投稿を行うよう努めています。Attribution Reporting API は、当初は CPA 課金を直接サポートするようには設定されていませんでした。広告テクノロジーの大部分で使用される課金構造である CPC と CPM の課金をサポートしています。今後、エコシステムに関するフィードバックがさらにある場合、これをサポートする可能性があります。
ユースケースのサポート	測定 API のユースケースに関するドキュメント	Google では、プライバシーサンドボックスのすべてのレポートサーフェスについて、ドキュメントの明確化に取り組んでいます。
クリックの品質	広告の意図的なクリックと意図しないクリックを区別するためのシグナルを追加するリクエスト	リクエストについて検討しており、追加情報もお待ちしております。
測定ソリューション	複数の DSP にわたる測定ソリューションのサポート	測定プロバイダは Attribution Reporting API を使用して、複数の DSP 間での重複を排除できます。また、`attributionsrc` での URL リストのサポートを提案しています。これにより、DSP が測定プロバイダの Attribution Reporting API リクエストを容易にサポートできるようになります。上記の提案について、さらにフィードバックがございましたらお聞かせください。
イベントレベルレポート	レポートが直接送信されるまでの日数をリクエストする	このリクエストは、現在利用可能な情報を使用して広告テクノロジーが計算できます。このリクエストに関して、エコシステムから他にフィードバックは寄せられていませんが、フィードバックは受け付けています。
`source_registration_time`	イベントレベルの Attribution Reporting に `source_registration_time` を追加しました。	Google ではこのリクエストを検討しており、エコシステムのプレーヤーがこの機能を有益だと感じているかどうかについて、追加のフィードバックをお待ちしています。
シークレットモード	ユーザーがシークレットモードのときも測定ソリューションは利用できますか？	いいえ。ユーザーがシークレットモードを使用している場合は、測定ソリューションは利用できません。シークレットモードでは、デフォルトでサードパーティ Cookie は無効になっています。
データクリーンルーム	Measurement API はデータクリーンルームと互換性がありますか？	一般的なデータクリーンルームでは、さまざまなソースから個々の ID データがデータベースにアップロードされ、基盤となるデータの統合に基づいて分析が行われます。プライバシーサンドボックス API 用の 2 つの測定フレームワークは、イベントレベルレポートとサマリーレポートです。イベントレベルレポートには、データクリーンルームで使用できる広告技術が提供するイベント ID が含まれますが、関連するコンバージョン側の情報は限定され、ノイズが多くなります。暗号化された集計可能レポートは、クリーンルームで直接使用することはできませんが、集計サービスが提供するサマリー結果は、実行する分析の入力または補足情報として使用できます。

集計サービス

フィードバックのテーマ	概要	Chrome レスポンス
（2022 年第 4 四半期にもレポートされます）レポートの遅延	レポートの遅延はどのくらいが予想されますか？	2023 年第 1 四半期の更新: パートナーからのフィードバックに基づき、遅延を短縮し、遅延の影響を軽減するための提案を共有しました。どちらの提案も、WICG の呼び出し中に広告テクノロジーによってサポートされています。
重複なしのルール	同じ共有 ID の集計可能レポートがすでに処理されている場合、「遅延型の集計可能レポート」をどのように処理しますか？	集計 API の遅延損失の影響に部分的に対処するために、集計可能レポートの共有情報にレポートの遅延を追加すること、および集計サービスの共有 ID の定義に関する提案を共有しました。この提案についてフィードバックをお寄せください。
データ処理	プライバシーバジェットを使用して、差分プライバシーを尊重しながら複数のデータパスのサポートを有効にするリクエスト	Google は、プライバシーバジェットをより柔軟な方法で使用してこのユースケースを実現する方法について検討しており、追加のフィードバックをお待ちしています。
（2022 年第 2 四半期にも報告）クエリのエルゴノミクス	キーの集計のクエリを有効にします。	2023 年第 1 四半期の更新: 機能リクエストは現在検討中ですが、現時点でお伝えできる提案はありません。
オリジントライアルの制限事項	オリジントライアルで現在適用されていない「重複のないルール」など、集計サービスのスコープを明確にする。	Google は、オリジントライアルと一般提供でご利用いただける機能を明確にするために、ドキュメントの更新を検討しています。

Private Aggregation API

フィードバックのテーマ	概要	Chrome レスポンス
民間集計の資金提供予算	L1 の寄付予算の制限が厳しすぎます。	Private Aggregation API の各呼び出しはコントリビューションと呼ばれます。ユーザーのプライバシーを保護するため、個人から収集できる投稿の数には制限があります。すべての集計キーのすべての集計可能値を合計する場合、その合計は寄付予算より小さくする必要があります。現在の設計では、特定のレポート元に対するコントリビューションに、過去約 24 時間（ローリングウィンドウ）の上限が設定されています。これはフィードバックで言及されている L1 の寄付予算です。 Google では、提供する値を、1 ではなく、期待されるボリュームに基づいて調整することをおすすめします。そのため、予算を使い果たさないように、一般的なイベントには小さい値を使用するほうが合理的な場合があります。現在、Private Aggregation API の寄付予算について、数値境界とスコープの両方についてフィードバックをお待ちしています。Google では、スコープをオリジンごとからサイトごとに移行し、既存の範囲を 1 日の制限をより長くした 10 分間のウィンドウに移行することを検討しています。

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

User-Agent の情報量削減/User-Agent Client-Hints

フィードバックのテーマ	概要	Chrome レスポンス
UA-R の導入	英国の上位 10,000 サイトのうち、HTTP Client Hints を送信しているサイトは、プログラマティック広告を使用しているわずか 1% です。移行していない DSP は、不正防止機能に影響する可能性があります。	同じデータセットで分析を行った結果、HTML <meta> タグと JavaScript API を使用して UA-CH の使用状況が考慮された場合、UA-CH を使用しているサイトの数は、フィードバックで提供された 1% の数値よりも大幅に多くなることがわかりました。Google は、こうした状況とエコシステムのフィードバックを含むその他の事実に基づき、CMA に情報を提供しつつ、公開されたタイムラインに従って UA Reduction のフェーズ 6 を段階的に展開していきます。移行の準備には 2 年近いリードタイムがあり、まだ移行準備が整っていないと感じるサイトでは非推奨トライアルを利用できます。
その他のフォームファクタに関するヒント	TV、VR などの追加のフォームファクタを提供するための UA-CH のリクエスト	Google はこの提案を歓迎し、設計に組み込むことを検討中です。その他のフィードバックをお寄せください。
自動テスト	UAR フェーズ 6 が出荷される前にヘッドレス Chrome での UA-CH バグの解決をリクエストする	問題のバグが修正されました。
iOS での UA-CH のサポート	広告のユースケースで詳細な UA 情報に依存しているサイトでは、iOS 版 Chrome はサポートされていないと指摘されています。	Safari 以外の iOS ブラウザ（iOS 版 Chrome を含む）の場合、WebKit プロジェクトで有効にするには、UA-CH のサポートを追加する必要があります（ネットワークスタックを制御するため）。

IP 保護（旧 Gnatcatcher）

フィードバックのテーマ	概要	Chrome レスポンス
（第 4 四半期にもレポート）位置情報のユースケース	IP 保護を使用すると、位置情報に基づくコンテンツのパーソナライズなど、位置情報の正当なユースケースが今後機能しなくなる可能性があります。	今回の対応については、2022 年第 4 四半期から変更はありません。「Google では、Chrome が IP アドレスの正当なユースケースをサポートし続けるよう、関係者と連携して取り組みを進めております。Google では、IP の位置情報の粒度に関するエコシステムに関するフィードバックを求めています。」
規制コンプライアンス	地域の人口が 100 万人未満の場合、現在の IP 保護のしきい値 100 万では、ウェブサイトは規制遵守のために IP アドレスを使用できません。	Google は関係者と連携して、Chrome で IP アドレスの正当なユースケースが引き続きサポートされるようにしています。Google では、IP 保護に関する規制遵守についてのエコシステムからのフィードバックを募集しています。
不正行為の軽減	当事者は、マスク処理されていない IP アドレスを他のユーザーと共有することで IP 保護を回避できます。	Google では、現在の IP 保護の提案では、当事者がマスク処理されていない IP アドレスを他のユーザーと共有することを技術的に阻止できない可能性があることを認識しています。Google では、このような不正使用のリスクを回避するため、現在対策を講じています。 Google は、この提案について多くのフィードバックやディスカッションを行ってきました。具体的には、当事者がマスク処理されていない IP アドレスを第三者と共有する必要があると判断したユースケースについてお尋ねします。
ネットワークブロック	当事者は、IP 保護プロキシを使用してネットワークブロックを回避できます。	このシナリオでは、ブロックを実行するエンティティが IP 保護を無効にする必要があります。Google はこの問題に対応しており、追加のフィードバックをお待ちしています。
IP 保護の提案の影響を受ける IP アドレスのブロックリスト	多くの広告テクノロジー企業は、TAG データセンターの IP リストなどの IP アドレスの基本的なブロックリストを利用して、不正である（または少なくとも収益化できない可能性が高い）広告枠への入札を防ぎます。広告テクノロジーがトラッカーでもあり、IP 保護提案の対象となる可能性がある場合、その会社は広告枠を購入する前に、広告に対する基本的なチェックを行えなくなることがあります。	潜在的な問題と解決策に関する IP 保護の提案について、より多くのフィードバックとディスカッションに参加することをおすすめします。このようなリストを IP 保護に適用し、以前にフラグが付けられた IP アドレスからクライアントをプロキシしないようにする方法もあります。

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

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

フィードバックのテーマ	概要	Chrome レスポンス
（第 4 四半期にもレポート）ドメイン数の上限	関連ドメイン数の増加のリクエスト	Google の対応は 2022 年第 4 四半期から変更されていません。 "WICG の電話では、Chrome はユーザーのプライバシーに関する利益にも配慮した実用的なソリューションを提供することに尽力していることを明確にしました。ドメイン制限の影響を受ける可能性のある具体的なユースケースについてコミュニティからフィードバックをお待ちしています。」
代替の FPS 提出	FPS 向けグローバルリストを送信する別の方法を提案する	現在、Google は Chrome でファーストパーティセット（FPS）をリリースする準備を進めており、セットの送信を受け付けるために一元化された GitHub リポジトリを設定しています。Google は、サードパーティ Cookie の廃止に備え、FPS が既存のウェブプラットフォームソリューションとのギャップを埋めることを期待しているため、サイト作成者が FPS をどのように活用しているかをそこから学びたいと考えています。セットのリストは時間とともに増加し、エコシステムはサードパーティ Cookie のない環境にも適応します。そのため、提案されたような別の分散型スキームも検討できるレベルにまでプロセスを成熟させることもできます。現在のプロセスでは、一定のライフタイムを設定し、取り込みプロセスを徐々に進化させることが期待されています。応募プロセスが成熟したら、この考え方を再検討します。
リポジトリのモデレーション	不正使用を防ぐために、FPS 提出リポジトリのコミュニティ管理を行う。不正な行為者はセットの提案にバーナーオリジンを使用するプロセスに過剰な負荷をかける可能性があります。また、大量のリクエストは真正なセット提案のオペレーションに影響する可能性があります。	Google では、技術的な検証チェックを利用することで、このチェックをできるだけ客観性のあるものにするよう努めています。Google では、これが最もスケーラブルな送信方法であると考えています。また、この目的に沿って、スパムやバーナーの送信に対してプロセスの復元力を確保することを目指しています。
関連付けられたサブセット	FPS は、関連付けられたサブセットを使用して、サードパーティのベンダー/SaaS フローのユースケースをサポートできますか？	サードパーティベンダー / SaaS のフローは、現在ファーストパーティセットの対象範囲とみなされていません。こうしたユースケースでクロスサイト Cookie がどのように使用されるかについて、追加のフィードバックをお寄せください。
FPS + CHIPS の統合	A/B テストなどのユースケースをサポートするために、FPS と CHIPS の統合のリクエスト	Google はこのユースケースについて検討しており、WICG 通話でさらに議論することも検討しています。こちらの追加情報をぜひお寄せください。
GDPR	GDPR のコンセプトに基づいてモデル化する新しい FPS サブセットの提案	この提案については、社内で検討し、寄せられた他のフィードバックや Google のプライバシーの目標との照らし合わせた内容となっています。回答として、今回この提案を採用しない理由を述べました。
メモリ	FPS リストが組み込まれている場合に想定されるブラウザのメモリサイズの変化	ブラウザは、接続解除トラッキング保護リストなど、メモリへの影響を最小限に抑えてこの種のリストを保存する前例があります。ファーストパーティセットのリストは各 Chrome クライアントにローカルでコピーされますが、引き続きファイルサイズをモニタリングし、メモリ使用量を最適化できると確信しています。

Fenced Frames API

フィードバックのテーマ	概要	Chrome レスポンス
フェンス付きフレームの制限事項	フェンス付きフレームによって課される制限の明確化	Google は 3 月に、フェンス付きフレームについての説明を更新し、フェンス機能に関する情報を提供しています。追加のフィードバックをお待ちしています。
アクセス情報を開く	隣接フレームに関する情報へのアクセス拡張リクエスト	Google は、これがエコシステムの要件である理由をさらに詳しく把握したいと考えています。さらなるフィードバックをお待ちしています。
フェンス付きフレームと iframe	フェンス付きフレームと iframe との機能同等性に関する質問	利用可能なすべてのプライバシーサンドボックスの API とレポートは、iframe と FencedFrame で同じ方法で使用できます。
フェンス付きフレームのサイズ変更	フレームサイズの変更を制限することは、特定のユースケースに影響します。	Google では、この制限の影響を受けるユースケースの種類について詳しく知りたいと思います。よろしければ、追加のフィードバックをお寄せください。

Shared Storage API

フィードバックのテーマ	概要	Chrome レスポンス
サードパーティワークレット	サードパーティは送信元で分割された共有ストレージに書き込むことはできますか？あるいは、サードパーティ測定のために他のワークレットを呼び出すか？	閲覧コンテキストでコードが実行されている場所によって、そのデータが書き込まれる共有ストレージが決まります。サードパーティのコードをページに追加すると、そのコードを独自の閲覧コンテキストとともに iframe として埋め込むことができます。これにより、サードパーティのコードは独自のオリジンに書き込むことができます。サードパーティのコードを iframe ではなくスクリプトとして埋め込むこともできます。この場合、ブラウジングコンテキストを切り替えることはなく、サードパーティは埋め込み側の共有ストレージに書き込むことができます。なお、この共有ストレージから読み取ることができるのは、その共有ストレージのオーナーのみです。
重複除去	Chrome エコシステム外のやり取りについては重複除去はできません。	共有ストレージは、Chrome ブラウザベースのユニークリーチを Chrome 内で出力することを目的としています。Google は広告テクノロジーと連携して、これらの出力を幅広いリーチモデルの一部としてどのように利用できるかを検討しています。Google は、出力自体がインタラクションの一部のみを説明する場合があることを理解しており、広告テクノロジーと連携して、上に配置できる追加のモデリング手法を探ることに興味があります。
コンバージョンのルックバックウィンドウ	時間の経過に伴うコンバージョンの変化を確認できるように、コンバージョン率のルックバックウィンドウを設定するようリクエストする	これは、共有ストレージを使用してクライアント側でさまざまなコンバージョン経路を処理することで実装できます。これにより、パーティション分割されていない安全なブラウザストレージに対して、高度な分析を行うための柔軟性が生まれます。
アイテムの有効期限	有効期限を 90 日間に延長することをリクエストする	データ保持ポリシーは 2022 年 11 月更新で、最後の書き込みから 30 日後に各鍵が消去されることが明記されています。新しいポリシーがエコシステムで機能するかどうかを把握するため、ぜひフィードバックをお寄せください。
クリエイティブローテーション	クリエイティブローテーションのユースケースには、オークション後の実際の対応は反映されていません。	Google では、クリエイティブローテーションのドキュメントが正確かどうかについて、バイサイドの広告技術企業に確認してもらいたいと考えています。

チップ

今四半期はフィードバックを受け取っていません。

FedCM

フィードバックのテーマ	概要	Chrome レスポンス
ID アサーションエンドポイント	ID アサーションエンドポイントへの任意のリクエストを明示的に許可します。	Google は、この pull リクエストにおいて Mozilla と協力し、ユーザーに迷惑をかけることなくクロスオリジンの認証済みリクエストを通知なく実行できないようウェブサイトの機能を制限してきました。今後も引き続き、その他のフィードバックの確認と対応を行ってまいります。
ID を事前入力する	FedCM を使用して FedCM リストの ID プロバイダをログインフォームに事前入力できますか？	このユースケースでは、ユーザーとやり取りしていないサイトが、ユーザーが最後に使用した IDP を照会できる場合に、情報が漏洩する可能性があることが懸念されます。Google ではこの問題についてさらに検討しており、追加のフィードバックをお待ちしています。
コンテキストに基づくアカウント選択	アカウント選択の UI にコンテキストシグナルを追加する提案	Google はこの提案を検討中です。さらなる議論を歓迎します。

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

Private State Token API（とその他の API）

フィードバックのテーマ	概要	Chrome レスポンス
能力収集アンケート	第 1 四半期の初めに、Google はさまざまな不正防止のユースケースに必要な機能に関するアンケート結果の収集を完了し、公開しました（分、結果）。	お寄せいただいたフィードバックは、不正行為対策機能に特化したプライバシー保護 API の新しい提案とプロトタイプを開発する際に生かす予定です。開発は、十分なニーズがあり、ユーザーのプライバシーを保護しながらウェブに機能を導入するために使用できる既存の技術がある場合に優先される見込みです。たとえば、デバイスと起動の整合性は高く評価され、多くのプラットフォームにはデバイスの完全性の評価を安全に共有する既存の API があるため、コミュニティグループ内で調査を進めることをおすすめします。
PST リリースの意向フィードバック	出荷の意図の一環として、古いバージョンのプライバシーパスを使用していることから、手続きを進めるうえで懸念が寄せられました。また、一部のセクションで仕様が不明確であり、ブラウザの互換性を確保するために改善が必要であるというフィードバックも寄せられました。	推奨される仕様の変更の多くと、いくつかの API の変更を一般提供する前に実装する予定です。フィードバックは第 1 四半期末に寄せられたため、GitHub の問題について、具体的な詳細とリリース計画の更新についてフォローアップしています（このフィードバックレポートの公開時点で進行中）。 API の大規模な変更については、検討する余地はありますが、一般提供に向けてリリースを進め、より多くのデベロッパーから実践的なフィードバックを得ることが最善の方法であると考えています。Google は今後も議論を続けて、ブラウザの標準化を推進していきたいと考えています。新しい標準が登場する場合は、その標準に慎重に移行するための計画の採用と開発を検討します。

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