为了确保数据的私密性和安全性，汇总服务使用支持差分隐私 (DP) 的框架。这些工具和机制旨在量化和限制单个用户泄露的信息量。我们来讨论其中的一些隐私保护措施。
在摘要报告中添加了干扰信息
当广告技术平台批处理可汇总报告时，汇总服务会创建摘要报告。摘要报告汇总了所有预定义网域密钥的所有贡献（添加了统计噪声）。
报告中添加的噪声不取决于汇总的报告数量、单个报告值或汇总的报告值。
噪声来自于 Laplace 分布的离散版本，该版本会根据相应的衡量 API 和隐私参数 epsilon 缩放到客户端强制执行的贡献预算 (L1 敏感度)。详细了解噪声。
贡献边界
在调用中传递的贡献数量取决于所使用的效果衡量客户端 API（Attribution Reporting API 或 Private Aggregation API），并与特定的贡献边界限制相关联，以便控制摘要报告的敏感性。
如需详细了解每个 API 的贡献预算，请参阅每个 API 的以下部分：
“禁止重复”规则
该规则规定，可汇总的报告（由 report_id 标识为唯一）在单个批次中只能出现一次。如果可汇总报告在每个批次中多次出现，则第一个报告将包含在汇总中，而具有相同 report_id 的后续报告将被舍弃。批量操作将成功完成。
该规则还规定，同一报告不能出现在多个批次中。如果某个报告已在之前成功的批次中批量处理，则该报告不能在后续的批次中处理。后面的一批将以失败告终。
如果没有这些规则，攻击者可以通过在单个或多个批次中包含报告的重复副本来操控特定批次的内容，从而深入了解特定批次的内容。
汇总服务引入的另一个概念是“不相交批次”。这意味着，两个或更多批次中的报告不应共用一个共享 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 的报告。
我们来了解一下如何使用相同的共享 ID。以下是 Report1 和 Report2 中“Shared Info”字段的示例。
这两种报告的 API、版本、attribution_destination、reporting_origin 和 source_registration_time 都相同。由于 report_id 不是共享 ID 的一部分，因此我们可以忽略此差异。唯一的另一个区别是 scheduled_report_time。我们进一步来看，Report1 的 scheduled_report_time 为 February 19, 2024 9:08:10 PM，Report2 的 scheduled_report_time 为 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 的报告，然后重试。
如需详细了解批处理，请参阅批处理策略指南。
预先声明汇总键
向汇总服务提交批量时，必须同时包含从报告来源收到的可汇总报告和输出网域文件。输出网域包含将从可汇总报告中检索到的键或存储分区。
从隐私保护的角度来看，即使没有真实报告与特定键匹配，也会向输出网域中预先声明的所有键添加噪声。指定输出网域可防范此类攻击：如果输出中存在密钥，会泄露关于单个用户 / 事件的信息。例如，如果您只向一位用户展示了广告系列，那么在输出中收到键（即使存在噪声）就表示该用户后来完成了转化。通过事先指定此网域，我们可以确保其中不会透露有关用户贡献的任何信息。
键或存储分区是广告技术平台在 Attribution Reporting API 或 Private Aggregation API 中声明的 128 位密钥，广告技术平台可以使用这些键对要跟踪的维度进行编码。
系统只会考虑汇总预先声明的键，并将其纳入摘要报告中。摘要报告中各存储分区的汇总值将会添加统计噪声，这会反映在创建的摘要报告中。
从本质上讲，如果汇总键包含在输出网域文件中，但未包含在任何批量报告中，即使汇总值为零，最终摘要报告也可能为非零值，因为为保护隐私而添加了噪声。
请注意，在撰写本文时，我们正在考虑一项名为 key-discovery 的功能。借助键发现功能，广告技术平台无需预声明键即可处理可汇总的文件，但为了在前面所述场景中保护隐私，系统会执行额外的阈值步骤。