2025 年第 2 季度的季度报告，总结了收到的有关 Privacy Sandbox 提案的生态反馈以及 Chrome 的回应。
Google 根据第 12 条、第 17(c)(ii) 条和第 32(a) 条的规定，履行对英国竞争和市场管理局(CMA) 的承诺，特此编制本季度报告。本报告涵盖了以下内容：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
- IP 地址
- openRTB
- 实时出价
- 加时赛
- 源试用
- PA API
- Protected Audience API（以前称为 FLEDGE）
- PatCG
- Private Advertising Technology Community Group
- RP
- 依赖方
- RWS
- Related Website Set（以前称为 First-Party Set）
- SSP
- 供应方平台
- UA
- 用户代理字符串
- UA-CH
- 用户代理客户端提示
- W3C
- 万维网联盟
- WIPB
- 故意视而不见
一般性反馈，不涉及特定 API/技术
| 反馈主题 | 摘要 | Chrome Response |
|---|---|---|
| Privacy Sandbox 的未来 | 鉴于我们已宣布不会继续引入 3PC 的用户选择机制，在存在 3PC 的情况下，有些 API 比其他 API 更有用，而有些 API 需要改进才能发挥作用。除了 Privacy Sandbox API 之外，Chrome 还有其他潜在的投资领域。 | 感谢您的反馈。鉴于 Google 于 2025 年 4 月宣布将继续沿用当前在 Chrome 中为用户提供第三方 Cookie 选择的方式，我们将继续与利益相关者沟通，评估 Privacy Sandbox API 未来可发挥的作用，并探索未来可投资的新领域。 |
| Privacy Sandbox | 一些生态系统参与者对 Google 宣布不再继续引入 3PC 用户选择机制感到失望，但他们对所完成的工作感到自豪，他们了解 Privacy Sandbox 中的技术挑战，并强调了与 Chrome 之间的协作工作关系以及市场测试补助金的实用价值。 | 感谢您的反馈。我们同意 Chrome 可以也应该与开发者合作，共同开发相关技术，在提高在线隐私保护水平的同时，维护依靠广告支撑的互联网。 |
| 浏览器数据共享 | 浏览器介导的数据共享是一项极具吸引力的技术，有望解决市场效率低下和信任问题。浏览器作为第三方执行上下文，在协作方面具有价值。 | 感谢您的反馈。我们同意 Chrome 可以也应该发挥作用，帮助开发者创建能够增强协作开发者与用户之间信任的技术。 |
| Chrome 流量 | Chrome 上无 Cookie 流量的占比是多少？无痕模式流量的占比是多少？ | 正如 CMA 在其“Notice of intention to release commitments”（有意发布承诺的通知）中所述，无痕模式仅影响极小一部分浏览活动。在英国和 EEA 中，Chrome 无痕模式在搭载 Android 操作系统的设备上所占的浏览次数比例不到 10%；在搭载 Windows 操作系统的设备上所占的浏览次数比例不到 10%。
这些指标仅指英国和欧洲经济区 (EEA) 基于 Chromium 的 Chrome 中的导航。 我们不会分享有关阻止 3PC 的浏览器的数据。 开发者可以使用 Storage Access Headers 确定何时对 Cookie 进行分区，并相应地使用可用的缓解措施。 |
| Chrome 测试版标签 | Chrome 针对 2024 年为测试启用的 1% 无 Cookie 流量有何计划？ | 我们目前没有计划可以分享，但我们打算在计划确定后立即公开分享。 |
| Chrome 测试 | 当前的测试标签设置是否包含以下场景的处理：同时提供 3PC 和启用 Privacy Sandbox API？ | 当前的测试标签设置包含针对第三方 Cookie 和 Privacy Sandbox API 的处理（以模式 A 的形式）。 |
| Privacy Sandbox | 部分广告客户认为 Privacy Sandbox API 过于复杂，并且由于之前的准备工作而感到厌倦，他们质疑如何量化早期采用者的优势，并希望了解再营销、潜在客户发掘和效果衡量方面的知识。 | 感谢您的反馈，我们理解您对技术复杂性和准备练习的看法。 在了解当前 Privacy Sandbox 技术的性能方面，我们的测试结果表明，生态系统参与是了解 Privacy Sandbox 解决方案性能的关键因素。小规模测试无法重现大规模使用这些技术时的市场动态和激励措施。 |
注册和证明
本季度未收到任何反馈。
展示相关内容和广告
主题
| 反馈主题 | 摘要 | Chrome Response |
|---|---|---|
| Topics API 增强功能在性能和实用性方面的兴趣 | 买方利益相关者的反馈表明，Topics API 是一项有价值的信号，可为广告客户广告系列提供与 3PC 受众群相比具有竞争力的每千次展示费用 (CPM) 数据。一些发布商认为 Topics API 的信号比标准开放式网络信号质量更高。鉴于用户对 Topics API 实用性的反馈，利益相关方正在请求增强功能，例如提高分类保真度和一致性，以及扩大发布商控制范围，以推动更广泛的采用。 | Google 于 2025 年 4 月宣布，目前在 Chrome 中为用户提供第三方 Cookie 选择的方案将继续沿用，因此我们正在考虑这些反馈，以便评估 Privacy Sandbox API 今后将发挥的作用。 |
对不同类型 的利益相关方的实用性 |
由于 Topics 分类器目前仅使用网页主机名来定义相应的主题，因此内容多样的大型网站会贡献通用主题，而小型网站会贡献具有更高广告价值的利基主题。 | 我们的回答与前几个季度类似： 与 3PC 一样，不同网站提供的信息价值存在差异。小众兴趣网站的价值贡献并不稳定：并非所有小众兴趣网站都具有商业价值的内容，因此贡献的价值较小。 以下是可从 Topics API 中受益的网站。我们曾考虑过按网页级而非网站级进行分类，但这种分类方式存在许多严重的隐私和安全问题。 |
| 主题分类法不够精细 | 对于在单个网域内包含各种内容版块的新闻发布商，Topics API 提供的粒度不够精细，可能会限制该 API 在广告定位方面的实用性。 | 鉴于 Google 于 2025 年 4 月宣布将继续沿用当前在 Chrome 中为用户提供第三方 Cookie 选择的方案，我们在评估 Privacy Sandbox API 今后将发挥的作用时，会考虑这些反馈。 |
| 分类器改进 | 允许发布商向 Chrome 授予权限，以根据网页内容（例如，头部、正文）对主题进行分类。 | 我们正在考虑此请求，欢迎您点击此处提供更多反馈。 |
| 政策 | 请求澄清有关将 Topics API 与 3PC 信息结合使用的指南。 | 同时使用 Topics API 和 3PC 没有任何困难，因为 Topics API 提供的功能是 3PC 的一个子集。 |
| Observe-Browse-Topics 标头 | 请求澄清 Observe-Browse-Topics 标头的实现，特别是持续返回该标头是否会导致问题。 | 持续返回 Observe-Browse-Topics: ?1 标头不会导致任何技术问题。浏览器会高效处理此信号，只需记录网页访问符合主题计算条件，而不会导致重复或错误。虽然并非每个网页都需要发送此标头，但将其作为标准标头在所有顶级文档中发送是一种有效且简单的策略。 |
| 分类类别 | 请求使用新主题更新最新的 Topics 分类。 | 我们正在考虑此请求，并欢迎相关生态系统在此处提供更多反馈。 |
| Null 值 | 请求就如何提升 Topics API 的性能以及了解 null 响应背后的原因（例如过滤或敏感度）提供指导。 | 为清楚起见，来自 Topics API 的 null 或空响应是一项预期的隐私保护功能，而不是错误。null 响应可能是由以下原因造成的：• 隐私权规则：5% 的随机 null 几率，或者是因为您的脚本未“观察”到用户在与相应主题相关的网站上的活动。• 用户状态：浏览记录不足、使用无痕模式，或者用户已在 Chrome 的广告隐私权设置中选择停用。 • 技术错误：发布商网站必须发送 Observe-Browse-Topics: ?1 标头，并且任何调用 iframe 都需要 allow="Browse-topics" 权限。如需进行调查，请使用 chrome://topics-internals 调试页面查看浏览器计算了哪些主题以及原因。虽然隐私权功能会阻止实现 100% 的填充率，但您可以通过以下方式来提高效果： • 与发布商合作：确保合作伙伴在其网站上正确发送 Observe-Browse-Topics: ?1 标头。• 验证代码：如果您使用 iframe，请确认 allow="Browse-topics" 政策已到位。 |
Protected Audience API
| 反馈主题 | 摘要 | Chrome Response |
|---|---|---|
| PA API 因成本和复杂性而难以普及 | 采用者正在降低 Protected Audience API (PA API) 集成的优先级或回滚这些集成，理由是运营成本高、广告客户需求不足以及广告交易平台的广告资源量低。 部分反馈意见中提到了 PA API 的潜在优势，例如能够提供持久的受众群体，以及由于匹配率高而实现出色的覆盖面。 |
鉴于 Google 于 2025 年 4 月宣布将继续沿用当前在 Chrome 中为用户提供第三方 Cookie 选择的方案，我们在评估 Privacy Sandbox API 今后将发挥的作用时，会考虑这些反馈。 |
| 跨平台功能 | 应支持跨平台功能，以便利用 PA API 在各个平台之间实现更强大的再定位和受众群体定位功能。Google 应允许在原生环境或 WebView 中投放广告时访问 Chrome 中注册的兴趣群体 (IG)，并且 Android 中注册的兴趣群体应可在 Chrome 竞价中使用。 | 鉴于 Google 于 2025 年 4 月宣布将继续沿用当前在 Chrome 中为用户提供第三方 Cookie 选择的方案，我们在评估 Privacy Sandbox API 今后将发挥的作用时，会考虑这些反馈。 |
| directFromSellerSignals | 通过限制情境竞价中可用的信息量，竞价参与者始终会通过 Google 的广告服务器进行路由。发布商必须先调用所有广告交易平台合作伙伴，然后调用 Google Ad Manager (GAM) 来运行情境竞价，最后允许 GAM 调用 IG 竞价。如果不实时了解情境竞价的结果，任何竞争者都无法公平地协调顶级决策。 PA API 中的 directFromSellerSignals 功能可能在竞价信息方面缺乏透明度，从而可能妨碍访问必要数据的能力。Google 应移除 directFromSellerSignals 或对其进行更新，使其无法用于隐藏广告服务器的竞价结算价。例如，可以通过 Chrome 传递情境价格，该价格以透明、不可变、已签名的字段形式呈现，所有竞价参与者（以及发布商）都可以访问和验证。 |
我们的回答与前几个季度保持不变： Chrome 回答： 除非卖家从自己的 iframe 中调用 runAdAuction()，否则传递到 runAdAuction() 中的信息不会被视为来自卖家。在多卖方竞价中，所有卖方都无法创建调用 runAdAuction() 的框架。directFromSellerSignals 通过从卖方来源加载的子资源 bundle 加载内容来解决此问题。这样可确保无法操纵从卖方竞价配置传递到竞价中的信息的真实性和完整性。如果发布商想要使用 PA API 了解其技术提供商传递到 PA 竞价中的任何信息，可以向这些技术提供商提出此功能要求。 Google Ad Manager 回应： 多年来，我们一直非常重视竞价公平性，并承诺不会在任何买方参与竞价之前，向其透露发布商任何无保证广告来源（包括无保证订单项价格）的价格，我们后来在对法国竞争管理局的承诺中再次确认了这一点。 对于 Protected Audience 竞价，我们打算通过利用 directFromSellerSignals 来履行承诺，并且在多卖方竞价中，在竞价结束之前不会与任何其他竞价参与者分享任何竞价参与者的出价。需要明确的是，我们也不会与自己的组件竞价分享情境竞价的价格，如此更新中所述。 |
| 报告 | 请求添加分析/报告实体以实现集中式报告。 | 我们正在此处讨论此请求，欢迎您提供更多反馈。 |
| buyerReportingId 的 k-匿名性 | 能够根据“buyerReportingId”的 k-匿名性舍弃出价，以便于甄选受众群体并履行与第三方数据提供商相关的报告义务。 | 鉴于 Google 于 2025 年 4 月宣布将继续沿用当前在 Chrome 中为用户提供第三方 Cookie 选择的方案，我们在评估 Privacy Sandbox API 今后将发挥的作用时，会考虑这些反馈。 |
| 改进了 generateBid 脚本中的调试功能 | 请求一种机制，以便快速识别 generateBid 脚本中进程失败的特定阶段或“断点”。 | 我们知道，您希望将实时衡量用作设备端竞价的中断点设置机制。我们正在考虑这些反馈，并评估 Privacy Sandbox API 今后将发挥的作用，因为 Google 已于 2025 年 4 月宣布，目前在 Chrome 中为用户提供第三方 Cookie 选择的方案将继续沿用。 |
| 用于监控 runAdAuction 状态的事件监听器 | 提议向 PA API 的 navigator.runAdAuction 函数添加事件监听器支持，以改进对广告竞价生命周期的监控。 | 我们正在评估此请求，并欢迎相关生态系统在此处提供更多反馈。 |
| API 应用 | 请求澄清在没有 3PC 的情况下，PA API 和 Attribution Reporting API (ARA) 如何支持 Web 广告用例，特别是对于已选择停用 3PC 但未选择停用 Privacy Sandbox API 的用户，以及涉及 Cookie 同步失败和 WebView 的场景？ | 鉴于 Google 于 2025 年 4 月宣布将继续沿用当前在 Chrome 中为用户提供第三方 Cookie 选择的方案，我们在评估 Privacy Sandbox API 今后将发挥的作用时，会考虑这些反馈。 |
| 延迟时间 | 与 PA API 相关的延迟时间可能会阻碍采用，因为如果延迟时间过长，发布商可能会选择停用 PA API。 | 在过去几个季度中，我们对设备端延迟进行了多项改进。根据需要继续构建和扩缩出价和竞价 (B&A) 服务。我们更新了延迟时间最佳实践指南，其中包含有关如何利用这些功能的更多信息。我们还在探索开发新的延迟改进功能，您可点击此处了解其中一些功能。 |
| B&A 中的日志记录行为（测试与生产） | 澄清了 B&A 服务在测试模式和生产模式下的日志记录行为差异。具体来说，包括云日志的可用性以及生产模式对日志记录的影响。 | 首先，务必区分 prod 与 non_prod build 和单独的 TEST_MODE 参数，后者仅启用硬编码的测试加密密钥。以下说明重点介绍 build 类型。 在 non_prod build 中，B&A 服务器具有可配置的日志记录详细程度。这些详细日志会写入标准 stdout/stderr 流。在 Google Cloud 上，这些信息可通过原生日志记录界面访问；在 Amazon Web Services 上，这些信息可在附加的控制台日志中找到。 对于正式版 build，日志记录行为会受到更多限制。详细程度级别是固定的，无法更改。虽然一些非隐私相关日志（例如服务器启动消息和大多数崩溃错误）仍会输出到 stdout/stderr，但无法通过此渠道获取特定于请求的日志。来自正式版 build 的唯一按请求日志是包含已同意的调试令牌的请求的日志，这些日志仅通过 OpenTelemetry 导出。请谨慎使用已征得用户同意的调试功能，因为大量流量可能会降低服务器性能并导致健康检查失败。 关于指标，所有指标均通过 OpenTelemetry 导出。非隐私敏感型指标始终按原样导出，不会进行任何“加噪”处理。相反，从以生产模式运行的服务器导出隐私敏感型指标时，这些指标始终会添加噪声。具体的遥测配置决定了这些涉及隐私的指标是以加噪、未加噪还是同时以这两种方式导出。 |
| 在可信出价信号中添加了完整网页路径，以确保品牌安全 | 请求更新 PA API，以便在针对 trustedBiddingSignals 的提取请求中包含顶级网页的完整网址路径（除了主机名之外）。 主要用例是实现更精细的品牌保障控制。广告客户通常需要阻止广告在网域的特定版块（例如 news-site.com/politics）中展示，但对整个网域没有意见。由于这些屏蔽列表可能包含数百万个条目，因此必须在服务器端进行评估。当前规范仅发送主机名，这使得 trustedBiddingSignals 服务器无法执行此必要的路径级评估，从而限制了品牌安全功能。 |
我们目前正在此处讨论此问题，之前已进行过多次广泛的讨论，您可点击此处查看，欢迎您提供更多反馈。 不过，我们想澄清一下，只有当 trustedBiddingSignals 获取请求发送到在可信执行环境 (TEE) 内运行的服务器时，我们才会考虑添加此信息。 |
受保护的竞价（出价和竞价服务）
| 反馈主题 | 摘要 | Chrome Response |
|---|---|---|
| 测试可用性 | 有关在 Chrome 和 B&A 环境中测试键值 (KV) v2 的可用性的信息。 | KV v2 同时适用于 B&A 和 Chrome。如需更多指导，请点击此处。 |
| KV 服务器实现 | 请求就 KV 服务器的使用情况提供说明，特别是关于以下方面：将广告素材呈现网址映射到请求数据；SSP 和 DSP 之间在呈现网址中定义参数时是否需要协调；以及是否有文档概述了 KV 模式下所需的协调和数据存储。 | KV 服务使用 render网址 作为键。如果网址是新网址，则会存储该网址。如果存在，则返回其值以用于 scoreAd。返回格式取决于设置：“自带服务器”(BYOS) 允许任何值，而可信 KV 服务需要用户定义的函数。 虽然并非总是必需，但与 DSP 协调对于宏替换（例如，${AD_WIDTH})，从而实现动态广告自定义和验证。 我们建议先通过一个 DSP 进行简单的测试，以确定必要的协调程度。我们目前也在更新 KV 文档，并会在更新完成后公开分享。 |
| B&A 的 BYOS | 为什么 B&A 不提供类似于 KV 的 BYOS 模式？ | B&A 需要 TEE，因此不支持 BYOS 模型，因为它会处理高度敏感的数据组合，需要强制执行隐私保护机制，如下所述。 对于 DSP： B&A 会处理发布商情境（如果卖家通过 auctionSignals / perBuyerSignals 明确发送，则可能是完整网址），并将其与详细的用户 IG 数据相结合。TEE 对于安全处理这种组合并防止潜在的用户重新识别至关重要。在 KV BYOS 中，无法发送完整网址。 对于 SSP： 即使只是知道竞价中参与的 IG（及其 DSP 所有者）的组合，也可以生成识别签名。干扰解决方案正是在这种情况下发挥作用的，该解决方案需要使用 TEE。 因此，为了安全地处理这些组合的敏感信号并强制执行隐私权机制，必须使用受控的经过认证的 TEE 环境。 |
衡量数字广告的效果
Attribution Reporting（和其他 API）
| 反馈主题 | 摘要 | Chrome Response |
|---|---|---|
| 噪音政策 | 对于部分市场参与者而言，ARA 的实施很有价值，Google 应继续维护事件级报告。在 ARA 和 3PC 均可用的情况下，Google 应考虑放宽噪声政策。效果广告客户正越来越多地使用 ARA 灵活事件的当前“价值”字段实现，而放宽噪声政策有助于减少延迟和不准确的报告。 | 此机制是 ARA 设计的基础部分，旨在通过防止跟踪个人来保护用户隐私。Google 于 2025 年 4 月宣布，Chrome 中目前向用户提供第三方 Cookie 选择的方式将保持不变，因此我们会考虑有关噪声导致报告问题的反馈，同时继续评估 Privacy Sandbox API 未来将发挥的作用，以及任何潜在的未来增强功能。 |
| 路线图和长期支持 | 请求提供 ARA 的产品路线图，并确认长期投资和支持，因为 Google 宣布不会继续为 3PC 引入用户选择机制。 | Privacy Sandbox 团队正在与生态系统互动，以了解 Privacy Sandbox API 未来将发挥的作用，并评估未来的任何投资。 |
| 跨环境衡量（应用到网站） | 请求提供一种解决方案，该方案涉及利用 ARA 来促进跨环境衡量，从而提供更清晰、更可靠的数据流，并增强跨不同平台关联用户互动的能力。 | ARA 已支持同一设备上的应用到网站。如需详细了解跨应用和跨网站衡量解决方案，请点击此处 和此处。 |
| 跨浏览器归因 | 采用统一的跨浏览器 ARA 方法将显著提高在开放网络上衡量投资回报率的能力，并在潜在的监管变化之前提供稳定的替代方案。Chrome 应该与 Safari 团队合作，共同开发此类解决方案。 | 我们已在 W3C 的 PATCG 和 PATWG 群组中与其他浏览器供应商探讨互操作性 API。请注意，这项工作尚处于初步阶段，利益相关方可点击此处查看我们的进展情况。 |
| 跨设备/线下衡量 | 无法在 ARA 中支持跨设备转化衡量是一项重大限制。衡量线上到线下的转化也至关重要，浏览器可以与衡量服务提供商协作，发挥相应的作用。 | 鉴于 Google 于 2025 年 4 月宣布将继续沿用当前在 Chrome 中为用户提供第三方 Cookie 选择的方案，我们在评估 Privacy Sandbox API 今后将发挥的作用时，会考虑这些反馈。 |
| 多接触点归因 | 请求允许广告客户使用 Privacy Sandbox 数据作为无偏的“评估依据”来验证和校准其现有的归因模型。为此，您可以将 ARA 的浏览器提供的数据用作可靠的校准信号，从而创建可靠的基准。 | 鉴于 Google 于 2025 年 4 月宣布将继续沿用当前在 Chrome 中为用户提供第三方 Cookie 选择的方案，我们在评估 Privacy Sandbox API 今后将发挥的作用时，会考虑这些反馈。 |
| 无需征得用户同意/选择不参与的流量衡量 | 注重隐私保护的解决方案（例如 Interoperable Private Attribution）可实现对无需征得用户同意的流量进行效果衡量。这样一来，即使是选择不接受跟踪的用户，其数据也会纳入其中，从而更全面地了解广告系列的效果，并弥补因征得用户同意的要求而造成的衡量方面的主要缺口。 | 鉴于 Google 于 2025 年 4 月宣布将继续沿用当前在 Chrome 中为用户提供第三方 Cookie 选择的方案，我们在评估 Privacy Sandbox API 今后将发挥的作用时，会考虑这些反馈。 |
| 服务器到服务器归因 | 请求允许具有复杂服务器端基础架构的广告技术以更灵活的方式与 ARA 集成，以适应难以仅在客户端管理的用例，同时维护用户隐私。 | 鉴于 Google 于 2025 年 4 月宣布将继续沿用当前在 Chrome 中为用户提供第三方 Cookie 选择的方案，我们在评估 Privacy Sandbox API 今后将发挥的作用时，会考虑这些反馈。 |
| 多网域注册 | 寻求有关使用 ARA 注册多个网域时的限制和注意事项的说明，特别是关于汇总服务和跨源归因的说明。 | 在多个网域中使用 ARA 时，存在以下主要限制： • 归因范围限定为单个来源。您无法将一个网域中的点击与另一个网域中的转化进行匹配。来源和触发器的归因都沙盒化到同一来源。 • 汇总服务不支持多源批处理。来自不同来源的报告必须单独进行批处理和处理。我们正在探索未来支持此功能的方法。 简而言之，虽然可以在一个实体下注册多个网域，但目前所有 ARA 功能（例如归因和汇总）都必须按来源进行处理。 |
汇总服务
本季度未收到任何反馈。
Private Aggregation API
| 反馈主题 | 摘要 | Chrome Response |
|---|---|---|
| 限值和噪声等级 | 有关 Private Aggregation API 中聚合键大小和聚合值限制的问题。 | 选择的聚合键和值大小可实现高精细度，同时限制网络和存储费用。我们还建议在分配密钥时使用哈希处理，以最大限度地提高灵活性。 虽然还有其他因素可以保护用户数据，但添加噪声是 Private Aggregation API 隐私保护的重要组成部分。 我们会考虑您的反馈，并继续评估合适的参数选择，同时考虑到 Privacy Sandbox API 今后将发挥的作用。这是因为 Google 在 2025 年 4 月宣布，目前在 Chrome 中向用户提供第三方 Cookie 选择的方案将继续沿用。 |
| 隐私与实用性 | Privacy Sandbox 的方法可能会优先考虑隐私保护，而不是实用性，从而可能阻碍采用。建议在征得用户同意后，允许更精细的数据共享，以改进效果衡量和广告个性化。 | 选择的聚合键和值大小可实现高精细度，同时限制网络和存储费用。我们还建议在分配密钥时使用哈希处理，以最大限度地提高灵活性。 我们正在考虑这些反馈，并评估 Privacy Sandbox API 今后将发挥的作用，因为 Google 已于 2025 年 4 月宣布，目前在 Chrome 中为用户提供第三方 Cookie 选择的方案将继续沿用。 |
限制隐蔽跟踪
用户代理缩减/用户代理客户端提示
| 反馈主题 | 摘要 | Chrome Response |
|---|---|---|
| 垃圾内容检测 | 如果使用垃圾内容检测系统的网站发出的第一个请求依赖于客户端提示，则跟踪或检测系统可能无法识别或正确分类该请求。 | 依赖于在首次请求时访问 User-Agent Client Hints (UA-CH) 的用例应使用关键客户端提示。 |
| API 反馈 | 考虑弃用 Sec-CH-USA-Wow64，因为它已不再适用于现代 Web。 | 我们正在考虑此请求，欢迎您点击此处提供更多反馈。我们还收到了反馈，认为将 wow64 扩展到 Windows 之外会很有用。 |
IP 保护（原 Gnatcatcher）
| 反馈主题 | 摘要 | Chrome Response |
|---|---|---|
| 控件 | 请求为网站提供 IP 地址保护切换开关，以便在无痕模式之外有选择地使用。 | 感谢您的反馈，欢迎点击此处针对此问题提供更多意见。 |
| 不当行为 | 如果概率性披露令牌 (PRT) 的结果为 NULL 值，那么当警方要求披露 IP 地址以调查平台不当行为时，是否会妨碍识别违规者？ | 如果某个网域仅用于检测欺诈和滥用行为，则该网域可能未包含在屏蔽网域列表 (MDL) 中，因此不受 IP 保护的影响。因此，这些网域不需要 PRT。 如果网域包含在 MDL 中，PRT 目前是了解代理请求的原始 IP 地址的唯一方式。由于 PRT 专门用于支持汇总分析，而不是个人身份识别，因此在大多数情况下，PRT 不会包含 IP 地址。我们预计，在上述场景中，此功能的影响有限，因为 IP 保护仅在第三方情境中适用，这意味着发布商将继续接收第一方互动（例如用户访问在线平台的网站）的未代理 IP 地址。 |
| 欺诈防护 | Google 针对 IP 保护采取了哪些具体的反欺诈措施，包括对代理访问和身份验证令牌发放进行速率限制的详细信息，以及 PRT 的具体使用情形是什么？ | 我们确认，IP 保护中的速率限制和身份验证令牌旨在防止漫游器通过过度访问代理来实施广告欺诈，如反欺诈和反垃圾内容策略中所述。有关 PRT 的更多使用情形，请参阅 PRT 说明文档（点击此处）。 |
| 无痕模式 | 无痕模式下的 IP 保护功能是否仍计划在第 3 季度推出？ | 目前，在无痕模式下启动 IP 保护功能的第 3 季度时间表没有变化。 |
反弹跟踪缓解措施
| 反馈主题 | 摘要 | Chrome Response |
|---|---|---|
| API 反馈 | 在应用跳出跟踪缓解措施 (BTM) 时，Chrome 应阻止 Cookie/存储空间访问，而不是对其进行分区，理由是 Safari 的“分区”方法会导致意外行为和混淆。 | 我们欢迎这项建议。目前，BTM 不涉及 Cookie/存储空间分区，而是在宽限期过后将其删除。如果后续有任何涉及立即对 Cookie 采取行动的 BTM 设计，我们打算优先选择屏蔽 Cookie，而不是对 Cookie 进行分区。 |
增强跨网站隐私边界
Related Website Set（以前称为 First-Party Set）
本季度未收到任何反馈。
Fenced Frames API
本季度未收到任何反馈。
Shared Storage API
| 反馈主题 | 摘要 | Chrome Response |
|---|---|---|
| API 功能请求 | 请求在共享存储空间中附加广告浏览和点击数据。 | 鉴于 Google 于 2025 年 4 月宣布将继续沿用当前在 Chrome 中为用户提供第三方 Cookie 选择的方案，我们在评估 Privacy Sandbox API 今后将发挥的作用时，会考虑这些反馈。 |
CHIPS
| 反馈主题 | 摘要 | Chrome Response |
|---|---|---|
| API 问题 | 请求澄清 Chrome 的 3PC 控制功能如何与 CHIPS 互动，具体而言，当 3PC 停用时，非分区 Cookie 是否会转换为分区 Cookie，以及分区 Cookie 是否会保持有效。 | 当 3PC 处于停用状态时，系统不会在第三方情境中存储、检索或发送非分区 Cookie。不过，分区 Cookie 将继续在第三方情境中存储、检索和发送，因为禁用 3PC 的浏览器设置不会影响其功能。 |
| 隐私问题 | 担心具有持久标识符（例如用于单点登录）的嵌入方可能仍然能够使嵌入方和被嵌入方获得全局数字标识符，即使使用分区 Cookie 也是如此。 | 虽然嵌入方可能具有持久性标识符，但当此标识符存储在分区 Cookie 中时，只能在嵌入方设置该 Cookie 的网站上访问。跨网站联接此标识符需要登录操作，而登录操作本身就允许交换身份验证令牌形式的标识符，即使不使用分区 Cookie 也是如此。 |
FedCM
| 反馈主题 | 摘要 | Chrome Response |
|---|---|---|
| API 应用 | 对于拥有多个账号的用户，静默中介失败，但没有具体错误。 | 静默中介行为是一项按设计实现的功能，因为它仅适用于只有一个可用账号的非常特殊的情况。建议改用“可选”中介，这样一来，如果无法进行静默中介，FedCM 会回退到向用户显示账号选择器。 |
| API 应用 | navigator.credentials.get 会返回一般性错误，从而无法捕获特定的拒绝原因，例如用户关闭或冷却期。 |
开发者无法区分用户关闭 FedCM 对话框、网络错误以及 FedCM 因用户之前关闭对话框而处于“冷却期”的情况，这也是一项旨在保护用户隐私的设计功能。令人担忧的是，这种功能会让网站能够推断用户在不同身份提供方 (IdP) 上的登录状态。 |
| 登录 | 观察到在登录多个账号的情况下，账号选择行为不一致。 | 目前尚不清楚在多账号登录场景中，间歇性无法选择特定账号是 FedCM 中的间歇性 bug，还是涉及测试系统的某些问题。我们正在与报告者合作解决此问题，并已要求对方提供更多详细信息，以便我们更好地了解此问题。 |
| API 应用 | 如果用户在使用 FedCM 进行授权时关闭了对话框，系统不会通过可捕获的错误报告用户处于冷却状态。 | 是的，在这种情况下，系统会生成一般性错误代码，以保护用户隐私。 |
| API 应用 | 为什么在成功进行“自动重新身份验证”后，FedCM 会进入 10 分钟的静默期？ | 鉴于自动重新身份验证是在没有用户发起操作的情况下发生的，如果用户想返回网站但使用其他账号登录，则需要一段时间让 FedCM 不自动重新验证其身份。“静默期”为用户提供了使用其他账号手动登录的机会。如需详细了解此“静默期”，请参阅这篇博文。 |
| 轻量级 FedCM | 有人担心，由于需要支持两种不兼容的实现（FedCM 与 Lightweight FedCM），Lightweight FedCM 提案会给 IdP 带来额外的复杂性。 | 轻量级 FedCM 与传统 FedCM 兼容。身份提供方可以选择使用哪种实现方法，无需同时支持这两种方法。 轻量级 FedCM 是 FedCM 的推送机制。如果 IdP 选择使用此功能，则可以在用户登录时将账号信息推送到浏览器，这样，当信赖方 (RP) 调用 FedCM 时，系统会从浏览器（而不是 IdP 的账号端点）检索账号。 |
| 轻量级 FedCM | 担心轻量级 FedCM 提案中将个人用户数据（例如姓名、电子邮件地址和个人资料照片）暴露给 RP。 | 自收到此反馈以来，轻量级 FedCM 提案已更新，从方法响应中移除了名称、电子邮件地址和个人资料图片。 |
| 轻量级 FedCM | 在轻量级 FedCM 提案中，管理多个已登录的账号似乎过于僵化。该提案目前不支持为每个账号设置单独的会话生命周期或细致的登录状态。 | 过期时间目前与凭据对象中的 IdP 相关联。我们已将“按账号设置过期时间”列为待解决的问题，并会在未来的开发工作中考虑此反馈。 |
| 轻量级 FedCM | “已登录”和“可供选择”之间的区别未明确定义，这可能会影响轻量级 FedCM 提案的用户体验。 | 我们目前不支持在 FedCM 界面中区分账号是处于登录状态还是已退出登录状态。不应列出已退出登录的账号。 如果某个账号已退出登录并列在列表中，而用户选择的账号未处于活跃登录状态，则可以使用 Continuation API 让用户重新登录。 |
| API 应用 | getUserInfo 中的 given_name 字段与 FedCM 界面中的用法不一致。 |
我们与 Mozilla 进一步讨论了此问题（点击此处了解详情），以便就如何在 getUserInfo 中处理 given_name 达成一致。 |
| API 应用 | 并非所有在界面中使用的 IdentityProviderAccount 中的字段都提供给 getUserInfo，尤其是 tel 和 username，这表明需要进行同步。 |
与 Mozilla 和其他 FedID 社区组成员就以下问题进行的讨论正在取得进展：如何协调将 IdentityProviderAccount 中的哪些字段发送到 getUserInfo. |
| 企业 FedCM | 请求为企业 IdP 使用场景提供 FedCM 支持。 | 关键问题在于，需要一种可信的机制，让 IdP 向浏览器发出信号，表明管理员已预先同意允许用户访问特定的 RP，而这些 RP 无法被 Web 跟踪器模仿和/或滥用。在 4 月 22 日的 FedID CG 会议上讨论了此问题（请点击此处查看会议记录），并提出了浏览器扩展程序和企业政策（适用于受管理的设备）的组合作为潜在的解决方案。 欢迎点击此处就此问题提供更多反馈。 |
防范垃圾内容和欺诈行为
Private State Token API（和其他 API）
本季度未收到任何反馈。