2023 年第 2 季度的季度报告总结了就 Privacy Sandbox 提案收到的生态系统反馈以及 Chrome 的回应。
为践行对 CMA 的承诺，Google 同意公开提供 关于 Privacy Sandbox 的利益相关方互动流程的季度报告 （请参阅 承诺）。 这些 Privacy Sandbox 反馈摘要报告是通过汇总 Chrome 从反馈 概述，包括但不限于：GitHub 问题，反馈表单提供于 privacysandbox.com、行业会议 相关方和网络标准论坛。Chrome 欢迎收到反馈 正积极探索将所学知识整合到 设计决策。
反馈主题按 API 的普遍性排序。方法是 汇总了 Chrome 团队收到的反馈数量， 指定主题，并按数量降序整理。常见反馈 通过审核公开会议的讨论主题确定了主题 （W3C、PatCG、IETF）、直接反馈、GitHub 和常见问题解答 （通过 Google 的内部团队和公开表单）。
具体而言，网络标准机构会议的会议分钟数为 查看 Google 的 1 对 1 利益相关方会议记录；对于直接反馈， 个别工程师收到的电子邮件、API 邮寄名单和公众发来的电子邮件 并考虑了反馈表单。随后，Google 的各个团队会进行协调 这些主动联系活动的人员，以确定 与每个 API 相关的新主题的普遍性。
Chrome 对反馈的回应说明是根据已发布的 常见问题解答、对利益相关方提出的问题的实际回应，并确定 专门用于本次公开报道。 反映当前开发和测试的重点、问题和反馈 在 Topics、Protected Audience 和 Attribution 报告 API。
在当前报告期结束后收到的反馈 经过深思熟虑的 Chrome 响应。
首字母缩写词词汇表
- CHIPS
- 具有独立分区状态的 Cookie
- DSP
- 需求方平台
- FedCM
- 联合凭据管理
- FPS
- First Party Set
- IAB
- 美国互动广告局 (IAB)
- IDP
- 身份提供方
- IETF
- 互联网工程任务组
- IP
- 互联网协议地址
- openRTB
- 实时出价
- 加时赛
- 源试用
- PatCG
- 私下竞价技术社区群组
- RP
- 依赖方
- SSP
- 供应方平台
- TEE
- 可信执行环境
- UA
- 用户代理字符串
- UA-CH
- 用户代理客户端提示
- W3C
- 万维网联盟
- WIPB
- 故意 IP 盲化
一般性反馈，不涉及具体的 API/技术
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 数据治理和法规遵从 | 关于在遵守监管要求中使用 Privacy Sandbox 的生态系统指南。 | 与任何新技术一样，每家公司都有责任确保其对 Privacy Sandbox 的使用符合法律规定；Google 无法向他人提供法律建议。不过我们也知道，这是整个生态系统值得关注的一个关键领域。对于每个 API，我们都发布了大量技术文档，为进行必要的法律评估奠定了基础。我们还在努力提供其他材料，以支持各公司的来尽力遵守监管要求。 |
| CMA 定量测试提案 | 详细了解 CMA 定量测试方案 | 我们正在与 CMA 合作设计实验，让您了解弃用第三方 Cookie 的影响，并推出 Privacy Sandbox 提案对整个生态系统的影响。4 月，CMA 发布了有关测试和试验阶段的总体指南，随后在 6 月发布了详细指南。我们鼓励用户直接与 CMA 分享有关 CMA 的定量检测提案的问题或反馈。 |
| Chrome 协助测试模式 | 关于测试时间表的更多信息和说明 | 我们在 5 月 18 日发布了一篇博文，分享了关于 Chrome 协助测试的两种模式的更多信息。这些细节并非最终版本，我们将在 2023 年第 3 季度发布进一步的实施指南。 |
| 分区存储 | 在 Chrome 协助测试期间是否会使用分区存储？ | 在第三方 Cookie 弃用实验之前，我们会向所有用户提供存储空间分区。因此，它将为实验的所有实验组启用。在此期间，网站可以选择启用弃用试用，以收回未分区的存储空间。 |
| 制作支持 | Chrome 采取了哪些流程来为影响生态系统的 Privacy Sandbox 技术问题和上报问题提供支持？ | Google 提供了多种渠道，以便广告技术平台报告问题以及进行必要的上报。 请参阅我们的开发者帖子，详细了解公共和私密论坛上的反馈和上报问题。 |
| 报名时间表 | 当前的注册时间范围过短 | 我们仍在评估强制执行的期限，并希望整个生态系统提供更合适的时间安排。 |
| 邓氏编码 | 详细了解有关注册和证明的邓氏编码要求 | 参与者可在 Dun & Bradstreet 网站上找到获取邓氏编码的要求。具体要求因市场而异，因此参与者应查看所关注具体市场的网站。不过，一般来说，参与者需要提供其商家的基本信息，例如企业的名称、地址，以及企业主或管理者的联系信息。我们可能也会要求参与者提供财务信息，例如企业的年收入。申请完成后，D&B 将对其进行审核，并在申请获批后发放邓氏编码。 |
| 从源试用转换为正式版 | 从源试用转换为正式版是否会影响当前的源试用测试人员？ | 从 7 月份开始，测试人员将能够访问正式版的相关性 API 和效果衡量 API。这会使源试用的可用性与正式版的推出时间重叠。 |
| AdExchanger 研究 | 详细了解调查问卷方法 | 该问卷调查请回复者估算其商家的同步率和收入。受访者的回答具体问题由他们自己决定。 |
| 参数值 | 如何确定噪声等级、匿名性阈值和隐私预算等参数值？ | 此 GitHub 说明文档介绍了 Privacy Sandbox API 背后的更一般原则。许多值仍在最终确定，欢迎就这一主题提供反馈。 |
显示相关内容和广告
主题
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 隐私保护 | 评估 Topics API 在隐私保护方面的研究 | 我们积极参与研究社区，通过论文、报告和研讨会演示来展示我们关于 Topics API 隐私保护属性的研究结果。我们很高兴看到研究社区中有更多的外部成员参与这一领域。 Topics API 使大规模跟踪用户变得非常困难，从而保护用户免受网络上的常规跟踪。这些论文表明，我们使用 Topics API 取得了成功。它比第三方 Cookie 的隐私性更强，可在用户喜欢访问的网站的同时提供保护。 |
| 主题分类不够精细 | 宽泛的主题分类不包含更细致的主题，包括针对特定区域的主题。 | 根据生态系统之前的反馈，我们在 6 月 15 日发布了一篇博文，详细说明了经过更新的新版分类法，该分类法在收集到来自生态系统的反馈后进行了多项改进。在修改分类法的过程中，我们与整个生态系统中的几家公司进行了合作，例如 Raptive（前身为 CafeMedia）和 Criteo。更新后的分类会移除我们听到的不太有用的类别，以支持更符合广告客户兴趣的类别，同时继续履行我们排除可能敏感主题的承诺。 我们建议整个生态系统中的成员查看最新分类并就变更内容提供反馈。 |
| 分类和分类器更新流程 | 详细了解 Topics 分类和分类器发布节奏，以及公司如何为此类更新做好准备。 | 正如近期的博文中所述，我们预计分类法会随着时间的推移而不断改进，为了对分类进行管控，我们最终会交由代表整个行业利益相关方的外部相关方来负责。我们还在 topics-announce 群组中分享了该公开范围渐增计划。 |
| 对第一方信号的影响 | 近期更新类目中的主题数量增加可能很有价值，并因此降低其他基于兴趣的第一方信号的价值。 | 在 2023 年第 1 季度的报告中，CMA 表示：“我们知道，Google 一直在与广告技术供应链中的几个市场参与者讨论其提议的新分类法。虽然一些大型发布商表示，主题效用越高，他们基于第一方数据的解决方案将面临更大的竞争压力，但我们的初步观点是，效用越大，整体竞争越激烈，特别是小型发布商在第三方 Cookie 被弃用后能够继续通过其广告资源创收的能力。”我们认同 CMA 的这一意见。 |
| 对不同类型的利益相关方的实用性 | 与其他生态系统参与者相比，充当 SSP 和 DSP 的广告技术平台可能具有显著优势。 | 我们的回复与往期相比没有变化： “Google 承诺遵守 CMA，在设计和实施 Privacy Sandbox 提案时，不会通过自利自己的业务来扭曲竞争，并考虑到对数字广告领域的竞争以及对任何规模的发布商和广告主的影响。我们将继续与 CMA 密切合作，确保我们的工作遵守这些承诺。随着 Privacy Sandbox 测试的不断进行，我们要评估的一个关键问题是新技术对不同类型的利益相关方的效果如何。在这方面，反馈至关重要，尤其是可以帮助我们进一步改进技术设计的具体且切实可行的反馈。我们与 CMA 合作制定了定量测试方法，并支持 CMA 发布关于实验设计的说明，向市场参与者提供更多信息，并有机会对提议的方法发表评论。” |
| 后代主题 | 如果主题选择条件是浏览器访问频率，细分碎片化是否会导致后代主题一直无法置顶？ | Chrome 目前正在评估其他排名方法，并探索可提升排名的其他信号。我们会适时向整个生态系统通报修改后的计划。 |
| 敏感程度 | Topics API 的目标是确保从 Topics API 获取或衍生的用户信息不如使用当今的跟踪方法所衍生的信息更敏感。 | 我们认为，与当前技术相比，Topics API 的隐私性明显更高，能够显著限制对用户的重新识别，并且旨在排除敏感主题。我们了解，主题可以与第一方数据相关联或结合，以创建敏感类别，但我们认为 Topics API 是在保障用户隐私方面向前迈出的一步，我们也将致力于持续改进该 API。 |
| 类目结构 | 向 Topics 分类添加 ID、版本控制和其他元数据结构 | 目前，我们在 API 响应中包含了类目 ID。随着我们迈向长期治理，我们有必要查看 Topics 对象，并根据需要添加有关版本控制的其他元数据。 |
| 发布商控制 | 发布商应对其网站归类为什么主题有发言权。 | 网站分类错误可能会使主题信号作为一个整体的参考价值略微降低，但分类错误的特定网站所受到的危害与任何其他网站一样大。这是因为网站的相关背景信息始终能用于竞价，即使出现分类错误的情况，也能提供与正确主题相近的信息。欢迎在此处就此主题提供反馈。 允许发布商控制自己的分类会带来风险。网站可能有意地对其网站进行错误分类，削弱其对所有人的效用，或对不太常见的主题中的敏感含义进行编码，从而损害用户隐私。 |
| Chrome 扩展程序 | 允许 Chrome 扩展程序管理和过滤 Topics（与当前的 Cookie Management 扩展程序类似） | 正如 GitHub 中所述，这应该已经可以实现，但我们也欢迎生态系统提供更多反馈。 |
| 过渡到正式版 | 从源试用转换为正式版时，Topics API 是否会有任何影响？ | 从源试用转换为正式版的用户不会丢失数据。 |
| 隐私权 | 主机名可能包含 Topics API 可能会泄露的私密信息 | 我们采取了多项措施来保护隐私，如此处所述。 |
| 欺诈和滥用行为 | 如何防止欺诈性访问操纵 Topics | 点击此处了解缓解措施。 |
| 主题分类器 | 网站可以请求更改其主题分类吗？ | 我们很想听听整个生态系统中关于这一主题的反馈，欢迎您在此处提供反馈。 |
| Topics 提供商网站 | 将托管多个主题内容的特定网站指定为“特殊主题提供商网站”并根据网页提供的标记训练分类器。 | 我们正在在此处讨论提案，欢迎您提供更多反馈。 |
Protected Audience API（以前称为 FLEDGE）
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 根据流量情况调整投放速度 | 由 SSP 驱动的过滤（以优化每秒查询次数 (QPS) 负载）的性能影响 | 我们花费了大量时间来考虑如何调整流量，建议 SSP 利用缓存。 |
| 测试音量 | Protected Audience 测试并非易事，因为 SSP 和 DSP 难以获得大量流量。 | 我们在不断鼓励 SSP 和 DSP 合作伙伴采用并测试 Protected Audience。正式版已开始，我们相信启用了 PA 的流量百分比将使合作伙伴更容易接受测试。 |
| 复杂性 | 实施 Protected Audience 解决方案需要投入大量精力和成本。 | 我们深知，新技术很难采用，包括 Privacy Sandbox。Privacy Sandbox 团队与众多利益相关方密切合作，为他们提供指导和支持，并不断评估其他加速器，以支持生态系统的采用。 |
| 可信执行环境 | 支持非公有云环境中可信执行环境 (TEE) | 虽然我们正在探索可能支持云端解决方案以外的选项，但由于本地安全限制，需要对 Privacy Sandbox 进行耗时评估，因此目前支持本地 TEE 是不可行的。鉴于 Privacy Sandbox 安全性要求以及本地部署带来的重大挑战，我们认为，持续扩展和改进云端部署（例如，除 AWS 之外还支持 GCP）对整个生态系统最有利。不过，我们欢迎您提供更多反馈，说明为什么必须完成此要求。 |
| 费用结构 | 出价和与客户端模型相比，竞价服务提案会增加广告技术平台的费用和复杂性。 | 我们目前正在制定一份指南，用于估算在“出价与竞价”部分内的出价和竞价工作流程竞价服务器，它与广告技术平台使用有关，有助于我们实现设计目标之一。 |
| K-Anon 时间轴 | 何时会对 `renderUrl` 强制执行计划的 k-匿名性约束？ | 我们正在制定执行时间表的相关说明，很快就会发布。 |
| runAdAuction 限制 | Chrome 能否限制 runAdAuction 只能从顶级页面调用？ |
虽然我们的设计完全支持可从顶级网域调用 runAdAuction，但我们认为，如果将它限制为只能从顶级网域调用，会对发布商造成更不利的影响。我们从生态系统中特别得知，Privacy Sandbox 需要最大限度地减轻发布商和广告客户的负担。该反馈符合网站开发的一般原则，即网站所有者可以使用第三方工具运行其网站。Privacy Sandbox 的目标是促进生态系统的健康发展，且无需规定发布商和广告技术的运作方式。 通过允许发布商选择如何以及由谁在其网站上调用 runAdAuction，我们相信，我们可以让发布商灵活地找到符合其要求的最佳路径。 |
| 实施方面的支持 | Chrome 能否构建或参与多卖方竞价的开源实现？ | Privacy Sandbox 旨在开发不依赖第三方 Cookie 或其他跨网站标识符的隐私保护技术。我们希望促进一个健康的生态系统，而无需设置广告技术平台的运作方式。 我们已在 GitHub 代码库中发布了 API 运作方式指南，并乐意与业界共同探索各种解决方案。 我们不打算构建任何具体的实现方案，因为我们的核心职责是开发平台技术，而不是制定使用这些技术的策略。我们的技术将帮助广告技术公司为消费者提供适当的隐私保护措施，从而为客户提供最佳服务。 |
| 多卖方竞价 | Chrome 是否会强制分享组件竞价的胜出者？ | Protected Audience API 旨在让发起多卖方竞价的各方能够将信息传递给组成部分竞价（注意：仅在发起竞价之前）。 尽管如此，我们仍无法让浏览器分辨某条信息是否为内容相关胜出者，因此我们无法实施拦截或要求提供某些信息。 |
| 用户对意见征求跟踪的偏好设置 | 广告技术平台向 PA 询问如何正确实现用户意见征求跟踪 | 我们根据第 1 季度的回答做出了以下处理： “对于特定广告，相关广告技术平台最能控制展示哪些广告素材或如何选择这些广告素材。” 我们在 5 月的 WICG Protected Audience 会议期间讨论了与此问题相关的多个场景，欢迎您就此问题提供更多反馈和讨论。 |
| 自定义受众群体 | Protected Audience API 是否支持与创建自定义受众群体相关的 SSP 用例？ | 借助 Protected Audience API，SSP 和其他广告技术提供商能够拥有和管理自定义受众群体。我们正在制定有关如何将 SSP 与 PA API 集成的进一步指南，并将提供给 SSP 和其他广告技术提供商，以支持其集成工作。 |
| 表现形式 | Protected Audience API 是否支持视频？ | 视频广告可采用以下两种方式之一投放：VAST XML 或 HTML（最终也可能会将 VAST XML 加载到视频播放器中的外播广告）。买方可以通过呈现网址返回任意一种格式。VAST 规范近期已更新，可支持 Attribution Reporting API。投放视频广告的网站需要为通过 Protected Audience API 投放广告的方式做好准备。这意味着，请确保展示位置代码能够将网址从 Protected Audience iframe 传递到视频播放器。对于围栏帧，我们将先于满足使用围栏帧的要求（不早于 2026 年）之前满足视频需求。 |
| 节奏 | 如何将 Pacing 用例与 Protected Audience API 搭配使用？ | 感谢您的反馈。我们希望看到更多来自更多 SSP 合作伙伴的此请求实例以及更多详细信息，因为迄今为止这一直是 DSP 的主要问题。 |
| 更新频率 | dailyUpdate 的来电频率（每个兴趣群体每天最多 1 次）可能不足以满足某些使用情形，例如更新商品信息。 |
感谢您的反馈。还有其他解决方案可让广告技术平台使用按不同频率刷新的信号（例如 K/V 查询）。 |
| 广告质量控制 | 发布商如何实施广告质量控制？ | 现在，Protected Audience API 为发布商提供了相关功能，使其能够向 SSP 告知他们可以在竞价配置中建立的特定控制措施，即出价前（即基于与广告关联的标签创建的拒绝名单）。我们欢迎您就生态系统可能需要的任何其他功能提供反馈。 |
| 调试 | 何时会移除 forDebuggingOnly 功能？ |
我们计划针对因第三方 Cookie 弃用而造成的损失事件弃用 forDebuggingOnly。我们计划最早在 2026 年弃用针对获胜事件的 forDebuggingOnly。 |
| 跨设备兴趣组 | 提案：为经过身份验证的用户代理启用跨设备兴趣群体 | 我们正在评估此方案，不过，如此 GitHub 问题所述，跨设备定位的特异性非常高会带来严重的隐私问题。 |
| （第 1 季度同期报告）动态再营销 | 弃用第三方 Cookie 后，是否仍然可以使用 Protected Audience API 进行动态再营销？ | 我们认为，使用 Protected Audience 可以达到此用例（如此处所述）。 |
| 点击相关数据 | 向 browserSignals. 添加与点击相关的数据 |
目前，我们要求你进一步说明点击发生的时间，从而给出初步排名。 |
| （2022 年第 4 季度也报告）Protected Audience 中用户定义的函数 | Protected Audience API 如何支持用户定义的函数 (UDF)？最终用户可以对这些函数进行编程以扩展该 API 的功能。 | 提出此问题的广告技术平台还表示，他们仍在评估使用 UDF 能做些什么，因此这里还没有切实可行的反馈可供回应，至少要等到正式版发布之前。 |
| 货币 | 货币金额不应使用浮点表示。 | 我们在此详细介绍了此问题。 |
| 非 DSP 广告选择功能 | 广告服务器在 Protect Audience API 竞价中发挥什么作用？ | 我们已了解到，要求广告服务器继续提供出价后广告选择 / 动态广告素材优化服务。我们目前正在评估当前 Protected Audience API 与这些要求之间可能存在的详细差距分析。 |
| GenerateBid | 对 Google Ads 的提案从 generateBid 为每个广告兴趣组返回多个候选广告，并在 `scoreAd` 中为这些候选广告打分。 |
目前正在评估。欢迎您在此处提供其他反馈。 |
| 竞价订单 | Protected Audience API 竞价是否必须作为最后进行的竞价，才能从所有其他竞价的结果中获取有用信息？ | Protected Audience API 能在最后运行，没有任何技术要求。 |
| 非用户启动的导航 | 公开非用户启动的导航 | 我们正在审核此要求，并在此处进行讨论 ，欢迎您提供更多反馈。 |
| 缓存 | 如果用户状态发生变化，SSP 不应从缓存构建给定 DSP 的 perBuyerSignals。 | 我们了解到，缓存并非适用于 perBuyer 信号的所有应用场景，因此我们正在评估其他选项。我们欢迎生态系统就缓存是否适合其用例提供任何其他反馈。 |
| Attribution Reporting 和 Protected Audience | Attribution Reporting API 和 Protected Audience API 如何协同工作？ | Protected Audience API 目前支持在这两种 Attribution Reporting API 模式（事件级报告和摘要报告）中使用集成。我们在 6 月 1 日分享了关于经过改进的 Protected Audience API 和 Attribution Reporting 集成的更多信息。您可以在此了解相关信息。 |
| 服务器端点 | 在最终设计中，该服务器端点是否会成为可信的汇总服务器？ | 服务器端点是一个由广告技术平台维护的端点，独立于用于处理收集和转换的报告的可信汇总服务器。我们目前未计划对报告端点进行任何更改。当前的设计旨在确保可汇总报告本身（具有加密载荷）不会跨网站数据泄露，因此不需要可信端点。另一个复杂问题是，不同的广告技术平台可能会采用不同的所需批处理策略。欢迎您在此处提供其他反馈。 |
| WebIDL | 当前的 Protected Audience API 规范与 WebIDL 规范不兼容。 | 我们正在评估此反馈，并在此处讨论该问题。 |
| 意见征求管理 | Protected Audience API 中如何处理意见征求信号传递？ | 情境信息不在 Protected Audience API 的涵盖范围内。我们正在讨论此问题，欢迎您提供更多反馈。 |
| 基于账号的营销 | 基于账号的营销应用场景是否可行？ | Protected Audience API 支持各种基于受众群体的营销用例。我们将继续了解 Protected Audience API 如何为这一特定用例提供有力支持，并欢迎生态系统就此问题提供其他反馈。 |
| 组件竞价 | 组件竞价参与者得分是多少？ | 组成部分竞价不会直接对兴趣群体进行评分，而是为 DSP 通过 generateBid 函数提交的广告和出价进行评分。generateBid() 函数针对每个兴趣群体运行，DSP 会在执行 generateBid 时返回以下内容：
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| 外部贡献 | 请求支持对键值对服务器 GitHub 代码库进行外部贡献。 | 我们希望更新相关流程，以便支持外部人员向 GitHub 代码贡献代码。 |
| 兴趣组规模 | IG 可以支持的最大密钥数量是多少？ | 目前，一个 IG 的大小上限为 50 kb，密钥也计算在内。我们欢迎进一步讨论大小限制。 |
| 批量处理 | 如何减少 K/V 服务器调用次数？ | 您可以使用 HTTP Cache-Control 标头来减少 K/V 调用次数。例如，它可以在不同的竞价中缓存，也可以缓存在一个网页上的所有广告位中。 |
| 版本控制 | 支持多个版本的广告技术平台代码 | 出价和竞价服务将支持多个版本的广告技术平台代码。在 Bidding and Auction API 中，SelectAd 请求可以指定用于竞价请求（即用于出价 / 竞价和报告）的代码版本。 |
| 共享存储空间 | 支持在出价和竞价服务中写入共享存储空间。 | 目前，出价和竞价服务不支持共享存储空间，但我们欢迎您就此类应用场景对生态系统的重要性提供更多反馈。 |
| 从网站到应用 | 支持兴趣群体从网站到应用分享。 | 跨 Chrome 和 Android 的 Protected Audience API 部署目前未涵盖“网站到应用”应用，但我们有兴趣了解生态系统对此应用场景的重要性。 |
| K-匿名性 | 如何处理 K-匿名性回退 | 我们正在讨论此问题，欢迎您提供更多反馈。 |
衡量数字广告
Attribution Reporting（和其他 API）
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 浏览型转化事件级报告的其他配置 | 关于替代浏览型转化事件级报告配置的反馈 | 我们收到了一些反馈，指出当前的事件级配置不是最优的，因此希望您就最佳全局配置提供反馈。我们很乐意就此问题提供更多反馈，并且认为我们灵活的事件级说明文档也有助于解决此问题。 |
| 灵活的事件级配置 | 事件级灵活配置功能处于什么状态？ | 我们分享了关于灵活事件级配置的文档。此功能仍处于提案阶段，我们希望就此功能对整个生态系统是否有价值获得更多反馈。 |
| 灵活的事件级配置 | 如何协调来自不同方的冲突报告？ | 大多数报告场景通过使用汇总报告来解决，而灵活事件级配置提案则旨在提高事件级报告（最常用于优化用例）的灵活性。我们欢迎您就此情况提供更多的生态系统意见/反馈。 |
| 来源注册 | 如果来源注册发生在触发器注册之后，该怎么办？ | 目前，如果来源注册发生在触发器注册之后，则来源和触发器无法相互归因。这似乎属于极端情况。我们欢迎您就此问题提供任何其他反馈，如果许多广告技术平台都可能遇到这种情况，我们会着手解决。 |
| 与多家广告代理机构合作 | 当广告客户与多个广告代理机构合作时，DSP 如何使用 Attribution Reporting API？ | 该 API 支持重定向，因此即使广告客户与多个广告代理机构合作，也可以使用该 API。此外，为了确保该 API 更好地保护隐私，我们对重定向也设置了一些限制。我们还针对广告技术平台提出的具体场景，确定了利用 Shared Storage API 的潜在权宜解决方法。我们欢迎您就此情况提供更多反馈，我们将根据这些反馈不断调整。 |
| 目标页面限制 | 自动刷新广告用例可能会受到目标页面限制的影响。 | 我们在 5 月 1 日的 WICG 会议中讨论了此问题，希望能就合理的限制征求反馈意见。我们在包含事件级报告的归因报告说明中添加了相关说明，指出浏览器可以限制来源网站代表的“目标”eTLD+1 的数量。（请参阅拉取请求）。 |
| Attribution Reporting 和 Protected Audience | Attribution Reporting API 和 Protected Audience API 如何协同工作？ | Protected Audience API 目前支持在这两种 Attribution Reporting API 模式（事件级报告和摘要报告）中使用集成。我们在 6 月 1 日分享了关于经过改进的 Protected Audience API 和 Attribution Reporting 集成的更多信息。您可以在此了解相关信息。 |
| 灵活的事件级配置 | 现在，这些参数是可以配置的，欢迎分享关于噪声模拟的最佳实践。 | 我们在 GitHub 上共享了代码，任何人都可以使用它们来评估自己想要测试的任何灵活事件级配置的信息增益和噪声影响。我们很乐意听取选择使用代码进行测试的任何人的反馈，并想分享反馈。 |
| 跨应用和跨网站归因衡量 | 跨应用和跨网站归因衡量功能何时推出？ | 我们在 5 月 9 日宣布推出一项通过 Attribution Reporting API 进行跨应用和跨网站归因衡量的实验。虽然我们已针对 Chrome 115 中的相关性和衡量 API 推出正式版，但目前并未计划在 Chrome 115 中正式发布跨应用和网站归因衡量。 |
| 删除重复的转化 | 如何让独立的效果衡量解决方案与 ARA 协调一致？ | 与目前的标准做法一样，广告客户将与第三方独立衡量服务提供商合作，对转化报告进行重复数据删除。我们提供了相关资源，帮助您为事件级报告删除重复的转化。 |
| Attribution Reporting 数据库更新期间会丢失数据 | 当 Chrome 按照公告更新 Attribution Reporting 数据库时，是否会丢失任何数据？ | 从 Chrome 稳定版 115 开始，我们将默认开始为部分 Chrome 用户启用相关性和效果衡量 API。随着我们不断监测潜在问题，正式版应用将会逐步推出。我们的目标是在 2023 年第 3 季度之前在几周时间内实现 100% 的可用性。这一时间将与相关性和效果衡量源试用结束的时间一致。从 7 月开始，测试人员将可以注册为正式版使用这些 API。这样，在源试用期间的推出情况与在注册后正式推出的情况会有所重叠。您的源试用令牌的有效期至 9 月 19 日，但我们建议您在到期之前注册这些 API，以便在源试用期间无缝过渡，而不会中断任何正在进行的测试。 如此公告中所述，在旧版（M113 及更低版本）中注册的数据在更新后不会迁移，因此可能会丢失数据。调试报告中不会显示这种数据丢失情况，但我们会尽力避免数据丢失，在数字 114 到 115 之间。 |
| 结算 | 使用 Attribution Reporting 进行每次转化费用结算 | 如这篇文章所述，由于事件级报告和摘要报告中添加了噪声，因此 Attribution Reporting API 可能不适合采用每次转化费用结算需求。我们鼓励生态系统参与者针对 GitHub 上的 Attribution Reporting API 对各种结算模型的影响提供反馈。 |
汇总服务
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 可汇总报告延迟时间变更 | 根据生态系统的反馈，该提案将可汇总的报告延迟时间从 [10-60 分钟] 更改为 [0-10 分钟] 的积极回应 | 我们非常高兴看到这项提议的更改获得了积极的反响，并鼓励整个生态系统继续针对我们的提议提供反馈。 |
| 本地解决方案 | 是否可以在本地数据中心部署汇总服务？ | 虽然我们正在探索可能支持云端解决方案以外的选项，但由于本地安全限制，需要对 Privacy Sandbox 进行耗时评估，因此目前支持本地 TEE 是不可行的。鉴于 Privacy Sandbox 安全性要求以及本地部署带来的重大挑战，我们认为，持续扩展和改进云端部署（例如，除 AWS 之外还支持 GCP）对整个生态系统最有利。不过，我们欢迎您提供更多反馈，说明为什么必须完成此要求。 |
| 重新处理不同时间段的报告 | 能够重新处理不同时间段的报告 | 我们曾收到过类似请求，希望能够针对不同日期范围拆分批次。一种方案是支持使用广告技术平台定义的标签扩展共享 ID，以便将报告拆分为不同的批次。我们正处于对此流程的评估早期阶段，并会随着此提案的制定及时更新整个生态系统。 |
| 可信执行环境对隐私的影响 | 对可信执行环境的隐私影响持积极态度 | 我们很高兴听到生态系统对我们的提案做出了积极回应，我们也欢迎您在继续迭代和发展的过程中收到更多反馈。 |
| 服务条款 | 接受“汇总服务条款”的截止日期是什么时候？ | 虽然我们尚未指定接受条款及条件的截止日期，但我们建议生态系统公司尽快接受条款及条件，以免注册延误。我们鼓励公司在有任何疑问时与我们联系。 |
| 密钥发现 | 借助键发现功能，测试人员无需明确列出可能的键组合即可查询汇总报告，从而处理用于跨广告网络归因的摘要报告，从而提升性能和准确性。 | 我们目前正在探索可能的解决方案和临时解决方法，欢迎整个生态系统提供更多反馈。 |
Private Aggregation API
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 举报来源 | 如何定义报告来源？ | 报告来源始终是不公开汇总调用方的脚本来源。 |
| 128 位键空间 | 阐明了 128 位密钥空间限制 | 我们将进一步明确这一键空间限制，并解决页面间的不一致问题。我们建议您使用哈希策略来避免超出此键空间的要求。 |
| 每份报告的贡献上限 | 目前每份报告 20 次贡献的限制过低。 | 我们愿意考虑拆分报告，而不是达到上限就截断报告，而不是提高贡献数量上限。随着此提案的完善，我们将与整个生态系统互动交流。 |
| 覆盖面报告 | 请求跨平台/跨设备报告。覆盖面是品牌广告的基础指标。广告客户依靠跨平台/跨设备估算数据来生成覆盖面和频次报告，以便分析广告系列并分配支出。覆盖面模型会将第三方 Cookie 用作衡量第三方环境中展示的广告的信号，因此广告技术平台要求在第三方 Cookie 被弃用后采用替代解决方案。 |
Privacy Sandbox 团队正在探索相关功能，以便在第三方 Cookie 弃用后支持跨网域覆盖面方法。 我们欢迎生态系统提供其他反馈。 |
限制隐蔽跟踪
用户代理缩减/用户代理客户端提示
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| （在 2023 年第 1 季度也报告过）关于更多外形规格的提示 | 请求用户代理客户端提示 (UA-CH) 以提供其他设备规格，例如电视、VR | 我们仍在努力制定一些关键的设计决策（是提供诸如“TV”之类的单个值，还是提供一系列外形规格功能），但仍继续关注这一想法的原型。 |
| 隐私预算 | 如果发送的请求过多，隐私预算限制可能会导致 UA-CH 请求变得不确定。 | 我们目前没有关于隐私预算提案的新更新，但已承诺在第三方 Cookie 被弃用之前，不会限制对 UA 客户端提示的请求。 |
| 网站兼容性 | 网站使用 UA-CH 品牌来限制某些浏览器访问网站。 | 创建品牌列表有很多有效的用例，其中之一就是兼容性。UA 可以免费使用多个品牌来解决这类问题。 |
IP 保护（以前称为 Gnatcatcher）
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 欺诈和滥用行为 | 公司可通过 IP 保护设置反欺诈措施吗？ | 我们了解防欺诈用例的重要性以及可能对这些用例的影响。我们计划在今年夏末发布有关支持反欺诈的更多详情。我们正在征求生态系统的反馈，以了解如何更好地支持反欺诈用例。 |
| GeoIP | 详细了解 GeoIP 的测试和部署时间表 | Chrome 最近发布了新信息，其中详细介绍了我们的 GeoIP 计划。我们计划于第 3 季度发布有关部署时间表的更多信息。我们预计会在初期面向一小部分流量推出 IP 保护作为用户自选功能。原因在于，我们知道此提案可能会给公司带来一些重大变更，因此希望给整个生态系统留出一些时间来调整和提供反馈，然后再更广泛地推出新功能。 |
| 账号身份验证 | 使用代理服务器进行账号身份验证的工作原理是怎样的？ | 我们计划在今年夏末发布有关账号身份验证的更多详细信息，不过我们已经分享了一些初始注意事项。 |
反弹跟踪缓解措施
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 测试指南 | 有关如何测试“跳出跟踪缓解措施”功能的信息 | 我们在 5 月发布了一篇 博文，进一步说明了如何测试“反弹跟踪缓解措施”。 |
| 文档 | 反弹跟踪提案的清晰度 | 当前提案尚在进行中，Chrome 会继续更新该提案，以便向整个生态系统提供清晰易懂的信息。我们正在努力提供更多详细信息，欢迎您提供更多反馈。 |
| Cookie 删除 | “跳出跟踪缓解措施”会删除网域中的所有 Cookie 吗？ | 跳出跟踪缓解措施 (BTM) 会清除所有存储空间和缓存，如此处所述。 |
| 规避跳出跟踪缓解措施 | 使用弹出式窗口或新标签页执行重定向可以绕过反弹跟踪程序分类。 | “跳出跟踪缓解措施”规范仍处于开发阶段。到目前为止，我们主要关注的是同一标签页重定向，但未来还计划开发弹出式窗口流程。欢迎您在此处提供其他反馈。 |
隐私预算
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 邻近区域定位 | 隐私预算可能会影响邻近区域定位用例。 | 我们已收到关于此问题的反馈，并且希望详细了解这一生态系统的潜在影响。 |
增强跨网站隐私边界
First-Party Set
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| （在之前季度中也报告过）网域限制 | 申请增加关联网域的数量 | Chrome 正在评估所关联子集的适当数值限制，以便针对已确定的用例平衡隐私性和实用性。从一开始，Chrome 就表示“关联”子集的确切数量尚未确定。 |
| 嵌入式应用场景 | 支持需要 First-Party Set、CHIP 和共享存储空间的嵌入式用例 | Chrome 已收到关于此使用情形的反馈，相关团队正在进行调查，欢迎您提供更多反馈。 |
| 仓库管理 | 有关在存在不一致或疏忽时从 GitHub 代码库中移除 First-Party Set 的政策的相关信息 | Chrome 已收到关于此使用情形的反馈。该团队正在展开调查，欢迎您提供更多反馈。 |
| 用户教育 | Chrome 应提高用户对 First-Party Set 的认知度和了解，以提高采用率。 | Chrome 致力于向用户介绍 First-Party Set，并发布了一篇与此相关的 帮助中心文章（链接到 Chrome 界面）。此外，Chrome 还致力于持续学习如何在适当的情境下提供有力教育。 |
| 第三方 Cookie 之后 | 弃用第三方 Cookie 后，第三方 Cookie 将继续存在于 First-Party Set 中。 | 尽管 requestStorageAccess 和 requestStorageAccessFor 确实能够重新在明确定义的特定用例中使用第三方 Cookie，但它们现在需要网站进行主动调用，而不是像当前状态的第三方 Cookie（在 Chrome 中）一样默认提供。虽然在单个集中进行的这种调用不需要用户批准，但用户可以通过在“设置”中选择停用此行为来防止出现这种情况。 如需了解更多信息，请参阅帮助中心文章（链接到 Chrome 界面）。随着 FPS 提升至 100%，我们计划在现有开发者指南的基础上进行扩展。 |
| First-Party Set 提交 | 重命名所需的 .well-known/first-party-set 以包含 .json 扩展名。 |
我们进行此项变更是为了确保某些网站托管方案受支持。 |
| IANA 注册 | first_party_sets.JSON 应向 IANA 注册 |
我们正在考虑该方案，欢迎您在此处提供其他反馈。 |
Fenced Frames API
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 广告拦截 | 围栏框架可让广告拦截器更轻松地屏蔽广告。 | 扩展程序可以与围栏框架的交互方式与其与 iframe 的交互方式类似。围栏框架即将导航到的实际网址也将对扩展程序可见，因此它们可以像在 iframe 中一样，应用任何网址匹配规则进行屏蔽。只是无条件地屏蔽所有围栏框架可能会破坏围栏框架的非广告用例。 |
Shared Storage API
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 采用率更高 | 共享存储空间应成为适用于所有浏览器的业界标准。 | 我们欢迎并认可这些反馈。Chrome 将继续积极参与 W3C 大会，以倡导提案、征求反馈意见并推动客户采用。 |
| 输出门 | 共享存储空间输出门控过于受限。 | 我们正在考虑此反馈，欢迎生态系统提供更多反馈，了解输出门槛为何过于受限。 |
| 法规遵从 | 共享存储空间如何处理数据保留政策等法规遵从？ | 共享存储空间可让您灵活地实现和自定义逻辑，以控制任何存储数据的生命周期。广告技术平台可以根据写入时间戳更新或清除共享存储空间数据。 |
| A/B Testing | 如何对 Shared Storage 和 Protected Audience API 进行 A/B 测试？ | 我们正在努力就此问题发布更多指南，希望日后可以分享更多详细信息。 |
| 共享存储空间上限 | 达到共享存储空间上限后会发生什么？ | 如果达到该限制，系统将不再存储其他输入。 |
| 在同一网页加载过程中多次访问 | 如果在网页加载时多次访问共享存储空间，会出现什么情况？ | 处理这种情况的最佳方式是通过 window.sharedStorage.append(key, value) 函数。而不是更新每个广告的值，否则会导致多个广告发生冲突。附加函数只会将新值添加到现有值的末尾。 |
| iframe 功能 | 当第三方 Cookie 被弃用后，如果某些 iframe 功能不再正常运行，共享存储空间是否会支持某些 iframe 功能？ | 弃用第三方 Cookie 后，iframe 中的本地存储将按顶级网站进行分区，但 iframe 本身不会被屏蔽。iframe 本地存储空间中的数据无法在多个顶级网站上复制，但本地存储空间可在 iframe 内使用。 |
条状标签
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 分区限制 | 每个分区站点 10 KiB 的容量仍然很大，希望能将其降低。 | Firefox 已经在 CHIPS 上取得了 积极的排名。为了支持 Webkit，我们鼓励开发者针对 此 GitHub 问题直接向 Apple 提供反馈，反映其在用例中优先使用分区 Cookie 而非分区存储。 |
| 经过身份验证的嵌入 | 由于不同的分区会影响经过身份验证的嵌入，芯片可能会影响当前的单点登录流程。 | 我们打算利用 Storage Access API（带有用户提示）来支持经过身份验证的嵌入用例，并且最近发送了一项 intent-to-prototype。 |
| 终身包退政策 | 可能的生命周期政策是否适用于第一方 Cookie？ | 目前，我们不打算对第一方 Cookie 施加生命周期限制。 |
FedCM
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| OAuth 授权支持 | 在授权非配置文件 OAuth 范围方面达成一致 | 我们正在积极通过 W3C FedID CG 向 Web Identity 社区寻求建议，了解在弃用第三方 Cookie 后，如何以最佳方式支持基本身份验证以外的授权。 |
| 对 SAML 的支持 | 在 SAML 支持要求方面达成一致 | 在弃用第三方 Cookie 后，该团队正积极向研究和教育社区寻求关于 SAML 支持需求（除了 OpenID-connect 支持）的意见。 |
打击垃圾内容和欺诈行为
Private State Token API（及其他 API）
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 探索新信号 | 一些合作伙伴对探索浏览器协助的设备完整性或用户信任信号表达了积极的态度。一般来说，他们对于新的专用信号是否足以维持当前的欺诈检测水平也持谨慎态度。 | 我们很高兴能与反欺诈和网络安全社区一起探索新提案，同时确认并分享他们的顾虑 - 这正是“打击垃圾内容和欺诈”的原因一直是 Privacy Sandbox 的核心工作流程，也是我们在加强用户隐私保护的同时，继续优先投资于保护网络安全的原因。 |
| 有关 PST 的正面反馈 | 一些合作伙伴已表示有兴趣针对各种防欺诈或网络安全用例测试或使用 PST。 | 我们很高兴得知您对进一步探索利用 PST 的新解决方案的支持和兴趣。Chrome 开发者网站上提供了相关资源和示例代码，欢迎您进一步提供反馈。 |
| 欺诈和滥用行为 | 有关在标识符不再可用的情况下，在弃用第三方 Cookie 后，如何进行广告欺诈防范 / 检测衡量指南。 | 我们推出了私密状态令牌等工具，这类工具有助于恢复第三方 Cookie 丢失的部分信号，以便防范欺诈行为，同时引入了新的隐私控制机制。我们正在积极投资开发新的反欺诈和反滥用提案，以便在 Privacy Sandbox 的其他变更中保留功能。 |
| 发卡机构到源站信息比率 | 从颁发者到来源的信息率足够高，可以识别唯一身份用户。 | 我们更新了规范，以更清楚地说明可以使用私密状态令牌传输哪些用户数据。根据设计，一次最多可以使用六个公钥，这些公钥可能代表一种“状态”，特定用户操作这些密钥集只能每 60 天更新一次（除非在极少数情况下需要进行紧急密钥轮替），这会降低联接其他用户数据的可能性。任何新的 Web API 都会在提供的效用和净新用户信息之间取得平衡。据我们估计，PST 能够在保护用户隐私方面取得适当的平衡，同时支持受第三方 Cookie 弃用影响的关键防欺诈应用场景。 |
| 提取集成 | fetch 集成既复杂又没有必要。 |
使用 fetch 有利有弊，我们希望在 Web 生态系统内实现进一步的标准化，但我们认为，在我们更清楚地了解该标准之前，现在还为时过早。当某个标准出现时，我们也致力于以负责任的方式帮助 Web 开发者改用该标准。 |
| 存储位置 | 私密状态令牌的密钥配置应与 PrivacyPass 协议存储在同一位置。 | 在源试用期间进行测试时，开发者表示，他们更愿意灵活地将密钥存储在常规网址（而不是 .well-known 目录中）中。PrivacyPass 中的密钥承诺格式并不适用于密钥集旨在允许隐式“公共元数据”的版本值。如果 PrivacyPass 的某个变体最终通过公开元数据实现标准化（作为 POPRF、部分 RSA 盲加密或密钥集），我们可能会改用未来版本的 PST 来支持此功能。 |
| API 的标头实现 | 关于 API 标头实现的问题 | 随着该 API 的标准化和生态系统使用日趋成熟，我们有望同时支持此 API 的标准非标头版本，如果使用率足够低，或者有足够多的开发者工具/支持，可支持将签发/兑换请求与其他数据相关联的标准方法，最终弃用标头版本。我们正在在此处讨论该问题。 |
| 注册 | 通过浏览器供应商注册 Issuer 是否可行？ | 我们更新了相关规范，以说明私密状态令牌的颁发者注册流程。虽然该流程采用自己的流程，但与 Privacy Sandbox 其余工作的注册计划类似，我们会要求发卡机构公开声明他们打算如何使用 PST，并承认用于保护用户隐私的技术限制。 |