データのプライバシーとセキュリティを維持するため、Aggregation Service では差分プライバシー（DP）をサポートするフレームワークを使用しています。ツールやメカニズムは、個々のユーザーによって公開される情報の量を定量化し、制限するように設計されています。これらのプライバシー保護のいくつかについて説明します。
概要レポートにノイズを追加しました
広告テクノロジーが集計可能レポートをバッチ処理すると、集計サービスが概要レポートを作成します。概要レポートは、統計的ノイズが追加された、すべての事前定義済みドメインキーの貢献度を集計したものです。
レポートに追加されるノイズは、集計されたレポートの数、個々のレポート値、集計レポート値に依存しません。
ノイズは、対応する測定 API とプライバシー パラメータ epsilon に応じてクライアントによって適用される貢献度予算（L1 感度）にスケーリングされたラプラス分布の離散バージョンから取得されます。詳しくは、ノイズをご覧ください。
貢献度の境界
使用する測定クライアント API（Attribution Reporting API または Private Aggregation API）に応じて、呼び出しで渡されるコントリビューションの数は特定のコントリビューションの境界制限に関連付けられ、サマリー レポートの機密性を制御します。
API ごとの資金提供の予算について詳しくは、各 API の次のセクションをご覧ください。
「重複なし」ルール
このルールでは、report_id で一意に識別される集計可能レポートは、1 つのバッチに 1 回しか表示されないと規定されています。集計可能なレポートがバッチごとに複数回表示された場合は、最初のレポートが集計に含まれ、同じ report_id の後のレポートは破棄されます。バッチは正常に完了します。
また、同じレポートを複数のバッチに含めることはできません。以前に成功したバッチですでにレポートがバッチ処理されている場合、同じレポートを後のバッチに使用することはできません。後者のバッチは失敗で終了します。
このルールがないと、攻撃者は、1 つまたは複数のバッチにレポートを複製して含めて、バッチの内容を不正に操作して、特定のバッチの内容を把握することができます。
集約サービスによって導入されるもう一つのコンセプトは、互いに素なバッチの一つです。つまり、2 つ以上のバッチに、共通の共有 ID を共有するレポートを含めることはできません。
共有 ID は、集計可能なレポートの shared_info フィールドから収集されたデータの組み合わせです。shared_info フィールドの例を以下に示します。API の version、attribution_destination（Attribution Reporting 用）、reporting_origin、scheduled_report_time、source_registration_time（Attribution Reporting 用）が表示されています。report_id を除くこれらのフィールドはすべて、共有 ID に貢献します。
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://privacy-sandbox-demos-shop.dev",
"report_id": "5b052748-f5fb-4f14-b291-de03484ed59e",
"reporting_origin": "https://privacy-sandbox-demos-dsp.dev",
"scheduled_report_time": "1707786751",
"source_registration_time": "0",
"version": "0.1"
}
source_registration_time は日単位で切り捨てられ、scheduled_report_time は時間単位で切り捨てられるため、同じ共有 ID を共有するレポートも存在します。
2 つのレポートが同じ共有 ID を共有する仕組みをご覧ください。レポート 1 と レポート 2 の共有情報フィールドの例を次に示します。
どちらのレポートも、API、バージョン、attribution_destination、reporting_origin、source_registration_time が同じです。report_id は共有 ID の一部ではないため、この違いは無視できます。もう一つの違いは scheduled_report_time だけです。さらに詳しく調べると、scheduled_report_time Report1 がFebruary 19, 2024 9:08:10 PM、Report2 がFebruary 19, 2024 9:55:10 PM です。scheduled_report_time は時間単位で切り捨てられるため、どちらのレポートでも scheduled_report_time が February 19, 2024 9 PM になっています。すべてのフィールドが同じであるため、両方のレポートに同じ共有 ID があることを確認できます。
scheduled_report_time を確認します。
| Report1 共有情報 | Report2 の共有情報 |
|---|---|
| "shared_info": { | "shared_info": { |
| "API": "attribution-reporting", | "API": "attribution-reporting", |
| "attribution_destination": "https://shop.dev", | "attribution_destination": "https://shop.dev", |
| "report_id": "5b052748-...", | "report_id": "1a1b25aa-...", |
| "reporting_origin": "https://dsp.dev", | "reporting_origin": "https://dsp.dev", |
| "scheduled_report_time": "1708376890", | "scheduled_report_time": "1708379710", |
| "source_registration_time": "0", | "source_registration_time": "0", |
| "version": "0.1" | "version": "0.1" |
| } | } |
両方のレポートが同じ共有 ID を持つことが確認されたので、両方のレポートが同じバッチに含める必要があります。
Report1 が以前に正常に処理されたバッチでバッチ処理され、Report2 が後続のバッチで処理された場合、Report2 を含むバッチは PRIVACY_BUDGET_EXHAUSTED エラーで失敗します。その場合は、以前のバッチで正常にバッチ処理された、共有 ID を持つレポートを削除して、もう一度お試しください。
バッチ処理の詳細については、バッチ処理戦略のガイドをご覧ください。
集計キーの事前宣言
バッチを集計サービスに送信する場合は、レポート元から受信した集計可能レポートと出力ドメイン ファイルの両方を含める必要があります。出力ドメインには、集計可能なレポートから取得されるキーまたはバケットが含まれます。
プライバシーの観点から、特定のキーに一致する実際のレポートがない場合でも、出力ドメインで事前宣言されたすべてのキーにノイズが追加されます。出力ドメインを指定すると、出力に鍵が存在することで単一のユーザーまたはイベントに関する情報が漏洩する攻撃から保護できます。たとえば、1 人のユーザーにのみキャンペーンを表示した場合、出力にキーが含まれていれば（ノイズがあっても）、そのユーザーが後でコンバージョンに至ったことがわかります。このドメインを事前に指定することで、ユーザーの投稿内容が漏洩することはありません。
キーまたはバケットは、Attribution Reporting API または Private Aggregation API で広告テクノロジーによって宣言される 128 ビットのキーです。広告テクノロジーはこれらのキーを使用して、トラッキングするディメンションをエンコードできます。
集計の対象となり、概要レポートに含まれるのは、事前宣言されたキーのみです。概要レポートのバケットの集計値には統計的なノイズが追加され、作成された概要レポートに反映されます。
基本的に、集計キーが出力ドメイン ファイルに含まれていても、どのバッチレポートにも含まれていない場合、集計値がゼロであっても、プライバシーを保護するためのノイズが追加されて、最終的なサマリー レポートはゼロ以外になる可能性があります。
なお、この記事の執筆時点では、key-discovery という機能が検討されています。鍵の検出により、広告テクノロジーは事前に宣言された鍵を必要とせずに集約可能なファイルを処理できるようになりますが、前述のシナリオでプライバシーを保護するため、追加のしきい値手順が実行されます。