2024 年第 2 季度和第 3 季度的季度报告，总结了收到的有关 Privacy Sandbox 提案和 Chrome 回应的生态系统反馈。
根据 Google 对英国竞争和市场管理局 (CMA) 的承诺，Google 同意每季度公开发布有关其 Privacy Sandbox 提案的利益相关方互动流程报告（请参阅承诺的第 12 段和第 17(c)(ii) 段）。2024 年 7 月 22 日，Google 宣布不会在 Chrome 上弃用第三方 Cookie (3PC)，而是提议采用经过更新的方法，提升用户在选择方面的体验。因此，在 CMA 同意的情况下，Google 并未向 CMA 提交 2024 年第 2 季度公开报告，以便 Google 和 CMA 有足够的时间考虑 Google 宣布弃用第三方 Cookie 的影响。
这些 Privacy Sandbox 反馈摘要报告是通过汇总 Chrome 从反馈概览中列出的各种来源收到的反馈生成的，这些来源包括但不限于：GitHub 问题、privacysandbox.com 上提供的反馈表单、与行业利益相关方的会议，以及网络标准论坛。Chrome 欢迎从生态系统中获得反馈，并正在积极探索将所学知识纳入设计决策的方法。
反馈主题的排名依据是每个 API 的流行程度。具体方法是汇总 Chrome 团队针对给定主题收到的反馈量，并按数量从高到低排序。我们通过查看公开会议（W3C、PatCG、IETF）、直接反馈、GitHub 以及 Google 内部团队和公开表单中出现的常见问题，确定了常见的反馈主题。
具体而言，我们查看了 Web 标准机构会议的会议记录，并考虑了 Google 的 1 对 1 利益相关方会议记录、各个工程师收到的电子邮件、API 邮寄名单和公开反馈表单，以获取直接反馈。然后，Google 协调了参与这些各种宣传活动的团队，以确定与每个 API 相关的主题的相对普遍性。
Chrome 对反馈的回应说明是基于发布的常见问题解答、对利益相关方提出的问题的实际回复，以及专门出于这项公开报告练习的目的而确定的。反映了当前开发和测试的重点，收到了特别有关 Topics API、Protected Audience API 和 Attribution Reporting API 的问题和反馈。
在当前报告期结束后收到的反馈可能尚未获得 Chrome 团队的回复。
首字母缩写词词汇表
- ARA
- Attribution Reporting API
- CHIPS
- 具有独立分区状态的 Cookie
- DSP
- 需求方平台
- FedCM
- Federated Credential Management
- FPS
- First Party Set
- IAB
- 美国互动广告局 (IAB)
- IDP
- 身份提供商
- IETF
- 互联网工程任务组
- IP
- 互联网协议地址
- openRTB
- 实时出价
- 加时赛
- Origin 试用版
- PAT API
- Protected Audience API（以前称为 FLEDGE）
- PatCG
- 私下竞价技术社区群组
- RP
- 依赖方
- RWS
- 相关网站集（以前称为第一方集）
- SSP
- 供应方平台
- TEE
- 可信执行环境
- UA
- 用户代理字符串
- UA-CH
- 用户代理客户端提示
- W3C
- 万维网联盟
- WIPB
- 故意 IP 盲化
一般反馈，无特定 API/技术
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 弃用第三方 Cookie (3PCD) | Google 对 3PCD 有何计划？是否已评估其对数字广告行业的长期影响？ | 我们提出了一种更新的方法，让用户能够更加明智、灵活地做出选择。正如此处所述，我们不会弃用 3PC，而是会在 Chrome 中引入一种新体验，让用户能够做出明智的选择，并将其应用于所有网络浏览活动，并且他们可以随时调整此选择。我们正在与监管机构讨论这一新途径，并在推出之前与业界合作。 |
| 用户选择 | 用户选择声明影响了生态系统对采用 Privacy Sandbox 解决方案的兴趣。关于用户选择公告，我们收到了各种反馈，包括要求提供监控功能等功能。 | 随着更新后的方法增加了用户的选择余地，开发者仍然需要用能够增强隐私保护的替代方案来替代跨网站标识符。虽然我们尚无法分享有关新版体验的详细信息，但我们预计 Chrome 中的无 Cookie 流量将会显著增加。这意味着，Privacy Sandbox API 对企业而言仍然至关重要。我们将继续在 Privacy Sandbox 技术方面保持投入，进一步增强其隐私保护和实用性。 |
| 用户选择界面 | 有关停用/意见征求功能时间表、考虑的用户选项类型以及界面将如何影响自动化测试环境的问题。 | 我们目前没有时间表更新可以分享。在决定不再采用 3PCD 后，我们希望尽快向整个生态系统提供最新动态。一旦有用户选择时间表，我们会立即分享。 |
| Chrome 测试 | 请求继续提供由 Chrome 提供的测试标签，以便在 2024 年下半年之后衡量 3PCD 的市场采用率和经济影响。 | 我们知道，即使 2024 年 Chrome 协助型测试已结束，测试人员仍希望继续使用带有标签的浏览器群组进行测试和协调。我们正在根据用户选择公告评估标签的后续步骤。与此同时，Chrome 团队发布了意向延长对已标记浏览器群组的支持，将持续到 Chrome 里程碑 132（持续到 2025 年 1 月）。 |
| Privacy Sandbox on Android | Privacy Sandbox on Android 和 Privacy Sandbox on Chrome 密不可分，我们无法在不使用 Android 的情况下妥善评估 Privacy Sandbox。典型的客户历程涉及跨设备和多点触控方面，对 Privacy Sandbox on Chrome 和 Privacy Sandbox on Android 至关重要。 | 请注意，Privacy Sandbox on Android 不在 Google 向 CMA 做出的承诺的范围内。 如果反馈仅针对 Android 时间表和发布，我们目前没有任何新进展可以分享，但我们会继续推进 Android 计划，我们将其视为一个独立的工作流，旨在改善隐私保护。 如我们之前所述，Android 设备上 Privacy Sandbox API 的可用性还将取决于用户更新设备的速度，而这不在 Google 的控制范围内。 |
| 模式 B 流量受限 | 模式 B 的广告竞价流量低于预期。 | Protected Audience API (PA API) 竞价量可能低于预期的原因有很多，例如： - 我们知道集成了 PA API 的公司仅包含横幅广告格式。 - 卖方平台可能并不总是启动竞价。 - 浏览器可能不支持兴趣群组 (IG)。 - 可能没有出价。 不过，我们没有发现任何尝试测试 PA API 但未收到任何流量的用户。 |
| 停电可见性 | 了解影响 Privacy Sandbox API 的中断和问题。 | 有 Privacy Sandbox API 的公共状态页面，其中列出了在浏览器之外提供服务的 API。 Chrome 团队将平台的可靠性以及网络上各大网站和服务使用的所有关键 API（包括 Privacy Sandbox 技术）的安全性视为头等要务。到目前为止，只发生了一次服务中断。它与用于 1% 测试的临时配置有关。此次服务中断所涉及的实验性配置很快将不再需要，因此我们确信，在 Chrome 中以常规方式启用 API 后，就不会出现这一问题。 |
| Cookie 图表研究 | 在 Privacy Sandbox 框架中，Chrome 对 这篇论文中所述的 CookieGraph 方法有何看法？ | 对于由与用户访问的网域不同的网域设置的第一方 (1P) Cookie 的检测和普及，本文提出了一些有趣的观点。正如本文所指出的，这些 Cookie 对于收集有关用户与网站互动方式的分析数据和信息非常有用。这些数据对于开发者提供更好的浏览体验至关重要。 该论文的主要论点存在缺陷，因为它将第一方 Cookie 视为跨网站跟踪矢量。不过，这仅在论文中列出的非常激进的假设下成立：
请注意，这些是可在不使用第一方 Cookie 的情况下利用的重新识别途径（例如，通过服务器端数据共享），需要单独解决，而我们目前的工作重点是第三方 Cookie 等基于状态的跟踪机制。 最后，我们想指出，该论文将分析 Cookie 和广告 Cookie 等同于跟踪 Cookie，并将严格必要 Cookie 等同于非跟踪 Cookie，但这并不一定正确。实际上，第一方分析或分区到站点的供应商服务（如店铺定位工具微件、聊天微件或负载平衡器 Cookie）通常只能在一个网域上使用，反过来，一些绝对必要的 Cookie 可能会用于防欺诈目的的跨网站跟踪。 |
| 用户体验变化 | Chrome 112 中的用户体验变更将第一方 Cookie 控件移到了 Chrome 设置的“设备端网站数据”部分，这可能会使用户更难阻止所有 Cookie。 | 我们之所以做出这项变更，是为了将 3PC（或未分区存储空间）的控件与所有其他类型的网站数据分离开来，并对其进行提升。第三方 Cookie 控制设置位于“隐私和安全”面板下，而第一方 Cookie 和所有其他类型的网站数据（关键网站功能通常依赖于这些数据）的控制设置则位于“设备端网站数据”下。我们会继续密切关注有关这一主题的反馈，但我们认为，当前的分离能够很好地兼顾重要隐私控制的曝光度和保留实用的浏览体验。 |
| 结算和付款 | 由于测试人员更侧重于测试 Privacy Sandbox API 的其他方面，因此尚未对结算和付款功能进行全面测试。 | 开发者和公司可以自行选择何时测试以及测试什么内容。这些 API 已于 2023 年 9 月推出，现已正式推出，可供测试。 |
| 测试 | DSP 从 SSP 接收的实验性流量中，并非所有流量都带有标签。一些 DSP 提交了以下信息：实验组和对照组中未标记的实验性展示的份额可能不同。 | Chrome 无法控制公司是否会在出价请求中转发标签。我们提供了一种从浏览器获取标签的方法。如果合作伙伴无法直接读取这些标签，则由生态系统将标签传递给合作伙伴。 |
| Android WebView 上的 3PCD | 请求有关在 Android WebView 中启用“Test Third Party Cookie Phaseout”（测试第三方 Cookie 逐步淘汰）标志以测试弃用功能的指南。 | Android WebView 默认会屏蔽 3PC。 |
| 使用差分隐私来降低模型训练中的风险 | 为什么在模型训练中使用差分隐私？ | 差分隐私与可信执行环境 (TEE) 相结合，对于模型训练至关重要，可防止数据泄露，并保护敏感信息免受威胁。这种方法可确保模型权重无法泄露个人用户数据。 |
注册和证明
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 注册 | 请求澄清认证注册在已注册的来源与采用 www 子网域的广告技术平台来源之间的运作方式。 | 广告技术平台只需在 https://example.com 上完成初始配置即可。当他们将认证放在 https://example.com/.well-known/privacy-sandbox-attestations.json 中时，https://www.example.com 也会被涵盖，因为它是子网域。 |
| API 规范 | 建议向代码库添加用于认证文件的 JSON 架构。 | 我们正在评估此建议，欢迎您在此处提供更多反馈。 |
展示相关的内容和广告
主题
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 主题权重 | 在“主题”中，最重要的是要了解给定信号的稀有程度。当前设计应进行演变，以允许在每个观察到的主题旁边添加权重值。权重是指相对于使用该主题的所有浏览器而言，给定主题在某个浏览器中的相对权重。 | 我们想进一步了解为什么信号的稀有性是最重要的信号。欢迎生态系统参与者就这一应用场景的实用性提供其他反馈，请点击此处。 |
| 主题可靠性 | 随着时间的推移，Google 需要针对 Topics 的可靠性提供更强有力的保障。 | 我们将继续根据生态系统的反馈对 API 进行更改，并在更改前公开讨论。我们提出的修订版治理结构方案将进一步提供保障。 |
| 分类器 | 发布商的网站经常被错误分类，或者分配的主题过于宽泛，无法发挥任何有意义的作用。 | 如 Topics 分类说明中所述，网站会通过人工挑选的替换列表（其中包含最热门的网站）和设备端机器学习模型来分类。Chrome 会继续评估网站提供的选项，以便为 Topics 分类做出贡献。在考虑任何实用性改进时，都必须权衡隐私和滥用风险。 例如，其中一些风险包括： - 网站使用自标签作为一种方法，将不同的（可能敏感）含义编码到主题中；以及 - 网站攻击主题，以降低其对他人的实用性（例如，向用户的主题发送无意义的垃圾内容）。 公众可以通过 chrome://topics-internals 或此 Colab 中的工具检查这些组件。我们希望通过测试，分类功能会随着时间的推移而不断改进，欢迎您提供可能被错误分类的网站示例，以便我们提供反馈。 |
| API 问题 | 担心 Topics API 会持续为利用不良内容创收的 SSP 带来不利于竞争的优势。 | 与 3PC 一样，只要相应实体已注册和证明，浏览器就与谁返回 Topics 无关。 |
| （也已在上一季度报告中报告） 对不同类型的利益相关方 的用处 |
由于主题分类器目前仅使用网页主机名来定义相应主题，因此内容丰富的大型网站会贡献常规主题，而小型网站则会贡献具有更高广告价值的小众主题。 | 我们的回应与以往季度的类似： 与第三方 Cookie 一样，不同网站提供的信息价值也有所不同。小众兴趣网站的价值贡献不一致：并非所有小众兴趣网站都具有具有商业价值的情境，因此贡献的价值较低。以下网站将受益于 Topics API。我们已考虑过使用网页级而非网站级分类的可能性，但此类分类会带来许多严重的隐私和安全问题。 |
| 分类器 | 较小的网站通常会被分配不准确的分类或未分配分类，因此无法参与价值交换。 | 就涉嫌的伤害而言，可能被错误分类的特定网站不会受到与其他网站一样的伤害，因为该网站的背景信息随时可供竞价参与，即使出现分类错误的情况，也能提供与正确主题相当的信息。主题通常用于从外部网站（而非自己的网站）收集可能有用的广告信息。 |
| 分类版本 | 如何访问分类法版本以确保向后兼容性？ | 类目版本是随启用了主题的提取请求发送的请求标头的一部分。 例如，如果标头为“(1 2);v=chrome.1:2:5, ();p=P000000000”，则版本为 chrome.1:1:2。其中 chrome.1 是配置版本，2 是类目版本，5 是型号版本。 如需了解详情，请参阅规范，该说明也已添加到说明文档中。 |
| Topics 数据 | 请求说明主题数据的更新方式。 | 未指定分类更新。这让浏览器供应商在实现方面具有灵活性。 尽管如此，下面还是介绍了 Chrome 从 V1 到 V2 的术语体系更新的启发词语： - 为 V1 和 V2 中的主题维护单个分类树。 - 相同的主题 ID 表示相同的含义。 - 树状结构只会变大 - 不断增加新的主题或关联，不会变小。 - 不过，某个版本中的某些主题或链接可能会处于“非活跃”状态，这可能会给人造成已被删除或重新整理的印象。 示例： - “皮卡车”现在将“卡车、货车和 SUV”作为中间父级。 - “外语学习”现在将“教育”作为第二个父级，其原始父级“参考”变为无效。 “无效”主题的影响：这些主题将不会用于新分类。不过，在强制执行用户屏蔽操作时，系统仍会考虑这些主题：如果用户在 V1 中屏蔽了某个主题，则其子主题在 V2 中仍会被屏蔽（即使子主题在 V2 中显示在其他父主题下也是如此）。 |
| 分类器 | 希望了解分类错误的原因和任何可用的纠正选项。 | 首先，我们想指出，Chrome 确定网站主题只是为了将其作为 Topics 算法的输入，以便确定用户的兴趣，从而投放广告。并非为其他更宽泛的分类目的而开发。 我们对分类模型的整体准确率感兴趣，并尝试尽可能提高其精确率/召回率，但针对的是全局级别，而不是单个网站分类级别。这是因为，即使发生了错误分类，也不会对被错误分类的个别网站造成伤害，而是会降低在其他网站上选择广告时主题信号的质量。在错误分类的网站上选择广告时，该网站已经知道自己的真实主题，这些主题可用作广告查询的输入。 欢迎您在此处提供更多反馈。 |
| API 测试 | Topics 和 Privacy Sandbox API 能否在 Chromium 中进行测试？ | Topics API 未随 Chromium 一起提供，而是随 Chrome 一起提供。 |
| 主题调用者 | 请求利用面向广告技术平台的 TEE 服务提升 Topics 的附加价值，从而以注重隐私保护的方式支持高级分析的成本。 | 我们已在此处回复过类似反馈。我们考虑了反频率，但最终在对反频率进行建模后，发现它与买方和卖方提供的主题价值之间没有很强的相关性。 欢迎您在此处提供更多反馈。 |
| API 规范 | 浏览器兴趣同类群组设置是否会屏蔽 Topics API？ | 我们已在此处回复此反馈。 Topics API 是 FLoC 的演变，它遵循 FLoC 的权限政策。如说明文档中所述：“注意：FLOC 中的旧版 Permissions-Policy: interest-cohort=() 也会禁止计算主题。” |
| 主题排名 | 在获取“前 5 个主题”时，我们是根据每个符合条件的调用方统计网站访问频率，还是始终根据浏览器的整个访问记录统计？此外，系统是否会为每个调用方单独对主题进行进一步排名？ | 该分数基于部分浏览记录的频率计算得出。只有当浏览记录条目（网页）至少包含一个 Topics 调用方时，该条目才有资格参与。如需详细了解主题历史记录存储，请点击此处。 正如我们在 Topics API 增强功能公告中所述，排名取决于频率和二元优先级（如需了解更多详情，请参阅此处和此处）。不过，它不取决于调用者的频率。请注意，这并不意味着所有调用方都可以在下一个周期中获取前 5 个主题。如说明文中所述，“只有在过去三周内观察到用户访问了与主题相关的网站的调用方才能接收此主题”。浏览器确实需要跟踪哪些调用方观察到哪些热门前 5 个主题（对应于规范中的包含调用方网域的热门前 5 个主题）。 欢迎您点击此处，就此问题提供更多反馈。 |
Protected Audience API（以前称为 FLEDGE）
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| （也已在往季度报告） 费用 |
在公有云中运行 TEE 的费用是否高于在本地广告技术数据中心运行 TEE？ | 我们当前的 TEE 安全模型受益于公有云实现实践（如需了解详情，请参阅公有云 TEE 要求说明）。例如，当前基于硬件的 TEE 无法防范所有物理攻击。我们现有的受支持的公有云提供商 AWS 和 GCP 设计并实施了针对物理访问风险（包括来自员工的风险）的缓解措施。 虽然一些广告技术平台向我们提到，运行云服务的费用高于本地广告技术平台数据中心，但其他广告技术平台则在公有云上运行，无论是出于成本还是其他优势考虑。 我们将继续评估扩大 TEE 支持的选项，包括在公有云之外。作为其中的一部分，我们正在研究本地数据中心，并与整个生态系统积极互动，以探索提供此类支持的潜在解决方案。在当前的研究阶段，我们无法保证这一定能为生态系统带来切实可行的解决方案。 |
| PA API 和 Google Ad Manager (GAM) | GAM 无法实现公平的市场结果。GAM 无法及时投放广告，因此无法使用 PA API 报告其投放的广告数量，但也未提供用于选择投放广告的方法（例如为特定广告位停用 PA API）的可配置性。 | Google Ad Manager 回应： GAM 一直在并将继续致力于优化通过 PA API 投放广告时的延迟时间，以便发布商通过 PA API 需求获得的额外收入超过因额外的 PA API 竞价延迟时间而产生的任何费用。我们的初步测试表明，发布商在不使用第三方 Cookie 的情况下从 PA API 获得了正的净流量收入，这表明 PA API 带来的额外需求超过了因延迟而产生的所有成本。如需详细了解我们的做法，请参阅我们的常见问题解答。 此外，GAM 还会向发布商提供有关通过 PA API 投放的广告的报告。这包括 GAM 作为组成部分卖方投放的广告，以及 GAM 作为顶级卖方通过其他组成部分卖方投放的广告。如需详细了解举报功能，请访问我们的帮助中心。 最后，GAM 确实允许发布商通过界面内控件启用或停用对其流量的 PA API 使用（如需了解详情，请参阅我们的帮助中心）。我们很乐意考虑针对发布商可能希望采用的进一步控制功能的反馈，并会按照标准功能优先顺序流程优先处理所有功能请求。 |
| PA API 和 GAM/AdX | Google 似乎已决定，绝不会购买 GAM 未做出最终销售决定的任何 PA API 展示机会，这与 AdWords 仅从 Google 内部购买展示机会非常相似。这似乎纯粹是滥用市场位置，因为 GAM/AdX 可能会像任何其他广告交易平台一样，向替代的顶级卖方提交组成部分竞价配置。 | Google Ads 平台经理回复： 这不是 Google 的立场。Google 的买方平台（Google Ads 和 DV360）确实会从非 Google 广告交易平台购买展示机会。这对 PA API 展示和非 PA API 展示都适用。 |
| 市场响应 | Mozilla 的疑虑： Google 的 Protected Audience 功能更侧重于保护广告客户（和 Google）而非您。 | 我们感谢 Mozilla 的评估，并将继续在公共标准论坛中积极回应 Mozilla 的反馈。他们在评估中指出，PA API 的当前实现尚未强制执行所有计划的保护措施。我们采用 PA API 的进入市场方法，力求在鼓励采用和尽快实施隐私保护之间取得适当的平衡。为此，我们制定了一项路线图，以便逐步强制执行隐私权限制，以便更好地实现与 API 的集成，并有时间收集更多反馈，以便纳入到未来的保护措施中（例如，Fenced Frames 中的 VAST 功能）。 我们也欢迎 Mozilla 最近就其在隐私保护和数字广告方面的做法发表的声明：“自由开放的互联网不应以牺牲隐私为代价”和“通过产品和基础架构改进在线广告”。 |
| （也已在上一季度报告） 竞价结果 |
请求单次竞价以返回多个呈现网址及其对应的得分，从而更轻松地删除重复的原生广告，并避免用户体验和延迟问题。 | 我们的回复与上几个季度类似： 我们曾考虑过共享来自单次 PA API 竞价的多个 render网址 及其各自的得分，但由于隐私问题，并未实施。 我们理解，用户希望避免在一个网页上多次展示同一个广告，因此我们正在评估这项要求。欢迎生态系统中的各方通过此处提供更多反馈，说明 PA API 需要提供哪些额外支持，才能最佳地支持原生广告用例。 |
| 性能 | 担心延迟时间会影响 PA API。 | 我们了解到，有些人对延迟时间有疑虑，这也是我们在 PA API 中开发了多项功能的原因之一。这些功能可让 SSP 限制 DSP 延迟时间，并进行有助于缩短延迟时间的改进。我们最近更新了 延迟时间最佳做法指南，其中详细介绍了如何充分利用这些功能。我们还在继续开发新的延迟改进措施，您可以在 此处了解其中一些改进。 |
| 顶级卖家 | Google 应让发布商能够选择其他顶级 PA API 竞价卖方。 | 无论是单卖家还是多卖家设计，PA API 对发起竞价的正文不作区分。各个公司是否以及如何支持 PA API 竞价取决于他们自己。 |
| （也报告在上一季度） 排除性定位 |
请求解决广告客户不希望向特定受众群体展示广告的用例。 | 我们支持通过额外的（情境）出价来实现否定 Instagram 定位，从而满足广告客户不向特定受众群体展示广告的需求。 如需了解详情，请参阅此说明和此 GitHub 问题。 我们还在探索解决方案，以支持针对 PA API 出价使用 IG 否定定位条件，欢迎您点击此处提供更多反馈。 |
| （在之前的季度中也报告过） 原生广告 |
请求为原生广告提供围栏帧支持。 | 我们正在考虑支持此用例，并在 此处讨论可能的权宜解决方法和解决方案。 |
| WebView | 请说明在 Chrome 中加入的 IG 无法参与在 WebView 上执行的竞价的情况。 | 我们希望在有足够的隐私保护基础架构可用后，支持这些用例。目前，我们没有任何进一步的公告，但欢迎您 在此处提供更多反馈。 |
| 负 IG | 请求通过新兴的标头功能更新 网址 处理，以支持否定 IG。 | 我们正在评估此请求，欢迎您在此提供更多反馈。 |
| 多样性过滤 | 请求获得指导，了解在采用多卖方和多竞价的 PA API 中投放原生广告时如何实现多样性过滤。 | 我们正在 此处讨论此请求，欢迎您提供更多反馈。 |
| （也报告在上一季度） 屏蔽过滤器 |
请求有关如何在 PA API 中使用多个卖方投放原生广告时强制执行“发布商屏蔽”(过滤器) 规则的指导。 | 我们已在 此处分享了相关指南，欢迎您提供更多反馈。 |
| 限制 | 请求允许在域名级别（而非子网域级别）设置限制。 | 子网域或来源级限制遵循 Web 的基本安全模型，因此这是我们的默认设计。 如需了解详情，请参阅此处和此处。 |
| 可信出价 | 在可信出价信号请求中请求用户代理和相关客户端提示。 | 我们会跟进此功能请求， 欢迎您在此处提供更多反馈。 |
| （也已在上一季度报告） 多个 IG |
在同一出价中使用多个 IG。 | PA API 目前不支持此操作，因为这会导致底层隐私保护模型发生变化。 欢迎在 此处进行更多讨论。 |
| （也报告在上一季度） 效果 |
将更多逻辑移至客户端可能会影响网页性能和用户体验，进而影响网站 SEO 得分。 | 我们正在讨论此问题，欢迎您 在此提供更多反馈。 |
| 竞价动态因素 | PA API 会减少竞价动态信息（例如谁参与了竞价、谁赢得了竞价的每个组件等），这会降低发布商的可追溯性，并使其难以确定交易是否会保持不变。 | 我们在此处提供了交易跟踪解决方案。我们计划修改一些现有字段，并在 IG 对象中创建一些新字段来存储 DealID 和 SeatID，并允许它们通过事件级报告从 generateBid 传播到 scoreAd 或出站。这应能为交易的用例提供充分的支持。 我们欢迎就其他元数据提供反馈，这些元数据被广告技术平台视为对竞价动态至关重要，可帮助发布商保持这种可追溯性。我们鼓励广告技术平台提供所提及元数据的具体示例，以及元数据需要从哪一方流向哪一方。 |
| GAM | 对必须使用 GAM 作为发布商广告服务器才能访问 AdX 需求的要求存有疑虑。 | Google Ad Manager 提供的回复： GAM 不要求发布商使用其广告服务器功能才能使用其广告交易平台功能。 |
| （也已在上一季度报告） 组件竞价 |
PA API 组件竞价胜出者将对 GAM 可见，这引发了人们对信息获取不平等的担忧。 | 我们的回复与上个季度保持不变： Google Ad Manager 提供的回复： “我们多年来一直非常重视竞价公平性，包括承诺在其他买方在竞价中出价之前，不会与其分享发布商的任何无保证广告来源（包括无保证订单项价格）的价格。我们后来在向法国竞争管理局做出的承诺中重申了这一点。 对于 PA API 竞价，我们打算兑现我们的承诺，在多卖方竞价中的竞价完成之前，不会与任何其他竞价参与者分享任何竞价参与者的出价。需要说明的是，我们不会与任何组件竞价（包括我们自己的竞价）共享内容相关竞价的价格，如此更新中所述。 此外，我们不会在自己的竞价中使用组件竞价配置（包括买方向 SSP 提供的信号）相关信息。事实上，我们非常欢迎 PA API 的更改，允许组件卖方以与顶级卖方混淆的方式指定组件竞价配置。” |
| GAM | 如果 GAM 未参与 IG 或 PA API 组件竞价的创建，那么在运行/报告顶级竞价时，GAM 是否会请求收益分成？ | Google Ad Manager 提供的回复： 当发布商选择将 GAM 用作其广告服务器时，GAM 将运行顶级竞价，并针对其广告服务器功能收取广告投放费用（与 PA API 竞价之外适用的广告投放费用相同）。 不过，如果胜出的广告来自非 GAM 组件卖方（即 GAM 未参与 IG 或 PA API 组件竞价的创建），则 GAM 不会处理结算，也不会收取一定比例的媒体费用。 |
| 点击性 | 点击事件的注册是否也遵循相同的差分隐私保护机制？ | 目前，我们不打算对此功能施加“k-anon”限制，因为“点击次数”将仅作为 generateBid() 函数内的 browserSignal 提供；它不会作为事件级报告中的新属性提供。 |
| 性能 | 由于对内容相关出价请求做出无条件响应，导致出站流量费用较高。 | 出于隐私保护考虑，我们无法直接提供哪些 DSP 具有 IG 的信息。不过，我们正在探索可在保护隐私的同时提供数据洞见的替代解决方案。 |
| 原生广告和外播广告 | 请求了解 Chrome 对原生广告和插播广告的最新看法。 | Chrome 的位置取决于相关用例。 对于视频，Chrome 的立场是，我们的工作是鼓励整个生态系统使用我们的 API 达成可行的插播视频解决方案共识。到目前为止，我们所知道的唯一具体提案是 GAM 的提案。 对于原生广告，我们正在此处积极收集反馈，并计划尽快让广告技术平台参与更多发现步骤。 |
| 实时监控 (RTM) | 已加标签的流量不会发送 RTM 报告。 | 我们已意识到这一差距，并正在努力提供解决方案。 如有最新消息，我们会在此处分享。 |
| 受众群体扩展支持 | 请求更新 PA API 中对受众群体扩展/卖方管理的受众群体的支持。 | 我们正在努力为此用例提供解决方案。我们正在收集生态系统中关于我们应构建和支持哪些内容的反馈。 我们会在有新进展时分享最新动态，欢迎您在此处提供更多反馈。 |
| 调试 | Chrome 的开发者工具中不提供用于监控 PA API 详细性能的面板。例如，总体效果可能会受到 IG 数量或买方数量的影响。 | 虽然这条具体反馈与 Chrome 开发者工具界面用于协助监控的功能有关，但我们于 10 月 7 日推出了广告技术平台配置可用作监控和提醒依据的自定义事件的功能。如需更多详细信息，请点击此处，我们希望此次更新能够解决此反馈的重要问题。 欢迎您在相应的 GitHub 讨论中点此提供有关此功能的任何其他反馈，无论是与支持的数据点还是开发者体验相关。 |
| 信号 | 关于 DSP 能否确保 perBuyerSignals 会独立于内容相关竞价结果而发送到 SSP 的疑虑。 | 假设内容相关竞价只有一个 DSP 的胜出出价，或者更确切地说，只有一个出价会在随后的 PA API 竞价中尝试超越。对于 PA API 流程，SSP 决定邀请他们希望了解是否有需求（以设备端 IG 的形式）提交的所有 DSP。输掉内容相关竞价的 DSP 完全有可能（实际上也非常有可能）被“重新邀请”参与 PA API 竞价。在这种“重新邀请”中，如果 DSP 决定接受，则会将广告验证工具希望确保 DSP 考虑的任何信号（如果该广告系列存在）转发给 SSP。 换句话说，在 PA API 竞价中，无论内容相关竞价中发生了什么，DSP 都始终有办法向 SSP 提交 perBuyerSignals。 |
| 信号 | 请求将 prevClicks 添加到传递给 generatedBid() 的 browserSignals 对象中。 |
我们的提案可以解决此请求，以支持点击性信号。我们已在近期的博文和相应的说明文档中宣布推出此功能。 欢迎就此提案提供更多反馈，请点击此处。 |
| （已在往季度报告） 根据模型估算信号 |
请求将建模信号的位数从 12 位增加到 30 位。 | 我们已回复此反馈，并在此处提供了抗辩通知。我们正在积极与业界人士互动，了解他们对我们提案的看法，并目前正在权衡对业界的益处与对 Chrome 用户和其他利益相关方的潜在影响。 |
| 文档 | 请求有关如何使用键值 (K/V) 服务器和 TEE 的指南。 | 如需有关在 K/V 上下文中使用 TEE 的指南，请参阅此处的 K/V 服务信任模型设计详细信息。 |
| 负面 IG 的生命周期 | 请求将排除性 IG 的生命周期延长至 365 天。 | 负面 IG 用于阻止展示广告，但作恶方仍能利用此类信息泄露用户信息，从而导致重新识别风险（例如，作恶方的攻击方式之一是重复针对包含负面 IG 的高出价，了解用户是否访问过或没有访问过某些网站）。 如果我们将 TTL 保持为 365 天，那么作恶方将拥有更多关于负面 IG 的数据，这将带来明显更大的隐私风险。 因此，为保护用户隐私，我们无法支持此请求。 |
| API 规范 | 可以插入什么值作为要作为 perBuyerSignals 的一部分传递的值？卖方可以任意定义此要求吗？ | 卖方可以通过 perBuyerSignals 向买方提供他们希望在竞价中提供的任何信息。 生态系统可以决定要在该位置插入什么内容，但我们欢迎您在此处进行进一步讨论。 |
| 广告尺寸宏替换项 | 希望获得有关广告尺寸宏替换不起作用的指导。 | 我们很快就会公开分享更多详细信息。 |
| 出价后 SSP 宏替换：欺骗顶级网址 | 为了让验证供应商能够验证 Privacy Sandbox 框架中的顶级网址，Chrome 可以引入什么机制？ 是否有替代数据点或信号可在围栏框架内使用，以确保 SSP 提供的顶级网址的准确性？ |
我们目前正在此处讨论这些受欢迎的其他反馈。 |
| 功能请求 | 请求在提取 update网址 和在实时报告回传时提供低熵 UACH。 | 我们正在此处讨论这些要求，也欢迎在此处和此处提供其他反馈。 |
| 功能请求 | 请求在给定客户端触发通过 forDebuggingOnly.reportAdAuctionWin() 和 forDebuggingOnly.reportAdAuctionLoss() 发送经过下采样的 forDebuggingOnly 事件级报告时，启用经过可信服务器同意的调试设计。 |
这是我们目前正在跟踪的有效要求，并将在适用时向生态系统通报最新动态。欢迎您在此处提供更多反馈。 |
| API 应用 | 请求有关如何统计覆盖的唯一身份用户数和覆盖的展示次数的指南。 | 我们正在讨论一项提案，旨在解决如何从共享存储工作流中读取 IG 的问题，以便您发送私密汇总报告。 如需了解更多详情，请点击此处，我们欢迎您就此提案及其对生态系统的实用性提供反馈。 |
| API 应用 | 不清楚发布商应测试哪些 API、哪些 API 很重要、哪些 API 应启用以及未来会发生什么。 | 我们正在努力更好地支持发布商及其在生态系统中的作用。 |
| API 应用 | 能否向广告竞价 Worklet 事件添加事件监听器？ | 无法通过常规事件实现此目的，但 Chrome 开发者工具协议事件可以部分解决此用例。 请注意，常规事件可能会影响隔离/隐私属性，但详情请参阅此处。 |
| k-匿名性 | 明确了解广告呈现要求（例如，如果广告获准展示，至少应有 50 人看到）。 | 开发者文档概要介绍了我们对未来开发工作的期望。特别指出，初始 k-匿名性阈值为 k=10 人。 blink-dev 邮寄名单会提供有关 Chrome 中实时动态的最新动态。 如有关 k-匿名性邮寄名单会话中所述，我们目前正以实验性方式对大约 1% 的 Chrome 稳定流量强制执行 k-匿名性要求，但从未对明确标记（“模式 A”和“模式 B”）切片强制执行此要求。 |
| 磨损 | 是否可以暂时移除或减少必须调用所有 N 个分片的 TEE K/V 代码转换，使其达到一定程度的隐私保护与效用之间的平衡（即K/V 性能/费用）？ | 只有可控制虚假流量的非正式版实例才能处理此类请求。对于生产实例，仍需要使用虚假标识。收到非生产环境使用反馈后，我们才能评估情况。 |
| 磨损 | 请求添加标记，以停用调试/非生产 K/V 二进制文件中的问题。 | 此标志随 1.0.0 版本提供。 |
| API bug | 升级到 Chrome 126 后，API 停止工作，即使在设置中启用了该 API 也是如此。 | 我们发现此问题与“enable-fenced-frames”Chrome 标志有关，该标志由用户出于开发目的启用。将此标志重置为默认值即可解决此问题。 |
| 报告 | 请求为买方将实时报告 API 设为可选启用，而不是依赖于卖方。 | 我们正在此处审核此请求。 RTM 解决方案最近刚刚发布，我们非常欢迎已经开始使用该功能的广告技术平台提供反馈。 |
| 报告 | 请求第三方报告；虽然 DSP 和 SSP 会收到 Chrome 发送的展示通知，但中间层技术提供商默认不会收到。 | 我们正在讨论此请求，欢迎您在此提供更多反馈。 |
受保护的竞价服务
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| TEEs | 根据技术标准，Google 需要手动完成初始配置，这非常限制了对云供应商的选择。Google 认为，无需前往云提供商局就能遵循所遵循的技术标准。我们无法接受将备选提供商的加入时间推迟到 2025 年（最早），因为这会引入网络效应，鼓励用户向 Google 的解决方案支付小费。 | 汇总服务是唯一需要在 TEE 服务中运行的服务，用于处理某些广告技术用例。汇总服务同时支持 Amazon Web Services (AWS) 和 Google Cloud Platform (GCP)。根据广告技术平台的反馈，我们认为目前提供的支持足以满足需求。 其他云提供商 - Google 发布了适用于公有云提供商的 TEE 标准。这些旨在确保 TEE 解决方案满足 Privacy Sandbox 的隐私和安全目标。 具体而言，Privacy Sandbox TEE 服务器会处理未加密的跨网站用户数据（例如，来自发布商和广告客户网站的数据，用于汇总服务）。这些 API 必须是安全的，以实现 API 的用户隐私目标。同样，要确保 API 继续保护公司的机密商业信息（例如，防止其他 PA API 竞价参与者访问买方的专有业务数据），安全的环境也必不可少。 据我们所知，目前还没有任何 TEE 技术能够完全保护用户数据免受潜在的恶意操作者的侵害。因此，我们列出了多项要求来验证云服务提供商的可信性。 我们不确定“云服务商局”是什么意思，而且它也不在要求范围内。我们欢迎您就这些要求提供反馈。我们还会继续评估是否支持新提供商，包括根据说明文档中定义的流程提交的请求。到目前为止，我们只收到了支持 Azure 的请求，目前正在对其进行评估。 |
| 床加早 | 随着设计的不断发展，B&A 服务的技术复杂性和可行性很难进行评估。 | 为了消除这些顾虑，我们在 GitHub 上提供了详细的解说来解释 B&A 的设计，发布了可用情况时间表，以及支持 PA API 的功能路线图。我们正在通过 GitHub 为希望部署 B&A 并从生态系统收集反馈的广告技术平台提供支持。 |
| B&A | 希望获得有关如何计算使用 TEE 进行 B&A 的费用的指导和更好的方法，以便开始使用 TEE 或从设备端迁移到使用 TEE。 | 我们最近发布了 K/V 服务器实例大小调整指南，其中包含用于更准确地衡量费用的工具。 |
| K/V 服务器 | 广告验证程序请求能够使用完整网页网址向 K/V 服务器执行广告验证。 | 我们目前正在评估向在 TEE 中运行的 K/V 服务器提供完整网页网址进行广告验证的可能性。完整网页网址将不适用于 K/V BYOS。 |
| 竞价安全性 | 寻求竞价安全功能来确保作恶方无法访问敏感数据或冒充他人 - 哪些功能可以保护竞价免受重放攻击？如何实施安全措施？ | B&A 的当前安全模型可以保护竞价完整性。B&A 在 TEE 中运行，可保护广告技术平台的信号和代码的机密性，免受恶意行为者的侵害。 在 B&A 架构中，加密的 B&A 请求载荷（请求密文）会从客户端通过不可信的广告服务器流向 SellerFrontEnd 服务（SFE，由 SSP 在 TEE 中运行）。请求密文包含基于时间戳的生成 ID。SFE 将检查请求的时间戳，并拒绝不在服务器时间 +/- n 秒内的任何重放请求。此外，B&A 还可以针对服务器到服务器通信返回填充的固定大小响应载荷。当恶意攻击者尝试重放相同的请求载荷以详细了解其内容时，这些解决方案有助于减少通过系统进行的重放攻击。 B&A 正在进行安全模型记录及更新。 |
| 通过 键值对服务器发送信号 |
请求将通过 K/V 服务发送的 perBuyerSignals 添加到 Chrome 发送的可信出价信号请求中。 | 我们正在评估包含来自 perBuyerSignals 的信息（已传输到在 TEE 中运行的 K/V 服务器中的信息（包括完整页面网址）是否可行。 |
| K/V 服务器 | 请求为 K/V 和 B&A 中的隐私权约束条件采用更分阶段的时间表。 | 我们理解您希望采用分阶段方法来采用 TKV，并感谢您就键值对和问题解答提出的具体要求。 不过，经过仔细评估，我们决定目前不放宽这些 API 中的隐私保护措施。我们认为，这些措施（例如虚假标记）对于保护用户隐私和维护对 Privacy Sandbox 的信任至关重要。 |
| K/V 服务器 | 需要有关如何通过兼容的配置扩缩键值对存储的指导。 | 您可以参阅最近发布的键值对服务器实例大小调整指南。该工具将针对每种参数组合提供 QPS（在说明中称为“RPS”）。 |
| K/V 服务器 | 在 K/V 服务器请求中添加卖方信息。 | 我们正在讨论此问题，欢迎您在此处提供更多反馈。 |
| K/V 服务 + B&A 服务 | 请求澄清键值对和问答功能的发布时间表或路线图。 | 对于 K/V 和 B&A，我们都有阶段和时间表： 对于 K/V 服务器以及设备端 PA API 竞价（相对于 B&A），您可以在此处查看公开时间表。如需了解如何为键值对定义“正式版”，请参阅“路线图”部分，其中定义了 Beta 版和正式版的功能集。 如需了解 B&A，请参阅此处的公开时间表和此处的路线图。我们将规模测试定义为“完全稳定的生产规模测试”- 如需了解此阶段的具体功能集，请点击此处。 B&A 还有 Alpha 和 Beta 阶段，因此规模测试将包含之前阶段的所有功能。 对于键值对和问答功能，请告诉我们这些阶段定义是否有助于明确何时提供哪些功能。如果仍有信息不足，请告知我们。我们非常乐意提供更具体的信息，以便您据此制定规划。 |
衡量数字广告
Attribution Reporting（和其他 API）
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 市场响应 | 要求竞争归因系统仅在严格限定的范围内使用事件级报告和摘要/汇总报告，是对竞争的任意限制。它会阻止在事件一级进行实时设备专用再定位和归因，即使已采取保护措施来确保数据保护合规性（例如去标识化）也是如此。 | 上述设计基于 API 的隐私保护目标（例如保护从一个网站传递到另一个网站的跨网站信息）。例如，ARA 支持通过事件报告进行事件级归因。事件报告至少会延迟一小时，这是必要的，因为这样可以防止使用时间攻击攻击广告客户网站，将事件级报告与用户的身份相关联，如此处所述。 此外，除了 ARA 之外，还有其他归因方式，例如直接从明知提供身份识别数据的用户那里收集信息。 我们欢迎就 Privacy Sandbox API 当前隐私保护边界无法实现的用例提供反馈。 |
| 多面 | 请求确认 ARA 和 Shared Storage API 是否支持多 Surface 用例，以及相关证据。 | 目前，ARA 和共享存储空间不支持多平台（跨设备）归因。支持在同一设备上进行跨应用和跨网站归因（通过 ARA）。 |
| （在之前的季度中也报告过） 跨设备 |
ARA 是否支持跨设备转化？ | 我们的回复与上几个季度类似： 跨设备在 3PC 的基础上带来了新的隐私保护挑战，并且鉴于用户可能会使用各种设备和平台，还带来了技术分发方面的挑战。我们正在探索可能的解决方案，但重点关注 ARA 目前支持的关键用例，目前没有提供跨设备支持的时间表。 |
| 扩缩 | 担心 Attribution Report API (ARA) 当前是否已配置，能否可靠地部署和扩容以服务所有 Chrome 用户。 | ARA 目前可供所有 Chrome 用户使用，并会按预期运行。此外，随着测试 ARA 的广告技术公司数量不断增加，我们会继续测试和监控其可靠性和可伸缩性。 欢迎您点击此处，就此提供更多生态系统反馈。 |
| （也报告在前几个季度） 删除重复数据 |
担心 ARA 提议限制设备上的归因机制，使发布商无法针对摘要报告有效执行归因后逻辑，包括对同一广告点击重复统计多次转化。 | 我们的应对措施与以往季度相比没有任何变化： 跨设备和衡量流水线的重复数据是广告技术平台目前在使用第三方 Cookie 时同样面临的一项已知和当前挑战。借助 ARA，广告技术平台可以决定何时注册特定转化，并添加特定元数据来指明其曾使用哪些衡量流水线（即汇总键的一部分），以与其他衡量流水线进行比较。 欢迎您点击此处，就此提供更多生态系统反馈。 |
| 转化跟踪 | 请求能够处理来自多个网域的转化。 | 我们正在 此处讨论此请求，欢迎提供更多生态系统反馈。 |
| 报告 | 浏览器会等待至少 2 天，但最长可达 30 天才能发送转化数据，考虑到大多数利益相关方广告客户都是近乎实时地工作的效果导向型广告客户，这可能会引起担忧。 | 事件级报告的默认设置如下：2 天、7 天和 30 天。 借助灵活的事件级报告，广告技术平台可以更改报告期的默认值和长度。报告期可更改为至少 1 小时，这可能有助于效果导向型广告客户的使用情形。 欢迎您点击此处，就此提供更多生态系统反馈。 |
| 线上促线下归因 | ARA 中是否提供任何适用于线上促线下广告的实现方案，或者在衡量线下到线上归因方面是否有任何其他建议？ | 目前，我们没有计划在 ARA 中支持线上促线下衡量用例。提供此类支持服务需要考虑重大的隐私和安全问题。 欢迎您点击此处，针对此支持功能的用例提供更多生态系统反馈。 |
| 调试报告 | 如何以便于 Chrome（来源/触发器）注册应用到网站归因的方式存储和/或检索广告 ID？ | 若要启用调试报告，广告技术平台必须向我们证明，他们已经可以在应用和网站中将用户加入数据行列，这是为了确保调试报告不会显示任何新信息。广告技术平台可以通过提供每个用户专属的联接键来证明联接。此联接键可以是 AdID，也可以是第一方联接键。如果广告技术平台使用广告 ID，Chrome 不支持从浏览器访问广告 ID，并且 API 希望每个广告技术平台在网站注册期间都有自己的广告 ID 传递方法。 |
| 存储分区粒度 | 可以对每个广告客户使用不同的存储分区策略吗？ | 我们建议您尝试不同的捐赠预算扩展方法，以找出最适合您的使用情形的方法。ARA 旨在实现灵活性和可定制性，以满足各种广告技术用例的需求。因此，我们建议针对每个广告客户或每个行业尝试不同的分桶策略。当广告客户想要跟踪的衡量值和衡量值的数量存在差异时，使用不同的分桶策略会非常有用。 |
| 文档 | 请求提供有关为 ARA 实现 app<>web 的其他文档。 | 我们已在 此处发布了有关 ARA 的“应用<> 网站”文档。 |
| 性能 | 与维护该网站所需的 keepalive 请求数量相比，与 ARA 相关的请求数量可能会给发布商的服务器带来较大的负载。在单个请求中批量处理来源事件有助于减少服务器的负载。一个可能的想法是允许使用 JSON 编码对象的数组 | 将 JavaScript 逻辑与 API 结合使用，在一定程度上可以根据特定逻辑批量处理来源事件。我们目前正在评估此请求，欢迎生态系统中的其他用户通过此处提供更多反馈。 |
| 功能请求 | 由于不支持服务器到服务器集成，因此建议采用权宜解决方案。 | 目前，我们不打算在 ARA 中实现对服务器到服务器集成的支持。为了支持服务器到服务器集成，还需要进一步考虑许多隐私保护方面的挑战。 欢迎生态系统就服务器到服务器支持的其他用例在此处提供反馈。 |
| 文档 | 请求提供“快速入门”指南，其中介绍了 ARA 的关键部分/如何通过几个简单的用例快速上手。 | 如需查看 ARA 快速入门指南，请点击此处。 我们今年将进一步改进此文档，欢迎您就需要更多文档来介绍的特定用例或场景，在此处提供更多反馈。 |
| API 应用 | 请求有关如何对许多小值进行贡献扩缩的建议。 | 我们建议您尝试不同的捐赠预算扩展方法，以找出最适合您的使用情形的方法。对于许多小值的情况，我们建议尝试不同的 epsilon 值，以确定拐点，在这些拐点处，您的用例可能可以接受来自 epsilon 的噪声。 如需了解详情，请参阅我们关于ARA 中的摘要报告优化 的研究论文。 |
| 灵活事件级 | 灵活事件级（多个触发器规范）何时会实施？ | 目前，“灵活事件级”支持自定义以下注册配置方面：每个来源可生成的报告数量、报告期数量和时长，以及触发器数据的基数。 目前，我们正在收集关于更多灵活事件级增强功能的生态系统反馈，但目前不打算实施任何反馈。 欢迎您就可能受益于此处列出的某些灵活事件级增强功能的用例提供更多反馈。 |
| 存储分区处理 | 请求考虑对存储分区的汇总贡献进行上限设置，以及考虑未来的可扩展性和向后兼容性。 | 我们正在讨论此请求，欢迎您在此提供更多反馈。 |
| Epsilon | 一旦 ARA 更改为正式版， Epsilon 范围会发生什么变化？ | ARA 于 2023 年第 3 季度在 Chrome 上正式发布。目前，我们没有计划修改 epsilon 值窗口。我们提出的修订版治理结构方案将在预计进行任何修改时提供额外的保障。 |
| 报告 | 触发器未知错误报告的报告正文中不包含来源属性。 | 如规范中所述，对于 trigger-unknown-error，报告正文中无需包含其他字段。我们知道，报告正文中描述字段的表格可能具有误导性，因为与来源相关的字段可能存在也可能不存在，具体取决于错误的根本原因。 例如，在来源匹配逻辑发生之前可能会出现内部错误，这意味着没有来源数据可用于填充调试报告。 我们现已更新文档，对此进行了说明。 |
| API 应用 | 使用两个衡量目标（计数和价值）时，是否表示要将贡献预算和 epsilon 分开？ | 在处理两个衡量目标时，我们建议在这两个目标之间分配贡献预算。 |
| 报告 | ARA 是否支持多接触点归因或辅助报告（也称为贡献报告）？ | ARA 目前不支持多点触控归因或辅助报告。目前我们还没有实现此功能的计划。 欢迎就各个用例及其优先级提供更多反馈，请点击此处。 |
| API 错误 | 对于 ARA，文档中指出，XOR 用于组合来源和触发器汇总键部分，但在实践中，使用的是 OR。这种差异会导致实现过程中出现混淆和潜在错误。 | 相关文档已更新，以反映此错误。 |
汇总服务
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 汇总作业 | 请求允许在汇总作业中使用多个前缀。 | 我们正在调查此反馈，并已在此处发布提案。欢迎您点击此处就此方案提供反馈。 |
| 功能请求 | 请求更改 Terraform 脚本，以便在未设置 service_account_token_creator_list（或为空）时，跳过修改账号 IAM 政策。 | 我们正在此处调查此问题，欢迎您提供更多生态系统反馈。 |
| API 应用 | 需要澄清 Terraform 计划始终显示更改的问题。 | 此问题已在 AgS 2.8 版中得到修复。 |
| API 应用 | 希望获得有关如何设置每位广告客户的汇总频率设置以及灵活贡献过滤条件的建议。 | 目前可使用 ARA 按广告客户进行批量处理。在广告技术平台希望按不同的频率进一步细分报告贡献情况的更高级用例中，可以使用灵活的贡献过滤功能。 广告技术平台可以点击此处详细了解如何进行批处理，以及如何将过滤 ID 与 ARA 搭配使用，请点击此处。我们还在努力提供有关过滤 ID 的更多文档。 |
| 功能请求 | 请求支持汇总服务 (AgS) 中的“log_sum_exp”。 | 我们已与该利益相关方联系，详细了解相关用例。一旦有更多详细信息，我们就会立即通知您。 |
| 功能请求 | 请求在 AgS 上出现问题以及部署的 AgS 上存在潜在问题时，能够查看更多日志/数据分析/其他指标。 | 我们已在此处发布了文档更新，以添加更多错误、缓解措施和说明。 欢迎您就未记录或未提供的任何错误/指标/日志等以及哪些详细信息会很有用，在 此处提供更多反馈。 |
| API 测试 | 测试期结束后，epsilon 的最终值将是多少？ | 目前，我们没有计划修改 epsilon 值窗口。我们鼓励测试人员尝试不同的参数并提供反馈。 |
| 报告 | 正在生成报告，但仍收到返回代码 PRIVACY_BUDGET_AUTHORIZATION_ERROR。 | 我们提供了有关指定正确的报告来源和可汇总报告的指南，以避免出现此错误。 欢迎您就此问题提供更多反馈，尤其是在出现反复错误时。 |
| 密钥发现 | 键发现方案的计划是什么？ | 我们尚未确定按键发现提案的发布时间表，但我们正在此处征求生态系统对该提案的反馈。 |
| 自定义 | 寻求可用于汇总服务的自定义选项。 | 您无法在 TEE 中对汇总服务进行自定义，但可以对 TEE 外部的某些组件进行自定义。这是因为我们需要在 TEE 中维护隐私和安全标准。 我们正在更新文档，以帮助广告技术平台了解该架构以及哪些组件可自定义。我们不支持某些自定义设置，因此建议广告技术平台尽可能使用我们的标准配置。 |
| Spot 实例与按需实例 | 系统是否已使用 Spot 实例与按需实例进行过测试？除了可能暂时不可用之外，使用 Spot 实例是否有任何其他缺点？ | 我们尚未优先测试 Spot 实例，因为我们建议广告技术平台使用按需实例。Spot 实例的缺点是作业会在预算消耗期间中断。如果预算已用尽，并且作业在广告技术平台收到摘要报告之前中断，广告技术平台将无法仅重试作业，而需要请求预算恢复。建议仅在发生灾难性故障时恢复预算，以保护隐私。 我们建议广告技术平台配置自动扩缩，以帮助最大限度地降低费用。为自动扩缩选择 0 表示在有作业请求之前，系统不会启动任何正在运行的实例（请注意，由于实例将在收到请求时启动，因此这可能会增加延迟时间）。 |
| 已知错误和解决方案 | 关于显示“服务错误”的汇总服务作业需要澄清 | 此问题已在此处得到解决。 我们还更新了一些错误消息，使其更具描述性。例如，我们已开始在 AWS 上抛出更具体的权限/身份验证错误，而之前这些错误显示为内部错误。 我们在此处更新了有关错误代码和缓解步骤的文档，欢迎就未记录或提供的错误提供更多反馈，以及 在此处提供哪些详细信息。 |
Private Aggregation API
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 密钥设计 | 请求私有汇总密钥设计指南 | 虽然我们没有专门针对私有汇总的指南，但汇总服务负载测试框架和高级密钥管理指南都可以用作参考资源。 |
| 贡献预算 | 贡献预算是在哪个级别计算和限制的？ | 在 10 分钟的滚动时间范围内，贡献预算为 2^16；在 24 小时的滚动时间范围内，贡献预算为 2^20。 |
限制隐蔽跟踪
用户代理缩减/用户代理客户端提示
本季度未收到任何反馈。
IP 保护（以前称为 Gnatcatcher）
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| Android 设备 | 您计划如何在 Android 设备上推出 IP 保护功能？ | 我们正在探索为 Android 引入防隐秘跟踪功能（包括 IP 保护），但目前还没有正式计划。 |
| API 应用 | 关于 IP 地址保护是否存在或将推出反欺诈例外情况的问题 | 我们会努力在保护用户免受基于其 IP 地址在网络上被跟踪的同时，尽可能减少对服务器正常运行的干扰，包括使用 IP 地址进行防滥用。虽然我们目前无法提供更多详细信息，但预计会在不久的将来提供，并且期待继续讨论。 |
| 操作者身份错误 | 担心传统安全措施对恶意 IP 地址的防范效果。 | IP 保护不会代理第一方请求，因此我们预计大多数入侵检测系统都不会受到影响。我们计划日后提供更多详细信息，以解决与无痕式浏览用户的反欺诈和网站中断问题相关的问题。 |
| IP 地址遮盖 | 如果新闻发布商网站 (第一方) 与广告网站 (第三方) 使用相同的网域，这两个网站的 IP 地址会被屏蔽吗？如果不是，如何区分这两者？ | IP 保护目前提出了一种基于列表的方法来识别通过代理传输的第三方流量。不过，即使某个来源在该列表中，如果在第一方环境中访问该来源，它也不会被代理。我们正在最终确定最初将优先优先考虑哪些特定第三方网域，以及如何为知识产权保护精确定义第一方和第三方情境的详细信息。 |
| IP 地址遮盖 | 对知识产权保护及其对反欺诈系统的影响存有疑虑。 | 第一方不会受到我们的 IP 地址保护计划的影响，因此论坛等网站应有权访问 IP 地址以解决争议。我们计划日后提供更多详细信息，以解决广告欺诈问题。 |
| IP 地址遮盖 | 对于受影响的网域，标头是否遮盖了 IP 地址？ | 系统会根据用户代表其当前位置的代理前 IP 地址为其分配地理区域。您可以点击此处了解更多详情。 |
跳出跟踪缓解措施
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| API 规范 | 需要阐明 Chrome 在关闭标签页时处理扩展导航的行为。 | 我们已在此处解决此问题，并相应地更新了规范。 |
| 导航跟踪 | 讨论了一种跟踪缓解方法，该方法涉及一组有限的链接，用于减少跨网站请求中的熵。 | 我们将继续在此处与其他浏览器供应商讨论这一主题，也欢迎整个生态系统针对此问题提供更多反馈和任何具体建议。 |
隐私预算
正如 GitHub 说明文档和开发者网站中所述，Privacy Sandbox 不再
在 Privacy Sandbox 提案中得到积极考虑。
增强跨网站隐私边界
Related Website Set（以前称为 First-Party Set）
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| （也报告在上一季度）相关网站集 (RWS) 网域数上限 | 请求提高 RWS 中关联网域的数量上限 | 我们的回复与上几个季度类似： 目前，我们不打算提高数字上限。确定这一限制的依据是用户隐私方面的考虑、W3C 中生态系统相关方的反馈，以及对其他浏览器中的类似实现方式的 。如需了解详情，请参阅我们的博文 (1、2)。 我们建议您检查需要跨网站 Cookie 访问超出此数值限制的用例，并考虑利用我们针对身份用例、经过身份验证的嵌入和广告用例的指南。如果用户会话与登录操作相关联，我们建议您使用 Federated Credential Management (FedCM) API 来维护功能。 欢迎就其他可能需要的使用情形提供反馈，欢迎点击此处提供反馈。 |
| 跨网站 Cookie 处理 | 主网域中的后续请求不会传递由子网域设置的跨网站 Cookie。即使使用正确的 CORS 和凭据配置，问题仍然存在。 | 我们在此处提供了有关正确使用 requestStorageAccessFor API 的指南，其中指出需要指定完整来源（即包括子网域），以便在后续提取请求中发送跨网站 Cookie。 |
| 用户选择 | 请求提供有关 RWS 在推出用户选项后使用 requestStorageAccessFor 的更多信息，尤其是目前允许访问 3PC 的隐式或显式用户手势在新系统中的运作方式。 | 我们希望在任一用户选择模式（即，无论用户是选择保留还是限制其第三方 Cookie）下，RWS 的行为都将与在允许第三方 Cookie 的情况下和在启用 RWS 的情况下屏蔽的 3PC 中的 Chrome 中的现有/运输行为一致（“允许相关网站在组内查看您的活动”）。 我们建议您先调用 hasStorageAccess 来检查嵌入内容是否已拥有对未分区的跨网站 Cookie 的访问权限，然后再调用 requestStorageAccess。如果用户选择允许 3PC，hasStorageAccess 方法将返回 true。如果允许 3PC，requestStorageAccessFor 目前不需要用户手势。 我们已创建一个新 GitHub 问题，以讨论并指定在此情况下应采用的正确行为，欢迎生态系统提供更多反馈。 |
| API 应用 | 用户担心 RWS 未明确用于“商业”目的，因而难以采用。利益相关方对将出版物分组以投放有针对性的广告感兴趣。 | RWS 的预期用途是支持核心网站功能和核心用户历程。我们建议您针对与定向广告相关的用例使用专用广告 API。 |
| API 应用 | 报告了 requestStorageAccess 存在的问题，即可以设置 localStorage 数据，但无法设置 Cookie。 | 此问题是由 SameSite 属性中的拼写错误所致。确保拼写正确，并将其明确设置为“无”（适用于 3PC）。 |
| API 规范 | 代码库中 JSON 架构存在差异，例如“contact”字段放错位置，以及改进建议，包括使用“oneOf”关键字来确保一致性。 | 我们正在调查这些反馈，并将在不久的将来考虑对架构进行这些改进。 欢迎您在此处提供更多反馈。 |
| 第三方 (3P) 对 RWS 的访问权限 | 在征得用户同意后，允许相应渠道指明哪些第三方网域也将拥有对 RWS API 数据的此类访问权限。 | 如果允许第三方将自己的未分区数据与 RWS 网站数据相结合，将会破坏 Privacy Sandbox 的跨网站跟踪保护功能。 不过，我们正在考虑让第三方维护分区到 RWS 的数据的可能性，并希望 在此就此类解决方案的设计征求反馈。 |
Fenced Frames API
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| API 问题 | 对无法访问网络的 Fenced Frames 可能会如何破坏广告客户的品牌保障和欺诈防护的担忧。 | 我们正在实施“围栏框架”计划，以便跟踪这一问题。我们很快就会开始研究与围栏帧强制执行兼容的解决方案，一旦有足够实质性的方案，我们会立即分享。 |
| API 问题 | Fenced Frames API 是否仍计划于 2026 年发布？ | 正如我们的公告中所述，最早将于 2026 年启用围栏框架。 |
| API 错误 | 当 reportEvent() 成功从跨源子框架发送点击数据时，setReportEventDataForAutomaticBeacons() 不会覆盖顶部帧的数据。 |
我们正在讨论此问题，欢迎您在此提供更多反馈。 |
Shared Storage API
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 应用广告 | Privacy Sandbox on Android 中没有等效于 Shared Storage API 的 API。 | 我们正在根据用例需求和平台限制评估 Android 上的解决方案。我们目前还没有任何计划要分享，但欢迎整个生态系统就此问题提供其他反馈。 |
| API 应用 | 对是否需要额外的 JavaScript 工作函数来实现 Shared Storage API 感到困惑。 |
我们正在调查此反馈，并考虑是否更新我们的文档，以说明 Share Storage API 需要其他 Worklet 脚本。 |
| 不可靠 | Shared Storage API 可能会发生显著变化，或因隐私权方面的批评而被弃用，这使其成为构建基础的不可靠基础。 | 我们不打算大幅更改或删除共享存储基础架构。已宣布的主要变更涉及“选择网址”输出门限，其中要求使用封闭的帧，并将废弃事件级报告。不过，这些变更最早要到 2026 年才会生效。 |
CHIPS
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 分区 Cookie | 与 Firefox 不同，Chrome 不会根据帧祖先来区分分区键，从而导致不一致。 | Chrome 采用了“祖先链位”，以解决安全问题和与 Firefox 行为的差异。 如需了解详情，请点击此处。 |
| 分区 Cookie | 具有不同存储访问权限级别的嵌入 iframe 会共享并覆盖相同的分区 Cookie，导致身份验证状态不一致。 | 对于这种特定配置，我们建议您在调用 Storage Access API 时使用未分区的 Cookie。 我们在此处进一步讨论了这一点。 |
| 分区 Cookie | 停用 3PC 后，分区 Cookie Jar 是否会被清除？是否有办法测试此行为？ | 目前，我们没有任何计划可以分享。不过，开发者可以通过 Chrome DevTools 的“Application”>“Cookies”面板手动删除分区 Cookie，以测试此功能。 |
FedCM
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 身份提供方 (IdP) 注册范围和组织选择器 |
关于将 IdP 注册从当前的同源政策扩展到同网站政策的问题。这一变化将实现更广泛且更灵活的身份管理，例如让大学的欢迎页面可以注册多个基于子网域的身份提供方，而无需单独的源特定注册。 针对以下方面的反馈：改进可调试性、处理已获批准的客户端以实现静默中介、阐明 Cookie 行为、允许自定义弹出式窗口用语以及解决超时问题。 |
我们认可这些反馈，并正在考虑如何将组织选择器并入 FedCM。 欢迎生态系统提供其他反馈，请点击 此处，我们将不断完善这一方法。 |
| IdP Cookie | 讨论在设备绑定会话凭据 (DBSC) 提案中实现短时有效的会话 Cookie 的影响。FedCM 对用户体验提出了质疑，因为过期的 IdP Cookie 需要使用用户可见的模态来续订。 | 建议的 DBSC 应允许在无需用户互动的情况下续订 Cookie，从而确保持续的用户体验。 我们已在此处详细讨论了此问题。 |
| API 规范 | 关于在“providers”数组的大小不等于 1 时，在 FedCM API 规范中使用“NetworkError”是否恰当的问题。 | 我们同意，“TypeError”更适合这种情况，因为它反映的是编码错误，而不是网络问题。随着我们逐步支持多身份提供方 (IdP)，我们会考虑这项变更，并探索在未来的更新中移除此限制的可能性。 欢迎您在此处提供更多反馈。 |
打击垃圾内容和欺诈行为
Private State Tokens API（及其他 API）
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 弃用试用和模式 B | 对弃用试用、模式 B 测试、私有状态令牌 (PST) 可能终止以及是否有更适合其防欺诈用例的新 API 存在疑虑。 | 弃用试用和模式 B 测试保持不变。我们会通过开发者博客发布任何更新。我们无意停用 PST，并且正在 GitHub 上讨论持续的功能开发和更新。 我们尚未公布任何新的 API，但我们欢迎您就 PST 如何更好地处理反欺诈用例提供反馈，欢迎提供反馈。 |
| API 反馈 | 请求撤消令牌功能，以解决反欺诈用例。 | 虽然发行者可以通过更改所用密钥来撤消所有令牌，但无法使用此 API 撤消个别令牌，因为这需要允许发行者关联令牌发放和兑换，这会破坏 PST 隐私模型，即阻止在两次事件之间进行跟踪。 |