2022 年第 4 季度季度报告，总结了收到的有关 Privacy Sandbox 提案的生态系统反馈和 Chrome 的回复。
根据对 CMA 的承诺，Google 已同意每季度公开提供有关其 Privacy Sandbox 提案的利益相关方互动流程的报告（请参阅承诺的第 12 段和第 17(c)(ii) 段）。这些 Privacy Sandbox 反馈摘要报告是通过汇总 Chrome 从反馈概览中列出的各种来源（包括但不限于 GitHub 问题、privacysandbox.com 上提供的反馈表单、与行业利益相关方举行的会议和 Web 标准论坛）收到的反馈而生成的。Chrome 欢迎从生态系统中获得反馈，并积极探索将所学知识融入设计决策的方法。
反馈主题的排名依据是每个 API 的普遍性。具体方法是汇总 Chrome 团队针对给定主题收到的反馈量，并按数量从高到低排序。我们通过查看公开会议（W3C、PatCG、IETF）、直接反馈、GitHub 以及 Google 内部团队和公开表单中出现的常见问题，确定了常见的反馈主题。
具体而言，我们查看了 Web 标准机构会议的会议记录，并考虑了 Google 的 1 对 1 利益相关方会议记录、各个工程师收到的电子邮件、API 邮寄名单和公开反馈表单，以获取直接反馈。然后，Google 协调了参与这些各种宣传活动的团队，以确定与每个 API 相关的主题的相对普遍性。
关于 Chrome 对反馈的回复的说明是根据已发布的常见问题解答、对利益相关方提出的问题的实际回复，以及专门为此次公开报告活动确定的立场而制定的。我们收到了有关 Topics API、Fledge API 和 Attribution Reporting API 的大量问题和反馈，这反映了当前开发和测试的重点。
在当前报告期结束后收到的反馈可能尚未获得 Chrome 团队的回复。
首字母缩写词表
- CHIPS
- 具有独立分区状态的 Cookie
- DSP
- 需求方平台
- FedCM
- Federated Credential Management
- FPS
- First-Party Set
- IAB
- 美国互动广告局
- IDP
- 身份提供商
- IETF
- 互联网工程任务组
- IP
- 互联网协议地址
- openRTB
- 实时出价
- 加时赛
- Origin 试用版
- PatCG
- “私密广告技术”社区群组
- RP
- 依赖方
- SSP
- 供应方平台
- TEE
- 可信执行环境
- UA
- 用户代理字符串
- UA-CH
- 用户代理客户端提示
- W3C
- 万维网联盟
- WIPB
- 故意忽视 IP
一般反馈，无特定 API/技术
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| （也报告在第 3 季度） 对不同类型利益相关方的实用性 |
担心 Privacy Sandbox 技术会偏向大型开发者，并且小众（小型）网站的贡献比通用（大型）网站更大 | 我们的回答与第 3 个问题的回答保持不变： “Google 已向 CMA 承诺，在设计和实施 Privacy Sandbox 提案时，不会通过偏袒 Google 自己的业务来扭曲竞争，并会考虑对数字广告竞争以及发布商和广告客户（无论规模大小）的影响。我们将继续与 CMA 密切合作，确保我们的工作符合这些承诺。 随着 Privacy Sandbox 测试的推进，我们将评估的一个关键问题是，这些新技术对不同类型的利益相关方的效果如何。在这方面，反馈至关重要，尤其是具体且切实可行的反馈，有助于我们进一步改进技术设计。 我们已与 CMA 合作制定了定量测试方法，并支持 CMA 发布有关实验设计的备注，以便向市场参与者提供更多信息，并让他们有机会对建议的方法发表意见。” |
| （也报告在第 3 季度） 文档请求 |
请求提供更多资源，详细说明如何管理测试、分析和实现 | 第 4 季度更新： 我们很高兴开发者认为我们目前提供的资料很有帮助，并将继续致力于提供更多资料，让开发者了解这些新技术对他们有何帮助。在过去一个季度，我们在 privacysandbox.com 上添加了“新闻和动态”部分，并发布了一篇详细的文章，介绍了 Privacy Sandbox 未来如何帮助提升广告相关性。 我们还举办了面向开发者的公开咨询交流时间，分享最佳实践和演示，并与产品和工程主管举办了问答会，以便进行实时讨论/提问。 |
| 核心网页指标 | Privacy Sandbox API 延迟时间如何影响 Core Web Vitals？ | 尽可能缩短延迟时间是 Privacy Sandbox API 的关键设计目标。我们目前预计，API 延迟时间对网站的核心 Web Vitals 指标的影响应该很小，因为大多数 API 都是在网站初始呈现后调用的。我们会继续监控和改进，以进一步缩短每个 API 的延迟时间，同时欢迎您继续进行测试并提供反馈。 实时出价流程中的延迟时间在“FLEDGE 竞价的效果”下方的 FLEDGE 部分中进行了介绍 |
| 互操作性 | 与其他潜在解决方案的互操作性方面存在疑虑 | Privacy Sandbox 的目标是在保护用户免受跨网站跟踪的同时，满足网络生态系统的需求。为此，我们将弃用支持此类跨网站跟踪的旧版浏览器技术（例如第三方 Cookie），取而代之的是专门用于支持特定用例的新技术。 Privacy Sandbox 提案通过限制从用户设备发出的数据来加强隐私保护。这些提案不会对网站从浏览器中收集数据后共享或以其他方式处理数据的能力施加技术限制。因此，这些技术不会阻止公司签订“数据管理”协议或任何其他类似的合同关系。同样，这些政策也不会限制用户同意通过其他方式分享其数据。 需要说明的是，Google 已承诺以相同的方式将 Privacy Sandbox 技术应用于所有网站，包括 Google 产品和服务。这些承诺还明确指出，在 Chrome 停止支持第三方 Cookie 后，Google 不会出于定位数字广告或衡量广告效果的目的而使用其他个人数据（例如用户已同步的 Chrome 浏览记录）来跟踪用户。 |
展示相关内容和广告
主题
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 对 Google 搜索排名的影响 | 询问网站是否支持 Topics API 会被用作 Google 搜索结果排名的潜在信号 | 某些网站可能会选择停用 Topics API。Privacy Sandbox 团队未与搜索组织协调或请求他们使用网页排名来激励网站采用 Topics API。Google 已向 CMA 确认，Google 搜索不会将网站选择停用 Topics API 的决定作为排名信号。 |
| 主题分类器 | 除了主机名之外，还添加了网址和网页内容，以确定网页的主题，从而提高对各利益相关方的实用性。 | 用户的浏览记录目前是根据网站的主机名进行分类的。Chrome 将继续评估在主题分类中考虑网页级元数据（例如网页网址和/或内容的所有或部分组成部分）的选项。在考虑任何实用性改进时，都必须权衡隐私和滥用风险。 例如，仅就元数据而言，一些风险包括： - 网站修改网页级元数据，以将不同的（可能敏感）含义编码为主题； - 网站修改网页级元数据，以误导性地陈述其主题以牟利； - 网站动态修改网页级元数据，以进行跨网站跟踪 |
| （也已在第 3 季度报告中提及） 对第一方信号的影响 |
主题信号可能非常有价值，因此会降低其他基于兴趣的第一方信号的价值。 | 我们的回答与第 3 个问题的回答保持不变： “我们认为，针对用户兴趣投放广告是网络的一个重要用例，Topics 旨在支持该用例。正如 [我们在第 3 季度报告中]所述，其他生态系统利益相关方曾表示，主题可能不够实用，无法提供价值。无论如何，我们会不断改进分类法，并希望随着生态系统测试和反馈的不断完善，分类法也会不断发展。” |
| 更新分类 | 分类列表将如何更新？ | 我们正在积极征求反馈，以确定对整个生态系统最有用的分类法。初始 Topics API 提案中包含的分类旨在实现功能测试。Chrome 正在积极考虑多种更新分类法的方法。例如，Chrome 可能会利用每个主题的商业价值概念来确定在未来的迭代中要包含哪些类别。 |
| 主题区域分类器的效果 | 主题分类器在地区性网域中的效果不佳 | 我们会持续改进分类器。根据收到的反馈，我们正在考虑扩大 Topics 替换列表，我们的分析表明，这将扩大全球覆盖面并提高准确性。 需要说明的是，Topics API 分类有两个相关组成部分：(1) 包含前 1 万个网站及其主题的替换列表，以及 (2) 用于将主机名分类为主题的设备端机器学习模型。通过扩展替换列表 (1)，我们可以提高分类器在分类效果可能较差的区域的分类性能。 |
| 一周纪元 | 对于希望做出短期决策的用户而言，一周的纪元太长。 | 我们正在积极研究适当的纪元长度，欢迎您 提供更多反馈，告诉我们哪种纪元更适合该生态系统。 |
| HTTP 标头检索 | 担心有关主题的 HTTP 标头检索的信息不足 | 我们正在处理标头和 fetch() 问题。您还可以在此处了解相关信息。我们还在说明中添加了 skipObservation 信息。 |
| 主题仅用于帮助广告客户，而非用户 | 主题/Privacy Sandbox 似乎是一种侧重于行业的方法。对用户的好处不如对行业的好处那么明确。 | 我们认为，Topics 支持基于用户兴趣的广告，有助于维护开放自由的网络，对用户而言是一件好事。我们还认为，与第三方 Cookie 相比，Topics 显著提升了隐私保护水平。如果移除第三方 Cookie 但没有可行的替代方案，可能会对发布商产生负面影响，并可能导致采用效果更差的方法 ，这些方法的隐私保护性较差、不透明，并且无法由用户实际重置或控制。许多公司都在积极测试 Topics API 和 Sandbox API，我们致力于提供有助于增强隐私保护和支持 Web 的工具。 W3C 技术架构组最近发布了其对 Topics API 的初步看法，我们将对此进行公开回复。目前，Google 收到了生态系统中提出的有关此审核对 Topics API 的开发和发布可能有何影响的问题，因此我们想重申，我们计划在今年将其纳入 Chrome 稳定版。虽然 Google 感谢 W3C 技术架构组提供的反馈，但认为与 CMA 和生态系统协商，继续努力开发和测试 Topics 至关重要。 |
| 数据泄露 | 担心主题可能会未经许可泄露到其他网站 | Topics API 的设计使得单个发布商（甚至一小群发布商）的数据极不可能以任何方式泄露。发布商网站还可以完全控制 Topics API，并可以通过权限政策禁止访问此 API。 |
| 缺少可供测试的广告客户 | 发布商担心，他们目前无法向广告客户展示主题的价值。 | 我们计划在 2023 年下半年开放所有与广告相关的 API 以供集成测试，并支持生态系统分析主题对广告客户的价值。测试和结果发布将由 CMA 监督，CMA 将审核数据、分析和方法。我们鼓励整个生态系统与 Google 和 CMA 分享反馈。 |
| Topics 和 FLEDGE | 申请详细了解如何在 FLEDGE 出价逻辑中使用 Topics | 您可以在 FLEDGE 出价逻辑中使用主题。我们还在编写集成指南，其中将包含有关实现的更多详细信息。 |
| 针对主题调用方自定义排名 | 允许调用方量身定制排名 | 为每个广告技术平台指定自定义主题排名或值存在一个难题，即这可能会成为广告技术平台影响返回的主题的机制，因此会成为一种指纹化矢量。 |
| 主题来电者优先级列表 | 允许调用方提供 Topics API 将根据资格条件返回的主题的排序优先级列表。 | 我们目前正在进一步讨论此想法 ，欢迎提供更多反馈。 |
FLEDGE
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| Google Ad Manager | 担心 Google Ad Manager 是 FLEDGE 竞价的最终决策者，并且会偏向 Google 发布商代码和 Google Ad Manager。 | FLEDGE 允许每个发布商选择竞价结构，包括选择顶级卖方和组件卖方。组件竞价中的每个买方和卖方都知道顶级卖方是谁，并且可以选择是否出价。 |
| 测试 FLEDGE 的参与者人数不足 | 请求鼓励更多公司测试 FLEDGE，例如通过改进 API 的功能并劝阻使用侵犯隐私的替代方案（例如指纹） | 我们将在 CMA 和 ICO 的指导下，与各方密切合作，分阶段推进 Privacy Sandbox 的开发。功能性 FLEDGE 测试已证明其具备必要的稳定性和功能。Google 一如既往地鼓励整个生态系统测试 Sandbox API，最近发布了“最大限度提高广告相关性”文档，展示了在第三方 Cookie 弃用后，FLEDGE 和其他 API 如何帮助广告行业支持关键用例。 Privacy Sandbox 的其他部分已经支持用于防范覆盖性跟踪的缓解措施（请参阅 UA-CH、IP 保护和跳出率跟踪缓解措施），并且会随着时间的推移不断改进。Google 的目标不是让 FLEDGE 成为唯一可行的定位解决方案，而是致力于与行业和监管机构合作，在 Chrome 浏览器中推动采用可保护隐私的最佳广告技术。 |
| 机器学习使用场景 | FLEDGE 和归因报告中将提供有关如何使用机器学习用例训练竞价出价算法的更多指导 | 我们认识到，需要帮助测试人员找到最实用的 Privacy Sandbox 技术应用方式。我们已开始发布有关将 Privacy Sandbox API 的各个方面用作机器学习输入的具体指南。最新一篇文章尽可能提高广告相关性探讨了广告行业如何将这些信号用于机器学习，我们计划今后继续发布此类指南。 |
| 查询 FLEDGE 键值对 (K/V) 服务器 | 为什么 K/V 服务器可公开查询？ | K/V 服务器旨在向 FLEDGE 竞价提供实时信号。因此，需要从执行这些 FLEDGE 竞价的位置（即用户设备）访问 K/V 服务器，这要求该服务器必须是公开的。存储在键值对服务器中的值只能由已拥有其键的各方检索，因此，如果广告技术平台仅向兴趣群体中的浏览器提供键，并且不使用可被随机猜出的键，那么只有需要该值来运行竞价的浏览器才能检索该值。 |
| 如何进行日期/时间定位？ | 支持在出价逻辑函数中使用日期对象。 | 您可以通过多种方式执行此操作。买家可以要求卖家提供当前日期和时间，卖家应能够轻松地向所有买家提供此信息。买方还可以在实时键值对响应中提供日期和时间。最后，买方可以在每个买方信号中的情境响应中提供日期和时间，卖方可以将其传递给买方的 generateBid 脚本。 |
| 用户偏好设置 | 用户可以选择屏蔽通过 FLEDGE 或替代解决方案投放的广告客户广告素材。 | 用户可以在 Chrome 中停用 Ads API。对于特定广告，相关广告技术平台最有能力控制展示哪些广告素材或如何选择广告素材。 |
| 更清晰的时间表 | 请求详细了解 FLEDGE 中是否提供隐私保护功能，例如是否需要使用 Fenced Frames。 | 我们计划在第 1 季度发布更详细的时间表。 |
| 报告混淆 | 请求更清楚地了解 FLEDGE 报告将如何与 Fenced Frames API 和 Private Aggregation API 等其他 API 搭配使用。 | 我们计划在未来几周内发布有关 Private Aggregation API、FLEDGE 和 Fenced Frames 之间互动的说明文档。 |
| 实时出价和 FLEDGE | 有关 FLEDGE 如何与标准实时出价集成的指南。 | 影响广告技术平台实时出价能力的两个主要因素是访问事件级数据和更轻松地与 ARA 集成。我们计划在第一季度发送有关这两项功能的最新动态和说明文档。 |
| FLEDGE 竞价的效果 | 测试人员报告 FLEDGE 竞价存在高延迟 | 感谢测试人员分享其结果和用例的报告，我们也分享了一些有关如何提升 FLEDGE 的效果的建议。 与此同时，我们还向浏览器添加了工具，让开发者能够更好地诊断导致竞价缓慢的原因，并系统地解决观察到的主要延迟时间来源。最近的改进包括针对运行缓慢的竞价设置超时、一种快速出价方过滤技术、一种重复使用 FLEDGE worklet 以避免支付启动费用的方法，以及正在进行的工作，旨在允许内容相关广告请求与 FLEDGE 启动时间和网络提取并行运行。我们预计，Chrome 开发者和 FLEDGE 测试人员会根据他们在使用该 API 时的实际体验，持续对延迟时间进行优化。 |
| 兴趣群组大小内存限制 | 请求将单个兴趣群组的大小上限从 50KB 提高。 | 我们正在积极考虑该请求，并希望您就适合的上限值提供反馈。 |
| 将 FLEDGE 投放的数据与第一方 Cookie 相结合 | FLEDGE 是否支持与广告客户的第一方数据集成？ | FLEDGE 旨在支持使用广告客户已有的第一方数据投放广告。不过，FLEDGE 不支持广告客户了解用户在广告客户自有网站以外的任何网站上的浏览行为。将非网站浏览行为附加到第一方数据是与 Privacy Sandbox 的目标相悖的。 我们计划在未来几周内分享集成指南，详细介绍 FLEDGE 将如何支持与第一方数据集成。 |
| k-匿名性值 | 如何确定“K”到“k-anon”的值，以及是否会发布？ | “K”值仍在最终确定中，我们会在计划不断完善的过程中分享更多信息。我们有兴趣详细了解未知 k 值如何妨碍 FLEDGE 准备工作和机器学习模型训练范围的确定，并欢迎您就此主题提供更多反馈。 |
| 支持多个 SSP | FLEDGE 如何支持多个 SSP？ | 如此提案中所述，FLEDGE 支持多卖家竞价。 |
| 出价逻辑的公开范围 | 担心 DSP 出价逻辑会在 JavaScript 中公开 | 在当前设计中，其他人可以访问出价逻辑 JavaScript，但我们欢迎提供更多反馈，说明这为何会成为 DSP 的关注焦点。 |
| prebid.js | FLEDGE 何时支持 prebid.js？ | 只有 Prebid.js 7.14 及更高版本支持 FLEDGE 模块。任何有兴趣参与测试的发布商都必须添加 FLEDGE 模块并升级其预出价实例。 |
| FLEDGE 中的用户定义函数 | FLEDGE 将如何支持用户定义的函数 (UDF)？这些函数可由最终用户编程，以扩展 API 的功能。 | 如需查看说明，请点击此处。我们仍在完善此功能，因此欢迎您就用例提供更多反馈。 |
| 放宽对兴趣群组资源的同源限制 | 请求放宽对兴趣群组资源的同源限制，以支持特定广告技术平台用例 | 在 FLEDGE 的当前实现中，biddingLogicUrl、biddingWasmHelperUrl、dailyUpdateUrl 和 trustedBiddingSignalsUrl 必须与兴趣群体所有者具有相同的来源。此限制旨在防止攻击者利用某些漏洞，如此处所述。 |
| interestGroup 所有权 | 请求限制广告技术平台是否可以在不同网站上针对相同的兴趣群体使用 joinInterestGroup | 我们关注的是受众群体的使用方式，而不是受众群体的构建方式。我们正在讨论可能的做法，欢迎您提供更多反馈。 |
| 键值对服务器密钥过期 | 讨论在相应兴趣群组过期后移除服务器密钥 | 我们正在探索处理密钥过期的方法，并期待收到反馈。 |
衡量数字广告的效果
Attribution Reporting API（及其他 API）
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 源试用流量 | 当前来源试用流量不足以进行实用程序测试。 | 当前的 Origin 试用版旨在供生态系统参与者进行功能测试，以确保该 API 按预期运行。我们了解到，随着各种 Privacy Sandbox API 的开发日趋成熟，执行实用程序测试所需的流量将会增多。目前的测试时间表预计，到 2023 年第 3 季度正式版发布（即针对相关用例开发的技术正式发布，可面向所有 Chrome 流量投入使用）时，我们将完成这项工作（请参阅 privacysandbox.com 上的最新时间表）。对于需要额外流量的用例测试，我们欢迎您提供任何其他反馈。 |
| 不同 Privacy Sandbox 效果衡量 API 的功能重叠 | 通过 Privacy Sandbox 使用多种衡量方法会增加复杂性，例如 Attribution Reporting API 和 Private Aggregation API。 | 我们正在努力改进文档，以阐明这些 API 的不同用例，并欢迎您就缺少说明的方面提供更多反馈。例如，Attribution Reporting API 专门用于支持转化衡量，而 Private Aggregation API 和 Shared Storage 是通用 API，旨在支持更广泛的跨网站衡量用例。 |
| 重试失败的报告请求 | 阐明了报告请求在失败后会尝试多少次。 | 我们已发布相关指南。总而言之，只有在浏览器运行/在线时，才会发送报告。第一次发送失败后，系统会在 5 分钟后重试报告。第二次失败后，系统会在 15 分钟后重新尝试生成报告。之后，系统便不会再发送报告。 |
| 报告延迟 | 报告预计会延迟多久？ | 我们希望听取生态系统中更多用户的反馈，了解他们在报告生成方面遇到的延迟问题，同时收集数据以进一步评估这些延迟问题。 |
| 预渲染网页 | ARA 归因是否适用于预渲染网页？ | 在预渲染网页上，归因注册会延迟到激活（实际点击或观看发生）时。这意味着，我们将推迟执行 `attributionsrc` 请求 ping。 |
| 衡量转化量提升情况 | 如何在同一网域中通过 A/B 测试衡量转化量提升幅度 | 网站可以通过归因报告，在同一网域中通过 A/B 测试衡量转化次数提升幅度。他们可以使用 Aggregate API 将 A/B 参数编码为键，然后按这些键分桶接收转化价值摘要报告。 |
| （也报告在第 3 季度）跨网域转化 | 如何跟踪跨网域转化（例如，具有 2 个或更多目标位置） | 第 4 季度更新： 我们发布了一项提案，旨在移除着陆页目标位置限制，以便跟踪跨网域对话。此提案已实施。 |
| （也报告在第 3 个问题中） 转化报告中的到期设置 |
请求支持报告过滤条件 / 有效期短于 24 小时 | 第 4 季度更新： 我们已分享此拉取请求 ，该请求将解除过期时间和报告时间范围之间的关联，以减少报告延迟与转化过期之间的权衡。此功能现已在 M110 中发布。 |
| 欺诈和滥用行为 | 广告客户和营销者请求能够根据其广告投放的发布商网站细分和汇总数据，这也有助于深入了解潜在的欺诈性广告做法 | 我们正在此处 积极讨论这些反馈，欢迎您提供更多意见。 |
| （也已在第 3 季度报告）事件级报告延迟 | 对于某些用例，事件级报告的 2-30 天延迟时间可能过长。 | 事件级报告的默认报告期为 2 天、7 天和 30 天。您可以使用“expiry”参数修改此设置。广告技术平台可以配置过期时间（最短 1 天），以便在 2 天内获取潜在报告。作为隐私保护机制，我们将到期时间的精细程度限制为 1 天，因为更精细的报告可能会导致时间攻击。此外，我们允许为事件级报告和汇总报告设置独立的“expiry”参数。请点击此处。此外，Google Ads 不会获得其他广告技术平台无法通过 Attribution Reporting API 获得的任何特殊报告期。 |
| 相同的报告来源要求 | 要求移除来源注册来源与转化注册来源相同的要求 | 我们建议使用 HTTP 重定向来委托注册，以解决此用例。欢迎您就新指南提供任何其他反馈。 |
| 转化跟踪 | 需要区分转化是发生在广告客户设定的特定时间之前还是之后 | Attribution Reporting API 支持为来源归因设置失效期限和优先级。从技术层面讲，同时使用这两种归因模型，您可以将在 X 天内发生的转化与在 X 天后发生的转化分别归因。 |
| 噪声模拟 | 请求能够模拟每个存储分区的转化量，以了解对转化量较少的广告客户的影响 | 我们希望在未来版本的噪声实验室中添加模拟此类情况的方法。欢迎您提供任何其他反馈。 |
| 在移动设备上生成报告 | 当 Chrome 在移动设备上后台运行时，报告是否仍会发送？ | 目前，即使在移动设备上，当 Chrome 在后台运行时，系统也不会发送报告。当该 API 与 Android Privacy Sandbox 集成后，这种情况可能会发生变化。请点击此处。请注意，Android Privacy Sandbox 不在 CMA 接受的承诺范围内。 |
| 数据可用性 | 担心 Google 会通过 Privacy Sandbox API 获得对数据的额外访问权限 | 首先，Google Ads 不会获得对 Attribution Reporting API 或其他 Privacy Sandbox API 中数据的任何优先访问权限。“互操作性”下的“常规反馈”部分也提到了这个问题，其中详细介绍了 Google 的承诺。 其次，关于大型网站和小型网站之间的差异，Google 认为基于噪声的隐私保护措施对较小的数据片段的影响可能更大。不过，还是有一些可能的缓解措施：例如，通过在更长时间段内进行汇总等方法可以解决此问题。尽管如此，我们仍不清楚，基于非常小的数据片段（例如一次或两次购买交易）得出的结论对广告客户而言是否有任何意义。在起源试用期间，Google 鼓励测试人员利用实验功能来尝试各种隐私和噪声参数，以便就此问题提供更具体的反馈。 |
限制隐蔽跟踪
用户代理缩减
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 在 Web 生态系统更加完善之前，推迟实施用户代理缩减 | 没有足够的时间来适应即将发生的用户代理数量减少变更。 | 在完整报告的“Google 与 CMA 的互动”部分下，我们在“利益相关方关注的问题”下回复了此反馈。 |
| 在 Web 生态系统更加完善之前，推迟实施用户代理缩减 | 请求在部署结构化用户代理 (SUA) 之前推迟用户代理缩减功能的发布 | Google Ads 团队于 2021 年 10 月向 OpenRTB 提议了添加结构化 User-Agent（请参阅规范），该提议已纳入到 2022 年 4 月发布的 2.6 版规范更新中。 我们有证据表明，SUA 已部署并可供使用，如 Scientia Mobile 博文所示，该博文演示了如何使用 UA-CH 和 WURFL API 创建 SUA。 |
###
用户代理客户端提示
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 将 UA-CH 与其他反隐蔽跟踪技术搭配使用 | 有关如何以整体方法测试所有 Privacy Sandbox API 和提议的所有指纹识别技术的指南 | 我们的测试计划旨在反映开发一些反指纹措施（而非沙盒提案的其余部分）的异步时间表。这项变更旨在解决以下现实问题：只有在第三方 Cookie 被弃用后，某些反指纹措施（例如隐私预算、IP 保护和跳出率跟踪缓解措施）才能全面开发完毕并准备好正式发布。 虽然这些反指纹措施不会纳入定量测试范围，但我们会根据“暂停”期间可用的事实对其进行定性评估。 |
| （也报告在第 2 季度） 效果 |
关于通过 Critical-CH 获取提示的延迟时间的疑虑（在首次加载网页时） | 请参阅下文的专门 UA-CH 部分 |
| 反馈不足 | 生态系统对 UA-CH 更改的反馈可能不够充分，这可能会导致生态系统缺乏相关意识。 | 我们一直在主动分享我们的计划，以确保谨慎发布，最大限度地减少中断。 我们于 2022 年 3 月 18 日向 W3C 反欺诈社区组介绍了减少用户代理数量和 UA-CH API 的计划，并于 2022 年 1 月 20 日向 Web 支付工作组和 Web 支付安全利益群组介绍了这些计划。在演示期间或演示结束后，没有人提出重大疑虑。 Google 已主动与 100 多位网站运营者互动，以获取反馈。此外，Google 还根据生态系统利益相关方的反馈，通过 Blink-Dev 渠道公开发布了减少用户代理的实施情况。 |
| 计时 | 关于发布时间和行业准备情况的疑虑 | 请参阅下文的专门 UA-CH 部分 |
| Chrome 平台状态 | 请求更新 UA-CH 的 chromestatus 页面 | chromestatus 条目已于 12 月 19 日更新为“混合信号”。 |
IP 保护（以前称为 Gnatcatcher）
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 选择启用或停用 | IP 地址隐私权功能是“用户选择启用”还是“用户选择停用”？ | 我们的目标是为所有用户提供知识产权保护。为实现这一目标，我们目前正在评估 IP 保护的用户自选选项。 |
| 第一方数据的 IP 地址用例 | 启用 IP 保护后，能否使用 IP 地址将第一方网域中的用户历程拼接起来？ | 正如之前发布的那样，IP 保护功能最初将重点关注第三方环境中的跟踪，这意味着第一方网域不会受到影响。 |
| 广告技术用例 | 公司如何通过 IP 地址保护功能设置防欺诈措施？ | 我们深知 IP 地址在当今网络反欺诈工作中的重要性。我们在向 CMA 做出的承诺（第 20 段）中已表明，我们不会在合理努力支持网站开展反垃圾和反欺诈工作的情况下实施 IP 保护。我们的首要任务之一是了解 IP 保护功能对防欺诈用例和检测功能有何影响，以便进一步投资于可保护隐私的技术，帮助公司保障网络安全。我们鼓励您提供反馈和针对新提案的意见，以便更好地满足安全和反欺诈公司的需求，即使信号随时间推移而变化也是如此。 |
| 欺诈和滥用行为 | IP 保护是否包括防御拒绝服务 (DoS) 攻击？ | 我们致力于在保护网络安全的同时加强隐私保护，而防范拒绝服务攻击是一项重要的反滥用用例，需要在设计时予以考虑。我们希望通过 IP 保护功能本身的设计以及新的防滥用解决方案，尽可能降低对 DoS 防护的影响。由于 IP 保护功能最初侧重于第三方嵌入式服务，因此一些利益相关方表示，该功能对第一方网站的 DoS 防护影响有限。不过，我们仍会征求公开反馈，以评估针对 DoS 攻击的用例（尤其是第三方嵌入式服务）的风险。 与此同时，我们也在探索滥用行为反馈和客户端屏蔽机制，以便网站或服务在不识别用户身份的情况下屏蔽垃圾内容用户。 |
| 内容过滤 | 内容过滤（含 IP 保护） | 不同公司在过滤内容和自定义用户体验方面有不同的需求。许多此类用例目前不依赖于 IP 地址，因此应该不会受到 IP 保护的影响。例如，如果发布商希望量身定制其内容并提高互动度，则可以使用第一方 Cookie 或第三方分区 Cookie (CHIP) 来了解用户的兴趣和与发布商之前的互动情况。例如，专注于向合适的用户投放合适广告的广告技术合作伙伴可以结合使用 FLEDGE 和 Topics，以便取得与目前使用第三方 Cookie 或其他跨网站跟踪技术时类似的广告效果。 我们还在探索如何在 IP 保护功能中构建可保护隐私的新功能（例如粗略地理定位），以便在现有机制可能不足的情况下进一步支持内容过滤。欢迎您就可能受知识产权保护影响的内容过滤用例提供更多反馈。 |
| （也已在第 3 季度报告） 地理定位用例 |
IP 保护功能可能会阻止日后使用地理定位功能的合理用例，例如基于地理位置的个性化内容。 | 第 4 季度更新： 我们正在与利益相关方合作，确保 Chrome 继续支持 IP 地址的合理用例。我们希望生态系统就 IP 地理定位精确度提供反馈，欢迎点击此处提供反馈。 |
隐私预算
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 文档更清晰 | 更多示例，以便利益相关方预测在实施隐私预算后可能会受到哪些限制 | 隐私预算提案仍处于积极讨论阶段，尚未被任何浏览器实现。分阶段发布的最早日期表示可以强制执行隐私预算的最早日期。在 2024 年移除第三方 Cookie 之前，不会发生这种情况。我们目前没有任何其他文件可以分享。 我们将在该提案更加完善后分享更多详细信息。在此期间，我们欢迎利益相关方分享任何有助于我们制定提案的反馈。 |
增强跨网站隐私边界
First-Party Set
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| （也报告在第 3 季度）网域限制 | 请求扩大关联域名数量 | 第 4 季度更新： 我们已发布适用于本地测试的 FPS，包括 GitHub 上的模拟集提交流程，以及用于在本地测试 rSA 和 rSAFor 的一个标志。我们还针对 FPS 举办了两次面向开发者的公开会议，以继续解答与相关子集的用例相关的问题。我们建议开发者测试 FPS 功能，并就关联子集的网域限制对其用例的 FPS 易用性有何影响提供反馈。 我们在 WICG 通话中明确指出，Chrome 致力于提供可用的解决方案，同时兼顾用户的隐私权益。因此，我们希望社区就可能受到网域限制影响的具体用例提供反馈，以便相关团队考虑如何在继续保护用户隐私的同时，解决这些用例。 |
| 请求详细了解滥用行为缓解措施 | 如果用户的网域被添加到他们未同意的网域组中，会怎么样？ | 我们已于 2022 年 12 月 2 日在 此处发布了第一方组的提交指南。 如提交指南中所述，任何集合更改管理都将遵循并尊重 GitHub 上的验证流程，包括对所有权的验证，这应该可以降低此风险。 |
| 滥用行为缓解 | 担心 First-Party Set 组成可能会被利用 | 我们正在研究如何扩大对子类型的技术检查，并积极在此处征求社区的更多反馈。 |
| 广告用例 | 关于是否应使用第一方组来支持广告定位的问题 | 我们不打算支持第一方组的 Google Ads 定位用例，建议您使用适用于此类用例的 Google Ads API。 |
| （也报告在第 3 季度）政策 | 担心 FPS 与 CMA 关于“适用的数据保护法律”的承诺不一致，因为 GDPR 对一组网站的数量没有限制，而 FPS 设定了 3 个的限制 | 我们的回复与第 3 个问题的回复保持不变： “Google 将继续致力于向 CMA 保证，在设计和实施 Privacy Sandbox 方案时，不会通过偏袒 Google 自己的业务来扭曲竞争，并会考虑对数字广告、发布商和广告客户的竞争产生的影响，以及对隐私保护成效和对适用数据保护法律中所述数据保护原则的遵从产生的影响。所表达的疑虑并未披露与 GDPR 存在任何不兼容性。我们将继续与 CMA 密切合作，确保我们的工作符合这些承诺。” |
| 备选方案 | GDPR 验证集 | 除了生态系统针对采用“GDPR 验证集”的提案提供的反馈之外，Chrome 还对此替代方案的以下限制存有疑虑：
自提出此替代方案以来，Chrome 更新了第一方集合提案，并发布了有关创建新集合的提交指南。 |
Fenced Frames API
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 在 OT 期间的围栏帧限制 | 在源试用期内，Fenced Frames 目前有哪些限制？ | 我们正在编写有关限制和实施状态的文档，并计划在 2023 年第 1 季度分享该文档。 |
| 在单个 Fenced Frame 中展示多个广告 | 请求在一次竞价中在一个围栏框中展示多个广告客户 | 目前，我们尚未积极开发此请求，但如果生态系统参与者认为此功能很重要，我们欢迎您提供更多反馈。 |
| Web Bundle | 我们计划针对包含围栏帧的 Web Bundle 制定哪些要求和支持？ | 我们目前无法确定未来是否会要求这样做。我们会提前宣布任何更改，并且在弃用第三方 Cookie 之前不会强制执行这些更改。如需了解当前状态，请参阅此说明。 |
Shared Storage API
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 适用于广告技术平台的共享存储空间 | 关于将共享存储空间用于广告技术用例的不确定性 | Shared Storage API 和 Private Aggregation API 可用于需要跨网站存储空间衡量的各种衡量用途。此处列出了一些示例。 我们预计 DSP 和效果衡量解决方案提供商将成为广告用例的主要集成商。 |
CHIPs
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| （也已在第 3 个问题中报告）分区要求 | 为第一方 Cookie 的“分区”属性添加了明确的行为要求。 | 第 4 季度更新： 在 GitHub 和 PrivacyCG 通话中进行讨论后，我们达成了一致意见，即在第一方 Cookie 上设置的分区 Cookie 将使用分区键 (A,A)，其中“A”是顶级网站。我们将在说明文档和规范中记录此行为。 |
| Cookie 管理 | 是否有用于管理/治理第一方或第三方 Cookie 的工具？ | 您可以使用 Chrome 开发者工具和 NetLog 测试启用了第三方 Cookie 屏蔽功能的网站。当 Cookie 因用户配置而被屏蔽时，这两种工具都会报告。欢迎您就希望看到哪些其他审核网站提供反馈。 |
FedCM
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| IdP 需要了解 RP 才能允许会话 | 用户尝试通过两个不同的 RP 登录 Feide IdP 时出现的问题 | 我们正在讨论可能的解决方案。 |
| 互操作性 | 关于 FedCM 对用户与他们使用 FedCM 登录的网站之间的关系以及网站之间的“互操作性”的影响的疑虑 | FedCM 旨在从 Chrome 中移除第三方 Cookie 后，继续支持目前依赖第三方 Cookie 的联合身份服务。我们预计，FedCM 只是此类服务可用的选项之一；身份提供方 (IdP) 和依赖方 (RP) 可以自由使用可能更符合其需求的其他技术。 关于用户与 RP 关系和“互操作性”的疑虑似乎源于对 FedCM 提案的误解。FedCM 允许 IdP 在用户选择登录 RP 网站后，自行决定要与 RP 共享哪些信息以及以何种形式共享。FedCM 并不要求 IdP 为“用户进行身份验证的每个 [RP] 创建唯一的假名化标识符”。相反，FedCM 是开放式的，每个 IdP 都可以选择是否分享用户的实际标识符、该标识符的每个网站版本，或此信息的某种其他版本。 （FedCM 规范确实将跨网站关联视为与该 API 相关的隐私风险，并讨论了定向（每个网站）标识符作为可能的缓解措施。不过，是否使用定向标识符由 IdP 决定，而不是由浏览器强加。） FedCM 还提供了与身份相关的用户选项。例如，如果用户在同一 IdP 中拥有多个身份（例如工作资料和个人资料），FedCM 提供了一种方式，让用户可以选择要使用哪个身份登录 RP 的网站。此外，每个 RP 都可以自行决定在其网站上支持哪些 IdP。在做出此决定时，需要考虑 IdP 所依赖的机制，无论是 FedCM 还是其他技术。再次强调，浏览器不会为 RP 或 IdP 强制执行这些选择。 |
打击垃圾内容和欺诈行为
Private State Token API
| 反馈主题 | 摘要 | Chrome 回复 |
|---|---|---|
| 处理聊天机器人 | 如果签发者发现已向聊天机器人颁发了私密状态令牌，会出现什么情况？ | 为避免向聊天机器人发放的令牌在生态系统中保留很长时间，签发者应定期轮替用于对令牌进行签名的密钥，以便根据可能已损坏的发放逻辑发放的旧令牌过期，而网站可以使用更新的发放逻辑兑换较新的令牌。 |
| 同一网站表单提交 | Private State Tokens 是否可用于涉及全页导航（即 Content-Type: application/x-www-form-urlencoded）的同一网站表单提交，而不是来自 fetch/XMLHttpRequest API 的请求？ | 第一个版本的私密状态令牌目前不支持此操作。如果生态系统对此用例有强烈需求，我们欢迎提供反馈。 |
| 服务器端验证 | 关于是否可以在服务器端验证 Private State Tokens 的问题 | 令牌是通过发行商兑换的，然后发行商会创建一个兑换记录，其中可能包含令牌本身或从令牌派生的某个已签名值，服务器可以使用该兑换记录来验证令牌的真实性，我们预计不同的发行商生态系统会针对如何解读其兑换记录制定不同的标准。 |