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