2022 年第 1 季度的季度报告，其中总结了生态系统对 Privacy Sandbox 提案的反馈以及 Chrome 的回应。
作为对竞争和市场管理局的承诺，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、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 进行了广泛的沟通，并且 Chrome 会发布一个常见问题解答来确认这一点，以表明将在全球范围内进行该测试。此外，Chrome 还会与 CMA 协商，定期更新公开时间表。
展示相关的内容和广告
| API / 技术 | 反馈主题
（按发生率排序） |
问题和疑虑摘要 | Chrome 响应 |
| 主题 | 粗略主题的实用性 | 有人担心，粗略的主题分类可能并不适合针对用户兴趣投放广告。 | 我们将通过测试来探索该 API 的实用性。Chrome 预计该分类会根据测试结果不断演变。 |
| 主题 | 类目 | 行业利益相关方希望有发言权来影响分类。 | Chrome 仍会保持打开状态，可输入类目。Chrome 非常希望能就用于修改分类的治理模式提供反馈，并探讨其他行业机构可如何更积极地参与分类的长期开发和维护。 |
| 主题 | 对不同类型的网站的实用性 | 有人担心，网站之所以会有实用性，是因为网站的流量水平或内容的专业程度如何。 | 我们将通过测试来探索该 API 的实用性。Chrome 预计分类和其他参数会根据测试结果而变化。分类或参数的演变可能不需要向后不兼容的更改。此外，Chrome 团队期望反馈能够在第三方 Cookie 弃用后继续影响 Topics API 的演变。 |
| 主题 | 网站分类方法 | 请求网站能够决定或影响其 Topics 分类。 | Chrome 正在探索这项请求，但收到（来自网络浏览器社区和 DSP）的担忧，他们认为网站可能会以侵犯隐私的方式定位到用户或降低广告相关性，存在“欺骗系统”的风险。Chrome 正在征求反馈并权衡潜在的变化。 |
| 主题 | 噪音信号 | 以 5% 的比例随机发送主题可能会造成过多噪声 / 虚假信号。 | 噪声是保护用户隐私的一种重要方法，我们将通过测试来探索各主题的噪声等级与实用性。 |
| 主题 | 由网站控制的第三方权限 | 请求网站能够选择哪些广告技术平台可以从其网站调用 Topics API。 | 如说明中所述，这项请求的功能已通过“browsing-topics”权限政策提供。 |
| 主题 | Topics API 对网页性能的影响 | 担心由于依赖于 Topics API 而导致展示首个广告的时间延迟 | Chrome 正在讨论能否支持在 HTTP 请求标头中使用 Topics 以提高性能。我们依靠测试来了解此类更改是否有必要。 |
| 主题 | 隐私权 / 政策 | 关于在某些第三方与来电者分享其主题的情况下，按来电者过滤回答的问题 | 根据生态系统中许多人的反馈，Chrome 选择了这种设计，只有那些本来无权访问这些信息的用户才能访问此类信息。当然，收到 Topics 信号的发布商和第三方可以自行决定要与网站上的各方共享哪些信息。如果用户进行此类共享，Chrome 强烈建议他们开诚布公地向用户说明此类共享行为，并为他们提供控制权。 |
| 主题 | 文档 | 对包含 FLoC 所用分类器模型和分类详情（例如分类器和分类的更改频率）的文档感兴趣。 | Chrome 已提供了在源试用中使用的分类，而且在 Chrome 代码库中也提供了可将网站归入主题分类的分类器模型（作为开放源代码的一部分）。在源试用过程中，Chrome 保留在收到反馈并收集关于其运行情况的相关经验后对上述任一 API 进行更改。 |
| FLEDGE | 频次上限 | 希望能够控制广告系列或广告组中向每位用户展示的频次。 | FLEDGE 将支持对设备端竞价设置频次上限。对于 FLEDGE 来说，也有一个未解决的问题，可支持内容相关/品牌塑造广告系列。共享存储空间、另一个开发中的 API 和网站专用上限也可用于额外的频次上限控制。 |
| FLEDGE | FLEDGE 对性能的影响 | 有人担心计算密集型出价方参与 FLEDGE 竞价的潜在影响 | Chrome 正与开发者积极讨论这会对网站性能产生的影响。Chrome 欢迎您在测试过程中了解详情。 |
| FLEDGE | 使用其他功能测试 FLEDGE | 将何时以及如何使用其他功能（k-匿名性服务器、键值对服务器等）进行测试。 | Chrome 团队特意分阶段为初始源试用逐步推出功能，以便简化测试。Chrome 了解，为其他功能明确时间表是非常重要的，并会尽可能加以说明。 |
| FLEDGE | 测试协调 | 如何协调多个广告技术平台之间的测试。 | Chrome 正在研究如何提供额外的支持来帮助协调实验，以便不同的广告技术平台针对相同的用户进行实验。这也是推广 Chrome 合作伙伴关系的重点；行业贸易机构也表示有兴趣在其中发挥作用。 |
| FLEDGE | 兴趣组限制 | 用户可加入或参与竞价的兴趣群体数量是否有限制？ | 在测试期间，Chrome 愿意根据反馈和测得的延迟影响，针对网页性能或用户体验方面的原因优化这些限制。测试人员正在讨论让买方和卖方调整资源使用情况的其他方法。 |
| FLEDGE | 跨 API 功能 | 归因报告如何与 FLEDGE 搭配使用？ | 详细信息仍待定，Chrome 预计会在第 2 季度对此进行更新。Chrome 预计会在源试用期间继续提供竞价结果（胜出和落败）的事件级报告。 |
衡量数字广告的效果
| API / 技术 | 反馈主题
（按发生率排序） |
问题和疑虑摘要 | Chrome 响应 |
| Attribution Reporting（和其他 API） | 测试流量 | 担心是否有足够的流量用于测试 | Chrome 将从非常低的流量开始进行源试用，以确保用户控制方面不存在任何严重错误或问题。从技术角度来看，早期测试人员对于确认 API 是否按预期运行发挥着重要作用，这有助于更快地累积到更大流量。一旦确信 API 能按预期运行，Chrome 就会增加源试用的期限，以支持实用性测试。 |
| Attribution Reporting | 用于注册事件的人体工学设计 | 与受支持的活动报名形式相关的问题。 | Chrome 已在 GitHub 上发布回复，阐明目前支持哪些注册形式。Chrome 正在从生态系统中收集有关当前设计的反馈，以了解建议的更改能否充分解决这些问题或是否需要进一步更新。 |
| Attribution Reporting | 噪声生成 | 想详细了解汇总报告如何生成干扰数据。 | Chrome 已在 GitHub 上发布回复，更详细地介绍了系统生成噪声的方式。Chrome 计划提供一个库，用于在 OT 期间模拟噪声并使用一系列参数进行测试。Chrome 还计划针对汇总报告模式提供更多开发者文档和指南。 |
| Attribution Reporting | 小型网站的数据准确度较低 | 担心规模较小的网站或广告系列会收到不够准确的数据。 | Chrome 认识到，基于噪声的隐私保护措施对较小的数据切片的影响更大。不过，诸如汇总较长时间数据之类的方法有可能解决这一问题；也不确定根据非常小的数据切片（例如一次或两次购买）得出的结论对广告客户是否有意义。在源试用期间，Chrome 建议测试人员充分利用各种隐私和噪声参数进行实验，以便就此问题提供更具体的反馈。 |
| Attribution Reporting | 转化延迟对效用的影响 | 担心转化延迟会干扰广告系列的设置和验证或广告系列优化。 | Chrome 就转化报告延迟的影响收到一些自相冲突的反馈。不过，由于 Attribution Reporting API 会在报告方面引入随机延迟，以保护用户隐私，因此 Chrome 预计具体用例或问题在测试期间会变得更加明确，并可能通过额外的调试支持或开发者指南来解决。 |
| Attribution Reporting | 归因回溯期更长 | 请求延长 30 天归因回溯期 | Chrome 已发布一个回答，希望就归因回溯期的跨度提供更多反馈，在将数据最小化和实用性都考虑在内的情况下。 |
| Attribution Reporting | 不可见的展示次数 | 有关浏览型转化报告中是否统计不可见展示的问题。 | 为了更清楚地说明可见展示次数，Chrome 在 GitHub 上发布了一项回答。 |
限制隐蔽跟踪
| API / 技术 | 反馈主题
（按发生率排序） |
问题和疑虑摘要 | Chrome 响应 |
| 用户代理缩减 | 性能 | 存在通过关键 CH 获取提示的延迟时间（在首次加载网页时）的问题。 | Chrome 正在研究提升性能的方法。 |
| 用户代理缩减 / 用户代理客户端提示 | 反欺诈 / 反滥用问题 | 在调试特定类型的攻击（包括拒绝服务攻击）时，提供尽可能多的信息非常重要。丢失 UA 字符串中的某些信息可能会带来挑战。 | Chrome 团队正在讨论和评估保护隐私的方法，同时提供足够的用于调试的信息。 |
| 用户代理缩减 | 对 OT 设置感到困惑 | 多位源试用参与者建议改进文档，并附上有关如何注册源试用的示例。 | 简化版 UA 源试用即将结束，但 Chrome 打算改进弃用试用版的说明（包括将示例演示更醒目）。 |
| 用户代理缩减 | 担心特定提示的值 | 有关 Sec-CH-UA-Model 是否与用户代理字符串中的 <deviceModel> 相同的问题。 | Sec-CH-UA-Model 与用户代理字符串中的 <deviceModel> 相同。Chrome 将尝试在以后的文档中更明确地说明这一点。 |
| 用户代理缩减 | 关于注册弃用试用的疑虑 | 有关如何为大量域名注册弃用试用的问题 | Chrome 在设计弃用试用版时考虑过集中式方法，但 Chrome 认为现有的源试用是最佳选择，因为这会将所有控制权都交由开发者（因为开发者可以选择是否发送标头）。 |
| 用户代理客户端提示 | 担心 UA-CH 的规范性问题 | 正如 rfc7231 中所定义，与 User-Agent 标头提供的灵活性相比，UA-CH 存在过于规范的局面。 | 从最终跨浏览器互操作性和用户隐私保护（通过防止任意添加高熵标识符）的角度来看，Chrome 将 UA-CH 标头的规范性视为 UA 字符串灵活性的重要改进。
不过，如果其他人也有同样的顾虑并想提供反馈，问题仍未解决。 |
| 用户代理客户端提示 | 担心 API 被用于屏蔽某些浏览器 | 担心某个网站正在使用 API 查找“Google Chrome”或“Microsoft Edge”并阻止所有其他浏览器。 | 品牌列表的概念旨在应对这种情况：浏览器除了可以发送自己的品牌外，还可以发送“Google Chrome”。 |
| 用户代理客户端提示 | 请求用于枚举所有受支持提示的方法 | 希望以编程方式了解所有受支持的浏览器提示。 | Chrome 正在评估该功能请求。 |
| 用户代理缩减 / 用户代理客户端提示 | 反欺诈 / 反滥用问题 | 对于 HTTP1 首次加载，客户端提示不可用 | 其中一个 Client Hints Reliability API (ACCEPT_CH) 只能通过 HTTP2 和 HTTP3 使用。对于仍通过 HTTP1 提供服务的服务器，将仅需要依赖关键 CH。 |
| 用户代理缩减 | 对 Chrome（Android 版）的影响 | 关于这对 Android 版 Chrome 有何影响的问题。 | 减少 UA 和 UA-CH 将在 Android 设备上的 Chrome 中推出，而不仅仅是桌面设备。对于 Android 版 Chrome，相关变更只会在“第 6 阶段”（目前已排定在 Chrome 110 中）生效。 |
| Gnatcatcher (WIPB) | 不合规的用途和方法 | 阐明不符合规定的用途和不符合要求的方法。 | Chrome 将会更新铺垫消息，以提供更多详细信息。 |
| Gnatcatcher + 用户代理缩减 | 减少反欺诈信号 | 同时减少 IP 和 UA 访问权限的防欺诈影响。 | 预期会实施“ Willful IP Blindness（IP 盲人）”反欺诈政策规定（允许将 IP 用于反欺诈用例）来消除有关 IP 代理的防御性问题。 |
| 导航跟踪 | 担心未来会发生服务中断 | 广告客户担心设备可能会遭到破坏；身份提供方也表示对 Chrome 的计划感兴趣。 | Chrome 并未做出即将做出的破坏性更改，仍在探索各种用例。 |
| SameSite Cookie | 与其他浏览器互操作 | 关于 Chrome 修复 crbug.com/1221316 计划的问题，因为 Chrome 的实现方式与其他浏览器有所不同。 | Chrome 在指标中发现了一个 bug，并因此采用了新的指标。Chrome 正在收集数据，以便更好地了解修复 bug 的影响。 |
| 存储分区 | 担心对消息通道进行分区 | 关于消息渠道（即SharedWorker 和 BroadcastChannel）进行分区。 | Chrome 正在评估这些反馈，但 Chrome 认为，有必要对消息渠道和存储空间进行分区，以防止隐秘跟踪。 |
强化跨网站隐私边界
| API / 技术 | 反馈主题
（按发生率排序） |
问题和疑虑摘要 | Chrome 响应 |
| First-Party Set | 通用隐私权政策要求 | 我们无法为需要共同涵盖的所有产品和管辖区维护一份通用的隐私权政策。 | Chrome 仍在制定我们的政策要求；我们会参考这些反馈。 |
| First-Party Set | 独立执法实体 (IEE) 可能会收到大量关于 FPS 有效性的验证 | 总结如何确定 FPS 有效性方面的可预见挑战：文本或隐私权政策与组成员不匹配；明确说明了如何定义用户显而易见的组成员资格、带宽和时间方面的挑战，以及与企业结构相关的专业专业知识。 | Chrome 仍在制定我们的政策要求；我们会参考这些反馈。 |
| First-Party Set | 维护浏览器 FPS 列表的流程 | 他们担心：非西方国家/地区的网站设有准入门槛；由于更新频率不同，FPS 列表版本不一致，导致各浏览器版本不一致，以及较小/较新版浏览器使用该列表的能力。 | Chrome 仍在制定列表的政策要求、接受流程和使用权限；我们会参考这些反馈。
Chrome 还会借鉴网络平台上使用的其他静态列表（例如公共后缀列表）的经验 |
| First-Party Set | 各网站动态断言设计 | 动态设计（与静态列表相对）可能更容易出现针对常见所有权的错误断言，以及网页加载延迟/失败。 | Chrome 目前正在开发静态列表方法；如果将来重新评估已签名的断言方法，将会参考此反馈。 |
| First-Party Set | First Party Set 的潜在使用场景（如果可以创建可信且公平的 FPS 列表版本） | 单点登录、可自定义的数据提示，使用户能够增强透明度报告。 | Chrome 会在考虑 First Party Set 的后续步骤时考虑此反馈 |
| 条状标签 | 浏览器兼容性 | 有兴趣了解其他浏览器如何处理分区 Cookie 属性 | Chrome 会继续在公共标准组织（例如 W3C）内开展工作，以确定可跨浏览器使用的设计和实现。 |
| 条状标签 | 设计要求 | 担心添加 __Host- 名称前缀不可行 | Chrome 已撤消源试用的命名要求，并考虑在测试期结束后是否永久保留该源试用。 |
| 条状标签 | 在广告用例中使用 CHIPS | 关于是否可以在广告用例中使用 CHIPS 的问题。 | 利用 CHIPS，第三方可以创建划分到顶级网站（或其第一方集）的客户端 Cookie。如果用例需要分区状态（而不是跨网站状态），则可以使用 CHIPS。 |
| 条状标签 | CHIPS 与 FPS 集成 | 担心无法使用 CHIPS 和其他 Privacy Sandbox 提案（例如 First Party Set）进行测试 | Chrome 正在积极探索如何推动测试环境，以便进行此类测试。Chrome 还发布了 FPS 和 CHIPS 本地测试说明，您可以暂时使用它们。 |
| FedCM | 表现力 | 需要担心的是，由于浏览器呈现联合身份流程的一部分，因此很难捕获 IDP 想要呈现给用户的所有细微差别 | Chrome 深知需要做出这种取舍，并将继续与这个生态系统合作，以便覆盖尽可能多的地区，让它尽可能地发挥表现力。Chrome 正在探索的一些建议包括品牌自定义（例如徽标、颜色）和字符串自定义（例如“访问此文章”而不是“登录”）。 |
| FedCM | 浏览器参与 | 浏览器比以前要更多地参与身份联合流程，因此能够更明确地了解用户登录的是哪些网站（以及使用哪个 IDP）。 | Chrome 认识到浏览器现在扮演了更积极的角色，但这种额外的参与是浏览器在区分和阻止跨网站跟踪的同时仍然支持联合的必要条件。 |
| FedCM | 适用性和互操作性 | 担心其他浏览器不会采用或实施 FedCM。 | Chrome 团队也一直在与其他浏览器供应商合作，在 FedID Community Group 中寻找适合联合的常用解决方案。 |
| FedCM | 各种 API 挑战 | 担心 FedCM 仍处于早期 / 成熟阶段，需要很长时间才能提供生态系统所需的所有功能。 | 在生态系统测试中，Chrome 将进一步探索这一方面。 |
| FedCM | 企业政策和用户控制功能 | 担心是否有任何控件（例如企业政策和/或用户设置）可以让企业保持其联合身份部署而不进行任何更改。许多联合身份的本地部署都极难重新部署 / 更改，因此对需要重新部署新浏览器 API 的阻力非常大。 | Chrome 正在探索适用于企业管理员和用户的各种控件，它认为这些控件可以解决这些问题。Chrome 欢迎企业就特定用例提供反馈意见，以便他们了解这些情况。 |
打击垃圾内容和欺诈行为
| API / 技术 | 反馈主题
（按每个 API 的发生率排序） |
问题和疑虑摘要 | Chrome 响应 |
| Trust Token API | 兑换限额 | 担心每个网页上最多包含 2 个限制条件过于严格，特别是对于可能在同一网页上多次嵌入同一网页，或在组织内拥有第二个颁发者域名的情况。他们很可能在没有考虑其他市场参与者的情况下，达到上限。 | 如果能提高采用率，Chrome 愿意略微放宽每个网页的兑换限额，但需要将限额保持在相对较低的水平，才能引入过多的熵。此外，缓存兑换记录可减少一个发卡机构在短时间内为单个用户兑换多个令牌的需求。 |
| Trust Token API | 延迟时间 | 通常需要在 10 毫秒或更短的时间内响应出价请求，因此，如果在首次加载网页时兑换令牌，那么您几乎不可能将其纳入到出价前无效流量决策中 | Chrome 正尝试通过测试来了解延迟时间对出价前用例的影响。 |
| Trust Token API | OpenRTB 采用 | 对于出价前用例，务必要将兑换的令牌信息传递给 SSP 和 DSP，以用于广告决策 | Chrome 愿意与 IAB 开展合作，以帮助确保所有有用的防欺诈/防滥用信号都可以通过 openRTB 传播，但他们拥有添加所有新默认字段的标准。 |
| Trust Token API | 隐私权 | 关于任何形式的跨网站数据传播的长期可行性的问题，尽管熵较低（约 2.5 位） | Chrome 拥有强大的用户保护机制（可避免唯一用户标识），Chrome 认为生态系统接受度是很好的理由。Chrome 团队与主要利益相关方密切合作，以确保其长期可持续性。 |
| 平台认证信号 | 判断对新创意/提案的兴趣 | 对各种可行（和不可行）的信号提供强有力支持，例如传达平台可以提供的设备完整性信号 | Chrome 计划将此想法纳入 W3C 反欺诈社区小组，作为收集反馈的新想法。 |
| 值得信赖的服务器防欺诈 | 判断对新创意/提案的兴趣 | 概念有趣，但可能需要对适用的用例进行更多调查 | 根据感兴趣的程度，Chrome 可能会就这一概念进一步构思，并编写成用于提供未来生态系统反馈的说明。 |