2025 年第 1 季度季度报告，总结了收到的有关 Privacy Sandbox 提案的生态系统反馈和 Chrome 的回复。
Google 已根据《竞争和市场管理局法案》（以下简称“CMA 法案”）第 12 条、第 17(c)(ii) 条和第 32(a) 条，履行其承诺，准备了这份季度报告。本报告涵盖 Google 在 Privacy Sandbox 提案方面的进展；更新的时间预期；Google 如何考虑第三方观察结果的实质性说明；以及 Google 与 CMA 之间的互动摘要，包括 CMA 的反馈和 Google 对反馈的处理方法。
Google 一直在按照承诺第 17(b) 段的安排，在定期举行的状态会议上向 CMA 通报 Privacy Sandbox 提案的进展。此外，该团队还负责维护开发者文档，其中概述了核心隐私广告功能和Cookie 变更，以及 API 实现和状态信息。我们会在开发者博客上分享重要更新，并将有针对性的更新分享给各个开发者邮寄名单。
首字母缩写词表
- ARA
- Attribution Reporting API
- CHIPS
- 具有独立分区状态的 Cookie
- DSP
- 需求方平台
- FedCM
- Federated Credential Management
- IAB
- 美国互动广告局
- IDP
- 身份提供方
- IETF
- 互联网工程任务组
- IP
- 互联网协议地址
- openRTB
- 实时出价
- 加时赛
- Origin 试用版
- PA API
- Protected Audience API（以前称为 FLEDGE）
- PatCG
- “私密广告技术”社区群组
- RP
- 依赖方
- RWS
- Related Website Set（以前称为 First-Party Set）
- SSP
- 供应方平台
- UA
- 用户代理字符串
- UA-CH
- 用户代理客户端提示
- W3C
- 万维网联盟
- WIPB
- 故意忽视 IP
一般反馈，无特定 API/技术
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 用户选择 | 目前尚不清楚 Google 为提升用户选择权而更新的方法将是什么样子、将以何种方式向用户展示，以及预计的用户选择接受/拒绝的比例。需要提供更多信息，才能将其与第三方 Cookie 弃用区分开来。 | 2025 年 4 月，Google 发布了一篇博文，标题为 Chrome 中 Privacy Sandbox 和跟踪保护功能的后续步骤，宣布 Google 决定继续沿用当前在 Chrome 中向用户提供第三方 Cookie 的方法，不会推出新的独立第三方 Cookie 提示。 如有进一步消息，我们会及时通知您。 |
| 数字“指纹”收集 | Google 从未与发布商或营销者分享过任何信息，说明他们如何在不使用风险更高的消费者身份作为通用匹配键（即“指纹”）的情况下，依赖 Google 广告系统的任何替代方案。 | 我们重点介绍了几种非 Google 广告系统，它们在为发布商和营销者提供解决方案时，部分依赖于 Privacy Sandbox API。这包括各个市场和渠道的非 Google 广告系统。如需了解更多详情和案例，请访问 privacysandbox.com 的“商家资源”部分（点击此处）。 |
| Privacy Sandbox | Privacy Sandbox API 将用 Google 自己的成品替代互联网数据要素。由于 Google 的替代方案是 API，因此 Google 提供的是其拥有和控制的产品的访问权限，该产品受 Google 自行决定的条款及条件约束。这不能替代他人用于制作自己的成品组件。 | Privacy Sandbox API 是在与监管机构和各种生态系统利益相关方广泛互动后开发和实施的。与其他平台技术一样，Privacy Sandbox API 必须考虑到它们将作为组件被用于他人的成品中，我们欢迎生态系统开发与 Privacy Sandbox API 协同工作的其他技术。 |
| 用户选择 | 请求提供信息，了解 Google 在 Chrome 上针对第三方 Cookie 更新的方法是否符合特定法规要求，这些要求可能会影响利益相关方意见征求管理平台的使用体验。 | 2025 年 4 月，Google 发布了一篇博文，介绍了 Chrome 中 Privacy Sandbox 和跟踪保护功能的后续步骤，宣布 Google 决定继续沿用当前在 Chrome 中向用户提供第三方 Cookie 的方法，不会推出新的独立第三方 Cookie 提示。 如有进一步消息，我们会及时通知您。 |
| Privacy Sandbox 时间表和采用情况 | 广告技术平台已暂停 Privacy Sandbox API 测试，并在寻找更有力的理由，以便重新投资于这些技术，用于产品和营销活动。他们在重新投资方面的决策在很大程度上受到以下因素的影响：需要更清楚地了解“用户自选”时间表，以及对 Protected Audience API (PA API) 延迟时间和 B&A 路线图的疑虑。此外，对于即将到来的 CMA 承诺审核，一些人也表示担心，尤其是 Google 作为不依赖第三方标识符的 Privacy Sandbox 技术的主要推动者，以及该计划未来的整体发展方向是否能为投资策略提供指导。 | 2025 年 4 月，Google 发布了一篇博文，标题为 Chrome 中 Privacy Sandbox 和跟踪保护功能的后续步骤，宣布 Google 决定继续沿用当前在 Chrome 中向用户提供第三方 Cookie 的方法，不会推出新的独立第三方 Cookie 提示。如有进一步消息，我们会及时通知您。 Chrome PA API 竞价速度比去年提高了 35%。此外，我们发现并行竞价的使用量大幅增加，这让这些竞价的胜出几率更高。 如需查看我们当前的 B&A 路线图，请点击此处。 |
| Privacy Sandbox 时间表 | Privacy Sandbox 时间轴页面有哪些更新？ | 我们最近在 Privacy Sandbox 时间表页面中添加了 Topics API 的概览。 |
| Privacy Sandbox | 是否有任何关于隐私保护与实用性的研究论文，可帮助了解 Privacy Sandbox 对收入的影响？ | 如需查看可解答这些问题的相关市场案例研究，请点击此处；如需查看 Privacy Sandbox API 测试结果，请点击此处。 |
| 采用 Privacy Sandbox | 一位早期采用者表示，由于大型公司的采用速度缓慢，Privacy Sandbox API 在初期存在一些问题，影响了测试的发布。尽管如此，我们还是很感谢 Privacy Sandbox 团队的协作方式和对反馈的回应。 | 感谢抢先体验者提供反馈。我们致力于与早期采用者合作，并将继续与整个生态系统互动并收集反馈，以评估 Privacy Sandbox 技术在支持生态系统方面发挥的作用。 |
| Chrome 测试 | 担心在移除测试标签后，是否能继续有效地进行 Privacy Sandbox 测试。测试结果表明，停用第三方 Cookie 的 Chrome（模式 B）与用户在 Chrome 设置中自行停用第三方 Cookie 的流量质量存在显著差异。 | 我们的回复与上个季度类似： Privacy Sandbox 团队理解，各公司希望继续使用Cookie 弃用标签。延长标签的使用期限的过程与延长来源试用期的过程类似。我们曾多次延长对这些标签的支持期限。我们计划提议进一步扩大对 Cookie 弃用标签的支持，并会在blink-dev 上分享最新动态。 |
注册和认证
本季度未收到任何反馈。
展示相关内容和广告
主题
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 选择启用/停用 | Google 确认 Google 搜索不会将网站选择停用 Topics API 的决定作为排名信号，这是否会限制 Google 将网站选择启用 Topics API 的决定作为排名信号？ | 我们的回复与上几个季度类似： Privacy Sandbox 团队未与搜索组织协调或请求他们将网页排名作为激励措施，以便网站采用 Topics API。Google 搜索不会将网站是否支持 Topics API 作为排名信号。 |
| 使用情况可观测性 | 为 SSP 或通用广告技术平台请求可观察性机制，以便了解其实现的 Topics API 是否在网络上使用。 | 我们正在评估是否支持此功能。如果此功能是高优先级功能，我们欢迎生态系统提供更多反馈。 |
| 隐私权 | 关于用户意见征求和重标识可能性的问题。 | 我们目前正在此处讨论此问题，欢迎您提供更多反馈。 |
Protected Audience API
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| PA API 和 GAM/AdX | 如果发布商希望依赖竞争对手的发布商广告服务器，Google 将不会向其发送任何 GAM/AdX 需求。Google 应让竞争对手发布商能够选择其他顶级 PA API 竞价卖方来控制最终竞价。PA API 中的信息将可供 GAM 使用，但对竞争对手 SSP 而言则受到限制。因此，发布商无法在 GAM 中比较 PA API 来源需求的效果，例如来自 AdX 或集成到 PA API 的 SSP 的需求。 | Chrome 回复： PA API 标准旨在实现灵活性，允许不同的方运行顶级竞价。此选择取决于发布商的广告服务器（无论是 GAM 还是其他服务器）以及生态系统中的其他参与公司提供的具体实现和功能。 PA API 以隐私保护为中心的设计会一贯限制所有参与者的精细报告。对于所有参与者（包括所有 SSP）而言，PA API 竞价本身报告的具体数据都受 API 定义的相同隐私保护规则和限制。 发布商使用 PA API 提供的注重隐私保护的汇总报告来评估效果。这样一来，您就可以评估通过 PA API 获取的需求的总体贡献，并与其他需求渠道进行比较，从而遵循该 API 的“从设计上实现隐私保护”原则。 Google Ad Manager 提供的回复： 发布商无需使用 GAM 的广告服务器功能即可访问 AdX 需求。此外，无论是单卖家还是多卖家设计，PA API 对发起竞价的正文并不关心。 |
| 顶级卖家 | 顶级卖家 (TLS) 可以访问其他任何组件卖家都无法访问的信息，这引发了人们对信息访问权限不平等的担忧。虽然任何实体都可以是 TLS，但为了访问 AdX 需求，发布商必须使用 GAM 作为发布商广告服务器。这会促使发布商使用 GAM 作为发布商广告服务器，从而为 Google 带来竞争优势。 | Chrome 回复： PA API 的设计并未规定哪些实体可以充当 TLS。TLS 角色需要根据 API 的结构协调竞价并访问相关竞价信息。 Google Ad Manager 提供的回复： 我们多年来一直非常重视竞价公平性，包括承诺在其他买方在竞价中出价之前，不会与其分享发布商任何无保证广告来源（包括无保证订单项价格）的价格。我们后来在向法国竞争管理局做出的承诺中重申了这一点。 对于 PA API 竞价，我们会信守承诺，在多卖方竞价结束之前，不会与任何其他竞价参与者分享任何竞价参与者的出价。需要说明的是，我们不会与任何组件竞价（包括我们自己的竞价）共享内容相关竞价的价格，如此更新中所述。此外，我们不会在自己的竞价中使用有关组件竞价配置的信息，包括买方向 SSP 提供的信号。 此外，如上所述，GAM 不要求发布商使用其广告服务器功能才能访问 AdX 需求。 最后，正如 Google 2024 年第 2 季度 / 第 3 季度报告中之前所述，Google 的买方平台（Google Ads [以前称为 AdWords] 和 DV360）确实会从非 Google 广告交易平台（包括通过 PA API）购买展示机会。 |
| PA API 和 GAM/AdX | 由于该选项的标签未明确说明用途，因此发布商很难理解为何要在 100% 的广告资源中启用 PA API。对于 SSP，其主要的广告资源访问方式通常是通过 GAM 充当 TLS 的多级竞价，因此，如果不受 GAM 约束，就无法通过 PA API 进行测试或创收。 | Chrome 回复： PA API 标准定义了技术角色（例如 TLS 和组件卖方）和竞价流程，让平台可以灵活地执行这些角色。 运营活动（例如配置、协调和协议）由实现方（发布商、SSP、TLS 提供商）管理，以便使用 PA API 框架参与。 Google Ad Manager 提供的回复： 如帮助中心中所述，Ad Manager 为发布商提供了一个控件，可让发布商针对其 100% 可使用该 API 的广告资源启用与非 Google 组件卖方（例如其他 SSP）的测试（替换 GAM 可能应用的任何抽样或节流）。 如果发布商启用此控件，那么每当非 Google 组件卖方提供竞价配置时，GAM 都会尝试运行包含所提供组件竞价的顶级竞价（前提是发布商已征得必要的用户同意）。GAM 会向发布商明确说明此控件可能会影响效果，以便发布商做出明智的决策。 |
| 服务器端与设备端 | 服务器端解决方案（例如出价和竞价 [B&A]）有望在保护隐私的同时解决流量塑形问题。服务器端解决方案是唯一可行的前进方向，Google 应放弃设备端解决方案。 | Privacy Sandbox 旨在同时支持服务器端（B&A 服务）和设备端竞价解决方案，提供多种选项来满足不同的广告技术需求和使用场景。 |
| 竞价安全 | 对 PA API 出价的攻击从根本上使设备端出价和竞价失去了资格，利益相关方认为此问题尚未得到解决，并继续要求提供技术保证，以确保 PA API 出价不会被篡改，以及提供详尽的调试模式，以便实时检测突发事件并高效调试。 | 确保 PA API 竞价完整性（包括减少潜在攻击）是 Privacy Sandbox 的一个重点。API 的设计中包含完整性措施，我们欢迎就具体问题进行进一步的技术讨论。 我们在 2024 年 5 月的 W3C 反欺诈社区组会议期间，展示并讨论了 PA API 可能遭受的攻击的详细列表以及我们的缓解措施。欢迎您就可能存在的“针对 PA API 出价的攻击”问题进行进一步讨论并提供反馈。 |
| 无 Cookie 流量 | 是否有方法仅针对不使用 Cookie 的流量启用 PA API，以进行测试或用于其他用途？ | 广告技术平台可以确定是否存在第三方 Cookie。如需详细了解，请点击此处。 |
| 席位 ID | 关于座位 ID 提案，座位 ID 知识对大多数出价请求至关重要，这引发了将座位 ID 与广告素材注册相关联的疑虑。此外，它是否仅适用于“主要广告”，还是也适用于组件广告？ | BuyerAndSellerReportingId 提案解决了在为主要广告注册广告素材时缺少买方账号 ID 的问题。此标识符旨在将买方的座位 ID 传达给卖方。我们正在评估对组件广告的支持。 |
| 监控和报告 | 实时监控 (RTM) 功能请求：(1) 针对已取消的竞价发送 RTM 报告，以及 (2) 浏览器填充的新分桶，以明确发生了哪种取消。 | RTM 似乎不适合用于调查参与率。RTM 是一款低延迟监控 API，旨在捕获突然发生的关键性临时服务中断。与之相反，参与度不需要低延迟报告，也不是突然发生的严重临时中断。买方与之合作的卖方最有能力解答有关参与率的问题，而不是买方通过浏览器进行调查。 此外，由于取消的竞价非常常见，如果浏览器针对每次取消的竞价生成 RTM 报告，则可能会掩盖实际中断的 RTM 报告。 |
| 文档 说明 |
报告了 PA API 说明文档中存在文档差异，其中指出 Nonce 应为 UUID 字符串，但实际上它会返回一个 Promise。 | 您可以点击此处查看相关说明。 |
| 冻结的 上下文 |
在使用冻结的上下文时，有哪些选项可用于解决与 (1) 捆绑、(2) 外部库和 (3) 不受支持的数据类型相关的问题和挑战？ | 我们已在此处对此问题做出了回复。 |
| 规格 | Private Aggregation API 添加了一个通用的 contributeToHistogramOnEvent 操作。因此，PA API 中的定义变成了过载操作，而 Web IDL 操作“不得在接口、部分接口 [...] 中过载”，因此该定义现在无效。 | 此问题指出，在我们合并这两项规范中的类似更改时，PA API 和 Private Aggregation 规范之间存在暂时性不一致。我们已合并一个拉取请求来解决此问题。 |
| 兴趣群体 | 请求有关在广告系列停止投放时结束兴趣群体 (IG) 出价参与的推荐且节省资源的方法的指南。 | 我们可以提供以下一些建议： 我们认为，延迟时间最短、最不永久但也最不耗用资源的机制是使用实时出价信号告知其 generateBid() 停止出价。第二种使用更少资源的方案是在实时出价信号响应中为该 IG 设置负优先级，因为这会阻止 generateBid() 被调用。第三种方法（使用的资源更少）是从 Instagram 中移除广告。不含广告的 IG 不会调用 generateBid()。第四种方法（使用的资源更少）是从 IG 中移除 biddingLogicURL。此时，您仍然可以更新/重新加入 IG，以便重新激活它。其他选项与离开 IG 有关，可以通过 leaveAdInterestGroup() 或 clearOriginJoinedAdInterestGroups() 或 IG 到期离开。如上所述，不同的选项会产生不同的延迟时间和资源消耗。广告技术平台可以选择最适合其特定用例的折衷方案。 |
| 受众群体 | 请求提供一种机制，用于对构建的受众群体运行逻辑运算（例如，能够定位到 IG A 和 B 的交集） | 现在，借助 PA API，您可以对来自同一网站的受众群体执行逻辑运算。出于隐私保护方面的考虑，我们目前不支持对不同网站上的受众群体执行逻辑运算，如我们的隐私保护模型中所述。我们将继续开展这方面的研究，并会随时分享最新动态。 |
| 功能请求 | 提案：移除对额外出价的限制，不再要求提前知道 TLS。 | 我们目前正在此处讨论此提案，欢迎您提供更多反馈。 |
| 更新了 Chrome 上的 3PC 方法 | PA API 等 Privacy Sandbox API 是否仍会面向所有 Chrome 稳定版用户正式发布，还是这些 API（或部分 API）仅面向拒绝了 3PC 的用户提供？ | 我们不希望用户拒绝第三方 Cookie 的决定会影响 Privacy Sandbox API 在 Chrome 稳定版中的可用性。 |
| 增强型信号 | 是否有计划添加功能来指明 TLS 是否打算运行 PA API 竞价？ | 我们正在评估是否支持此功能。我们会在有更多详细信息时分享，欢迎您就此请求提供更多反馈。 |
| 优惠 ID | 担心交易 ID 提案中的 KV 服务器要求可能是一个耗时且成本高昂的服务器端流程。 | 借助交易 ID 提案，SSP 可以在 PA 竞价期间从键值对服务器查询所选交易 ID 的元数据，这样就无需将所有与交易相关的元数据预加载到设备上。我们之所以提出此提案，是为了响应 SSP 的要求。我们欢迎您在此处提供更多生态系统反馈。 我们理解设置键值对服务器需要做一些工作，但总体而言，我们仍认为这对广告技术公司而言是利大于弊。我们一如既往地欢迎您就如何简化此流程提供反馈和建议。 |
| 跨 Instagram 频次上限 | 请求通过 PA API 设置跨 Instagram 频次上限。 | 跨 Instagram 频次上限具有复杂的隐私保护特性，我们一直找不到解决方案。 如果生态系统认为此功能是优先事项，我们欢迎您提供更多反馈。 |
| 交易 ID 和账号 ID 报告 | 请求能够将交易 ID 或座位 ID 纳入汇总报告中。 | 我们正在此处 开发报告 ID 功能，以便您报告交易 ID 和座位 ID。 selectedBuyerAndSellerReportingId 会提供给 reportResult()，因此报告此 ID 的最简单方法是通过事件级报告（即将交易 ID 编码到传递给 sendReportTo() 的网址中）。如果要使用汇总报告，也可以这样做。 报告 ID 功能目前面向 10% 的 Chrome 稳定版渠道流量推出。我们正在评估是否要将此功能的发布范围扩大到 100%。 |
| 兴趣群体 | 在 IG 选择和评估中使用相同的优先级顺序，并在所有评估模式中使用该优先级顺序。 | 我们目前正在此处讨论此问题，欢迎您提供更多反馈。 |
| 兴趣群体 | 建议使用受众群体激活和委托来提高 Privacy Sandbox API 的采用率。 | 我们已知晓多方利益相关方提出的这项请求，并正在研究相应解决方案。 我们欢迎生态系统提供更多反馈。 |
| 兴趣群体 | 创建 PA API IG 时遇到的挑战，尤其是在代表多个买方或代表发布商进行操作时遇到的委托和所有权方面的问题。 | 我们已收到多方利益相关方提出的支持更高级别 IG 委托的请求，并认为 SSP 可以为此流程提供额外的价值。 我们正在开展研究，以寻找最佳解决方案，让不同的方能够参与受众群体扩展流程。我们欢迎生态系统提供更多反馈。 |
| 客户端性能 | 请求有关简化 trustedBiddingSignals 的客户端缓存的指导，以优化基础架构费用和延迟时间。 | 我们目前正在此处讨论此问题，欢迎您提供更多反馈。 |
Protected Auction（B&A 服务）
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 键值对服务 | 如何将从浏览器发送到卖方 KV 服务器的请求进行批处理？对于卖家，来自浏览器的请求是什么样的？是 GET 请求还是 POST 请求？此外，还需要对 k-匿名性要求进行一些说明。 | 对于 v1，Chrome 会向卖方的 KV 服务发送 GET 请求，以便使用请求的查询参数中的信号提取 trustedScoringSignalsURL。这些参数包括 hostname、renderUrls、adComponentRenderUrls 和 experimentGroupId。我们目前正在实验一些扩展程序，以便发送额外信息以供广告素材扫描，但尚未发布。将 maxTrustedScoringSignalsURLLength 设置为 0 后，Chrome 可能会将所有信号批量处理到单个请求中（可能会超出服务器上的任何网址长度限制），但不能保证一定会这样。如果请求准备好在 10 毫秒内发送，Chrome 目前会选择将其包含在同一批请求中，但我们目前正在研究如何优化此操作。使用 trustedScoringSignals 时，请务必注意 Chrome 会遵循缓存标头。 Stale-While-Revalidate“Cache-Control”标头等标头可以允许 Chrome 使用缓存的副本（并更新下一次竞价的缓存），从而缩短平均延迟时间，从而有效地从关键路径中移除信号提取。最后，关于 k-匿名性，说明文档中的特定部分似乎已过时。我们原本要求可信信号网址具有 k-匿名性，但后来取消了这一要求。我们会从说明中移除这句话。 |
| B&A 服务 | 升级到最新版本的 B&A 需要很长时间。缩短构建时间或使用预构建映像会很有帮助。 | 广告技术平台可以自行构建二进制文件，并使用提供的哈希进行验证。我们将考虑在未来研究是否有可能提供预构建工件或缩短构建时间。 |
| API 功能请求 | 请求为出价和竞价服务 (B&A) 构建脚本、容器映像和调用工具提供 macOS 兼容性，以便于本地开发和测试。 | 我们目前支持 amd64，这足以部署到受支持的云平台（GCP 和 AWS）。我们日后可能会研究对其他架构的支持。 |
| AWS | 是否必须创建 IAM 角色才能发布正式版 build？ | 是的，您需要 IAM 角色才能获得适当的权限并与协调者进行沟通。这些密钥用于解密在设备上生成的 ProtectedAudienceInput 密文（如此处所述）。此外，这些角色还需要使用这些协调者通过生产 build 的服务器/TEE 认证。如需了解详情，请参阅我们的自助指南。 |
| B&A 标志 | 请求在文档中列出可用 B&A 标志的定义，因为目前这些定义位于 Terraform 代码、cc 文件和 proto 文件中，但广告技术平台可以通过这些标志文档获益，将其用作了解如何自定义部署的可靠来源。 | 我们正在研究是否可以记录 Terraform 标志说明，欢迎您在此处提供更多反馈。 |
| AWS 出价服务 |
需要有关在 AWS 上使用出价服务以及默认日志记录行为和配置的指导。 | 如需在 TEE 中调试出价服务（例如出价服务），我们建议您使用广告技术平台同意的调试。这样，您就可以直接从客户端启用详细日志记录，并捕获特定测试请求的请求/响应数据，以便进行调试。 |
| TEE K/V 文档 |
请求澄清 dev 网站上所述的 TKV 强制执行的开始时间。 | 在要求使用 TEE 之前，我们会提前提供充分的通知。在此之前，您可以继续使用自己的服务器来获取实时键值对信号。 |
| B&A 测试和分析 | 但 B&A 分析和测试成本仍然很高，似乎还不适合投入生产环境使用。 | 我们需要更多关于成本分析的信息，以及导致您认为应用不符合正式发布条件的因素，以便进一步调查。 |
| 可信服务器优化 | 提议将特定于组件卖方的参数合并到一个 inputsPerSeller 参数中，并使用 JSON 字符串作为其值。 | 我们正在讨论此提案，欢迎您在此处提供更多反馈。 |
| 安全 | 如何通过使用 B&A 来降低 TKV 带来的安全风险？ | 可以防止对 TKV 进行外部调用。目前，GCP 完全支持此功能，并且可进行配置。 对于 AWS，由于之前支持此功能的 AWS App Mesh 已废弃，因此需要开发额外的支持。欢迎您在此处提供更多反馈。 |
| B&A 服务 | 请明确说明有关 HTTP 流式传输对 B&A 优化的价值的说明/沟通信息。 | Privacy Sandbox 支持在传输 B&A 数据时使用流式传输功能，以缩短选择使用该功能的广告技术平台的延迟时间。在混合模式下，这项功能是可选的性能优化。 |
| 出价前 | 请求有关为开源预出价库做出贡献的最新动态，以便为生态系统启用 PA API B&A 功能。 | 2025 年 3 月，Chrome 在稳定版中推出了“优先使用出价前优化”功能，如 B&A 公开路线图中所述（请参阅 2025 年 3 月）。 |
| 流量控制 | 请求提供机制来记录 B&A 收到的情境信号，以便更好地了解 IG 何时被激活，并改进其在情境响应中的“出价意图”逻辑。这样可以更好地利用网络资源，避免出现“无用流量”（也称为流量整形）。 | 我们目前正在 此处讨论一项提案，欢迎您提供更多反馈。 |
| 文档 说明 |
需要澄清在 B&A 测试集成设置中发现的“无法访问服务/Vsock 代理”错误。 | 这是由于最低内存要求所致。AWS 配置说明已更新，以反映此要求。 |
衡量数字广告的效果
Attribution Reporting（及其他 API）
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 实时数据 | 缺少实时数据会影响整个行业的所有人。实时数据延迟对广告客户来说是一个严重的问题，买方会转向使用 Google Analytics 的平台，因为只有 Google Analytics 才能证明他们覆盖了受众群体。 | Attribution Reporting API (ARA) 中包含的实时数据延迟功能是作为隐私保护机制实现的，旨在降低广告技术平台使用事件级报告跨网站跟踪用户的能力。不过，ARA 提供了灵活的归因报告提交方式，允许事件级报告的最短报告期为 1 小时，并允许汇总报告选择立即发送给广告技术平台，无需延迟。 |
| API 使用情况 | 请求确认跨网站应用归因流程的正确配置，尤其是在同时运行网站到网站归因和网站到应用归因时。 | 在并行投放网站到网站广告系列和网站到应用广告系列时，广告技术平台应仅选择一个平台来注册每个来源或触发器，以防止重复统计。我们强烈建议您尽可能使用操作系统 (OS)，因为只要正确委托了网站来源和触发器，OS 便能够执行网站到网站归因和网站到应用归因。这意味着，对于来源，应使用 Attribution-Reporting-Register-OS-Source 标头进行响应；对于触发器，应使用 Attribution-Reporting-Register-OS-Trigger 标头进行响应。 Attribution-Reporting-Support 标头可用于确定是否有 Chrome 和/或 Android 级支持。如果请求中没有 Attribution-Reporting-Support 标头，Attribution-Reporting-Info 标头会很有用。在这种情况下，浏览器会根据用户设备上是否支持相应平台来做出平台注册决定。 |
| API 规范 | 希望澄清 Attribution Reporting API 设置的 Attribution-Reporting-Support HTTP 请求标头，以及该标头是否应包含 web 和 os 键（无论平台如何）。 | Attribution-Reporting-Support 标头会受到浏览器添加“GREASE”参数的影响，以确保服务器使用符合规范的结构化标头解析器。对于此标头，应仅解析结构化字典键。这些值和参数目前未使用。如需查看示例，请点击此处。 |
| 基于 3PC 的报告 | 请求有关如何排查广告系列中 ARA 和 3PC 之间衡量差异问题的指导。 | ARA 支持两种类型的调试报告，可用于排查和调试差异。归因成功调试报告可用于轻松比较 ARA 结果与其他衡量技术的结果，详细调试报告可用于获取更多信息并排查归因注册中的潜在问题。 |
| API 应用 | 在测试 ARA 时，我们发现了一些问题：报告不够精细，导致数据杂乱无章、广告系列优化不灵活；阈值较高，排除了一些规模较小的广告客户；由于关键绩效指标不一致，广告系列难以比较。 | ARA 提供了多个参数，广告技术平台可以对这些参数进行自定义，以实现其特定的衡量用例，从而实现灵活性。事件级报告支持灵活的事件级报告，让广告技术平台能够自定义报告期、可接收的报告数量以及要衡量的触发器数据，从而改变噪声对数据的影响，并实现不同的应用场景。同样，广告技术平台可以通过多种方式自定义汇总报告的配置，例如跟踪的维度数量、批处理频率，以及使用贡献预算来改变噪声的影响，并实现不同的用例。 |
| API 规范 | 关于 ARA 对 3PC 的依赖性的问题，具体而言，是指 ARA 是否仍处于需要这些 3PC 的测试阶段。 | ARA 的启用与 3PC 无关，但需要启用 3PC，以便 ARA 过渡调试报告能够将 ARA 结果与基于 Cookie 的归因结果进行比较。 |
| API 应用 | 询问如何使用 ARA 在较低版本的 Android（11、12 和 13）上注册应用到网站归因的来源。 | Android S 及更高版本（12 及更高版本）目前支持 ARA。 |
| API 应用 | 请求获取 ARA 用户选择接受率和分发详情。 | 我们的回复与上个季度保持不变： “我们无意与生态系统分享此类信息。欢迎开发者调用他们已部署代码的 API，以估算 Privacy Sandbox API 的可用性” |
| API 可用性 | 启用 ARA 时，3PC 是处于启用状态还是停用状态？ | 在用户的浏览器上启用 ARA 不会对用户的 Cookie 设置产生任何影响。ARA 可以处于启用状态，而用户可以选择启用或停用 Cookie。 |
| 报告 | 我们可以在“Attribution-reporting-support”标头中收到预定义的值列表吗？ | 如我们的 指南中所述，该值是一个结构化标头字典，目前仅定义了操作系统和网站键的存在与否。应忽略标头的所有其他部分。换句话说，解析需要使用结构化标头解析器，而不是简单的字符串匹配。 |
汇总服务
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 功能请求 | 汇总服务的功能请求： 服务器到服务器集成、跨设备衡量、简化多触点归因和贡献报告、全渠道归因，以及对高级机器学习优化循环的支持（例如私密模型训练）。 |
我们正在评估这些要求，一旦有进一步详情，便会与您分享。 我们欢迎生态系统就这些请求是否属于优先事项提供更多反馈。 |
| 功能请求 | 请求在 Terraform 环境中将 EBS delete_on_termination 参数设置为 True，以缓解更新汇总服务集时重置问题的疑虑。 | 我们正在评估此请求，一旦有进一步详情，便会与您分享。 欢迎生态系统中的各方通过此处就此请求是否应列为优先事项提供更多反馈。 |
| 文档 说明 |
请求有关哪些内容可以更改（例如监控阈值）以及哪些内容应保持不变的指导。 | 我们正在考虑发布有关汇总服务可用自定义设置的其他文档和指南。 |
| 部署 | 请求说明有关在 bazel 命令中失败的新部署。 | 部署失败可能是因为环境中使用的 Bazel 版本。 文档将进行调整，以涵盖 Terraform 失败的调试，并指明所需的 bazel 版本。 |
Private Aggregation API
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| API 应用 | 请求有关一些实现方面的挑战的指导，例如因报告的共享存储空间限制而可能丢失数据、因基数过高而需要复杂的汇总服务许可名单（建议使用通配符）而遇到困难，以及因汇总服务的“无重复”规则而导致测试速度变慢。 | 关于 Shared Storage 限制，20 次贡献次数限制（详见此处）是指每次执行，而不是每月。此外，API 调用方可以替换此限制。此限制旨在帮助管理汇总服务中处理报告的费用，而不是限制报告实用程序。 关于通配符查询，我们正在评估此请求，并会在有更多详细信息时分享。 关于“不得有重复”规则，为了支持测试，我们暂时支持调试模式，以便绕过此规则。如需了解详情，请点击此处 。 |
| 过滤 ID 和存储分区 | 是否可以在两个单独的汇总运行中向汇总服务请求使用两个不同过滤 ID 的同一存储分区，即过滤 ID 能否充当域名的补充分区？ | 是，此功能受支持。执行汇总时，系统只会处理过滤 ID 与作业参数中的列表匹配的贡献，其余贡献将在单独的运行中处理。 |
| 多接触点归因 | 关于多触点归因 (MTA) 实现的澄清请求： 1) 如果汇总值不超过 2^16，贡献次数是否有上限？ 2) 可为给定情境存储的唯一汇总键（存储分区）的数量是否有限制？ 3) 如果每个用户代理（浏览器）都有唯一的汇总键（MTA 中可能存在这种情况），Aggregation Service 如何处理摘要报告？ |
1) 我们已设置默认的贡献限制，但 API 调用方可以选择替换这些限制，如此处所述。这些限制旨在帮助 API 调用方管理在汇总服务中处理报告的费用。 2) 没有此类限制，但广告技术平台应考虑汇总键的精细程度，以提高信噪比，如此处所详述。 3) 请参阅此指南，尤其是上面第 2) 项中提到的信噪比指南。 |
限制隐蔽跟踪
用户代理缩减/用户代理客户端提示
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 功能请求 | 请求向 User-Agent 客户端提示 (UA-CH) 添加 Sec-CH-UA-Robot，以便服务器能够识别自动流量，以进行内容自适应、安全和分析。 | 这是其他标准组织正在讨论的一个重要用例（如需了解详情，请点击此处 ），我们建议感兴趣的各方提供反馈，参与讨论。不过，我们认为 UA-CH 可能不适合解决此问题，因为 HTTP 请求标头很容易被自动化流量操纵。 |
IP 保护（以前称为 Gnatcatcher）
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| IP 地址隐私保护 | 将 IP 地址提供给 Google 使用与其声称的隐私保护目标相悖。尽管 Google 声称会通过 IP 保护功能对数据进行匿名化处理，但用户必须登录 Chrome 才能使用 IP 保护功能，因此 Google 仍会了解他们的身份。 | 登录的原因是为了防范欺诈和滥用行为，主要是为了对代理服务进行速率限制。 此外，为了在身份验证要求的背景下保护用户隐私，我们的令牌设计采用盲签名，这意味着在登录期间发出的令牌不同于在代理期间使用的令牌，因此发出的令牌日后无法与用户的 Google 身份相关联。这意味着，即使出于防欺诈原因而要求用户在无痕模式下进行身份验证，Google 也无法得知用户是谁。 |
| IP 地址隐私保护 | 使用 IP 地址是错误的做法。它们无法像 Cookie 一样从浏览器中删除，并且用户对其透明度的控制功能与 Cookie 不同。如果 Cookie 被弃用，业界将转而使用 IP 作为替代解决方案，将自保置于隐私保护之上。 | 作为一个平台，Chrome 旨在为用户提供有助于提升其网络浏览体验的功能。对于选择在无痕式窗口中浏览的 Chrome 用户，这意味着通过限制第三方环境中的 IP 地址信息的可用性，可提供增强型跨网站跟踪保护。 |
| 经过脱敏处理的网域列表 | 如何选择要列入经过脱敏处理的网域列表 (MDL) 的网域？ | Chrome 制定了一些标准来确定哪些网域应加入 MDL，从而在第三方环境中收到经过掩盖的 IP 地址。Google 与 Disconnect.me 建立了合作伙伴关系，后者是一家知名的互联网隐私保护领导者，也与其他网络浏览器合作。Chrome 将利用 Disconnect.me 来识别符合 Chrome 既定条件的网域。此外，Chrome 还开发了一种方法，用于识别广泛使用的 JavaScript 函数，这些函数可从稳定且高熵的 Web API 提供一致的输出，因此可用于构建高熵概率标识符。然后，当这些函数在第三方环境中的网站上加载时，系统会检测到这些函数，从而生成一个网域列表，其中包含提供具有这些特征的脚本的网域，这些脚本会成为 MDL 的一部分，因此会被代理。用于查找这些 API 滥用模式的检测流水线会考虑所有网域，包括 Google 自有网域。 |
| 欺诈防范 | 针对概率性公开令牌 (PRT) 的反馈：建议的 24 小时公开延迟时间和公开率会妨碍实时欺诈检测。申请延迟时间更短（1 小时延迟）和费率更高（至少两位数）。其他建议包括根据风险信号（VPN、自动化浏览器）启用差别费率，以及允许有针对性地显示特定令牌。 | 我们与之交流的大多数开发者都会向客户提供每小时报告，并会在一天内多次更新 IP 屏蔽名单。延迟时间越短，更新频率就越高。如果延迟时间少于一小时，则会在每小时统计数据中重新启用 IVT 衡量，但也可能会增加用户重新识别的可能性。我们愿意根据生态系统研究和利益相关方的反馈，探索缩短延迟期和更改公开率，并欢迎您点击此处提供更多反馈。 |
| 经过脱敏处理的网域列表 | 关于网域未用于广告用途，但已纳入 MDL 的问题。担心这可能会启用“IP 桥接”功能，以便根据 IP 地址创建个人资料。 | 我们深知，为基于列表的方法实施申诉流程非常重要。通过申诉，公司可以声称其在 MDL 中的网域不符合纳入条件，因此应予以移除，从而允许该网域在无痕模式下继续在第三方环境中接收用户的原始 IP 地址。 我们现已启动申诉流程，以便在 Chrome 稳定版中推出无痕模式 IP 保护功能之前，为网域所有者留出足够的时间来提出申诉并收到判定结果。 如需详细了解申诉流程，请点击此处。 |
| 经过脱敏处理的网域列表 | 反馈：发布商正在调查其合作伙伴被纳入 MDL 的影响。他们对 IP 保护说明中关于地理位置信息的规定感到放心。 | Chrome 深知支持基于地理位置的用例的重要性。代理将分配代表用户粗略位置（包括国家/地区）的 IP 地址。如需了解详情，请参阅IP 地址地理定位说明。 |
| 经过脱敏处理的网域列表 | 关于 MDL 的问题：国家/地区级定位功能是否仍可用。 | Chrome 深知支持基于地理位置的用例的重要性。代理将分配代表用户粗略位置（包括国家/地区）的 IP 地址。如需了解详情，请参阅IP 地址地理定位说明。 |
| 欺诈检测 | 担心 IP 保护功能对欺诈检测系统的影响。用户会看到代理 IP 还是标头？对于给定用途，SSP 和 DSP 会看到相同的代理 IP 地址吗？不一致可能会影响欺诈检测和 OpenRTB。 | 如果用户在启用 IP 地址保护功能的情况下浏览无痕模式，并向 MDL 上的网域发出请求，则会收到根据定义的地理位置 Feed 提供的代理 IP 地址。组织可以请求将 PRT 作为代理流量的附加标头传递，在这种情况下，系统会在延迟期过后显示一小部分原始 IP 地址。我们怀疑许多 SSP 会将其服务器端出价请求中的代理 IP 地址传递给其需求方合作伙伴，但无法保证胜出的 DSP 在展示时会看到相同的代理 IP 地址。 |
| 欺诈检测 | 关于 IP 地理位置文件的更新频率、报告欺诈行为和 PRT 详细信息的更新时间，以及广告技术平台应如何检测欺诈活动的问题。 | “PRT 说明”和代理 IP 地址及其对应的地理区域列表现已发布。我们建议您定期查看此文件，了解最新动态和变化，因为 IP 地址会随时间推移而轮替。我们将在该功能发布前公布用于举报滥用行为的公开电子邮件地址。 |
| 地理定位 | 请求提供用于代理的 IP 地址的公开列表。 | 如需获取用于 IP 保护功能的 IP 地址与大致位置的映射文件，请点击此处。请注意，此文件会定期更新。 |
| API 应用 | 断言 IP 地址保护功能似乎默认处于开启状态，并且用户无法选择停用。 | IP 保护功能将面向 Android 和桌面平台上使用 Chrome 无痕模式的用户提供。用户将能够停用 IP 地址保护功能。对于企业管理的 Chrome 版本，可以启用 IP 保护功能，但该功能默认处于关闭状态。 |
| API 应用 | 询问是否有实验性标志可用于在 Chrome Canary 和 Beta 版中启用和测试 IP 保护功能。 | 目前，我们没有可用于测试完整版知识产权保护功能的实验标志。我们正在开展的功能实验仅代理指向 Google 网域的流量。 |
| IP 地址隐私保护 | 当浏览器进入无痕模式时，3PC 提示设置如何运作？ | 无痕模式下默认会屏蔽 3PC。 |
| 无痕模式 | 想了解在用户未登录 Chrome 的情况下，IP 保护功能是否会在无痕模式下运行。 | 如果用户在启动无痕模式之前未登录 Chrome，IP 保护功能将处于停用状态。之所以这样做，是为了防范欺诈和滥用行为，即对代理服务进行速率限制。IP 保护功能将使用客户端身份验证来限制不法分子利用代理来放大对 MDL 上服务的攻击。因此，只有在打开新的无痕式窗口之前使用其在 Chrome 浏览器中登录的 Google 账号进行身份验证的用户，才能使用 IP 保护功能。 |
| 无痕模式 | 在发布之前评估 IP 保护功能影响的请求，包括： (1) 提议使用浏览器状态标志或汇总 API 报告来量化无痕模式的使用情况； (2) 在启用该功能之前发送 IP 保护标头一段时间；以及 (3) 向一小部分已知流量分发该功能以进行推断。 |
我们理解生态系统希望能够了解和衡量知识产权保护的规模和影响。不过，Chrome 会努力确保用户选择在无痕模式下浏览时能获得私密体验。Chrome 不会公开用于检测用户是否在无痕模式下浏览的方法，并且已采取措施来限制可能泄露用户浏览模式的其他信号。 我们正在考虑如何在不影响浏览无痕模式的用户隐私的情况下，协助进行此类测试，并欢迎生态系统提供更多反馈。 |
反弹跟踪缓解措施
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 合规性 | Google 不愿授权使用符合数据保护法律的跳出率跟踪缓解措施 (BTM) 技术，这没有法律依据，也使 Privacy Sandbox 申诉流程毫无意义。 | 正如我们在之前的反馈报告中所述，合规性状态与 BTM 的应用无关，Google 不会就实施 BTM 的合规性做出任何决定。与其他 Chrome 隐私保护措施一样，BTM 的重点是进一步加强用户对其数据是否共享以及如何共享的控制。 CMA 的第二/第三季度报告中提及的第三方管理申诉流程仅适用于 Google 决定将个别公司列入或排除名单的地区。 |
| 法规遵从 | 讨论浏览器如何在 GDPR 的背景下确保遵守用户已同意的法律操作，重点介绍浏览器可能会抑制用户明确同意的操作（例如重定向或 Cookie 设置），从而导致法律意见征求和浏览器隐私设置之间出现冲突的情况。 | 浏览器无法了解用户与网站之间的关系性质。此外，对于当前的 BTM 行为，已经存在一些权宜解决方法，可让用户明确同意跟踪从给定网站的跳出情况。 如需详细了解合规性，请参阅我们的与隐私权相关的合规性常见问题解答。 |
| 双重用途网站 | 想确认一下，从 WebView 或应用到网站 (Chrome) 的转换是否会被视为 BTM 下的“双重用途网站”？ | 浏览器无法了解跳出链是通过 WebView 还是应用的转换开始的。 因此，BTM 不会对这些流程进行任何特殊处理。而是将流程解读为从“about:blank”开始的跨网站跳出，并继续执行标准行为。 |
增强跨网站隐私边界
Related Website Set（以前称为 First-Party Set）
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| API 应用 | 担心将 RWS 与 IP 保护功能结合使用可能会被滥用。向 RWS 组中的组织公开 IP 地址可能会促使组织加入多个 RWS 组，以便访问可携带 IP 地址数据，从而跟踪无痕式浏览用户。 | 系统会通过自动验证来强制执行对关联网站、服务网站和整个集合的集合要求，从而减少尝试加入多个集合的任何潜在动机。 若要通过 IP 地址联接各组的用户活动，则需要在组中添加 MDL 网域，这需要组所有者与网域所有者之间进行协调。与 MDL 网域协调的单个网站（即不涉及 RWS）也存在同样的风险。 您可以点击此处，详细了解我们对此问题的回复。 |
Fenced Frames API
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 原生广告 | 有反馈指出，按照目前的设计，Fenced Frames 与其原生广告业务模式不兼容，后者要求广告能够灵活地适应周围内容。 | 我们将继续评估生态系统需求和当前的 Fenced Frames 产品。无论如何，如前所述，最晚在 2026 年必须使用围栏帧。 |
Shared Storage API
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| API bug | 报告当 Shared Storage API 的预算机制阻止 select网址 操作运行时，Chrome 会记录错误，即使这是预期行为也是如此。请求 Chrome 将日志记录级别从“错误”降级为“警告”或“信息”，因为调用方无法根据该错误采取行动。 | 此变更已实施，并包含在自 2025 年 3 月 4 日起推出的 Chrome M134 中。 |
CHIPS
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| API 文档 | 需要澄清分区 Cookie 与 SameSite=Lax/Strict Cookie 相比所提供的安全保护。建议在文档中明确说明，分区 Cookie 在防范 XSS 和 CSRF 攻击方面提供的保护级别不如 SameSite=Lax/Strict Cookie。 | 我们将更新说明文档和规范，以阐明分区 Cookie 提供的语义和保护措施。 |
FedCM
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 界面和安全 | 反馈：FedCM 界面与 Google 之前的一键式登录过于相似，由于缺少被动呈现跟踪，因此很难量化 FedCM 的效果，建议使用更强硬的 PKCE 文档语言。 | 我们正在积极与利益相关方互动，以解决他们的反馈。我们正在讨论的领域包括如何向 IdP 提供更好的指标，以便他们跟踪 FedCM 的效果，以及可能的增强功能，以便针对订阅用例解决 FedCM 的新用例。 |
| API 应用 | 当用户刷新页面并调用 navigator.credentials.get 进行登录时，系统会显示一个弹出式窗口，要求用户点击以继续，这会导致延迟，影响用户体验。依赖方 (RP) 能否缓存 navigator.credentials.get 返回的令牌以改善用户体验？ | RP 可以使用自己的 Cookie 来存储令牌。然后，RP 可以在调用 navigator.credentials.get 之前检查自己的 Cookie，以确定用户是否已登录。如需了解详情，请点击此处。 |
| 选择多身份提供方 | 浏览器如何在 FedCM 中显示多个身份提供方 (IdP) 的登录选项？ | 开发者文档中提供了有关如何显示多个 IdP 的信息。利益相关方可以在 chrome://flags 中启用 fedcm-multi-idp 标志，以便试用此功能。 |
| 浏览器和 IdP | 浏览器（例如 Chrome）能否本身充当 IdP？浏览器可以使用其存储的账号和个人资料数据作为可信的身份验证来源。 | 由于浏览器可以被修改（例如通过扩展程序），因此如果没有额外的服务器端验证，就无法信任浏览器直接声明的电子邮件验证。因此，不建议采用完全基于客户端的解决方案。 我们已在此处详细讨论了此问题。 |
| API 规范 | 讨论了 IdentityCredential.disconnect() 算法的参数应为必需参数还是可选参数。 | 该问题现已解决。如需了解详情，请点击此处。 |
| API 安全 | 如果 RP 存在 XSS 漏洞，则 FedCM 登录流程中存在令牌泄露问题。攻击者可以在恶意代码中执行 navigator.credentials.get 以获取令牌。 | FedCM 不会产生新的 XSS 风险；这些风险是 Web 应用和现有身份验证协议固有的。为了降低这些风险，RP 应验证 ID 令牌中的 aud 声明，并且仅接受在其自己的来源中签发的断言。如此处所述，目前有广泛认可的最佳实践可用于保护此令牌交换，这些最佳实践可与 FedCM 搭配使用。 此外，Storage Access API 可与 FedCM 搭配使用，并且在先前有 FedCM 调用时，系统会自动授予 Storage Access API 调用权限。这应该会启用 GitHub 问题中所述的嵌入式重定向流程。 |
| API 规范 | client_metadata_endpoint 是 FedCM 配置端点响应中的必填字段。空对象是有效响应，Chromium 会静默忽略 404 响应，这表明在实践中，端点被视为可选。 | 我们同意可以更改规范以反映这一点，并将 client_metadata_endpoint 设为可选字段。 |
| API 应用 | 由于浏览器控制的界面无法通过 DOM 访问，因此担心难以测试 FedCM 实现。 | 我们支持使用浏览器自动化 API 进行回归测试，这可能会解决这些问题。如需了解这些 API，请参阅此处。 |
| API 规范 | login_url 参数是配置端点响应的必需部分，但规范的 3.2 部分未对其进行记录。 | 我们已向文档提交更新，以在第 3.2 节中添加 login_url 参数。 |
| API 规范 | 对 FedCM 中潜在跟踪矢量的疑虑。IdP 可以将 ID 作为路径参数插入到配置端点响应中指定的端点（accounts_endpoint、client_metadata_endpoint），并使用这些 ID 来关联账号和客户端元数据请求。 | 虽然我们没有证据表明身份提供方会将 ID 插入这些端点，但我们正在积极考虑采取缓解措施来解决此问题（详见此处）。 |
打击垃圾内容和欺诈行为
Private State Tokens API（及其他 API）
本季度未收到任何反馈。