2023 年第 1 季度的季度报告，其中总结了生态系统对 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 API 和 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 响应 |
|---|---|---|
| 测试和试验 | 测试的相关性，用于在测试开始前未完成 Privacy Sandbox API，从而告知 CMA 的评估 | Privacy Sandbox API 的开发工作稳步推进。
这些测试已在源试用中提供，可用于测试，并在今年夏天全面推出。 此外，我们还阐明了在 2026 年之前不会受到影响的功能（例如 FLEDGE 事件级报告、使用 iframe 进行 FLEDGE 呈现）的时间表。 我们鼓励生态系统测试这些 API，并根据在第三方 Cookie 被弃用后测试人员预计将依赖的内容向 CMA 提供反馈。这有助于他们评估弃用第三方 Cookie 可能产生的影响。 |
| 用户控制功能 | 就 Privacy Sandbox API 对用户控制的影响向生态系统提供了明确指导 | 我们无法就生态系统可以使用哪些用户控制功能提供法律建议。与此同时，Chrome 正在尝试向一小部分用户显示更新后的 Privacy Sandbox（“增强型广告隐私权”）用户控制功能，以持续改进 Privacy Sandbox 技术。这些更新包括更清晰、更实用的语言和布局。Chrome 评估这些优化措施并确定是否将其推广到更多用户后，便可与生态系统分享更多信息。 |
| 数据泄露 | 如果浏览器遭到入侵，第一方数据泄露给 Google 和其他方的风险 | 我们的 FLEDGE 说明明确指出，某个广告技术平台的数据仅与该广告技术平台共享（与其 Worklet 或可信服务器共享），或者由该广告技术平台明确共享（例如，买方向卖方显示他们想要展示的广告网址）。唯一的例外情况是 k-匿名性检查必须由全球集中式服务器完成，我们会在该领域继续投入大量资源。如需详细了解我们如何看待隐私权，请参阅 K-匿名性说明文档。 此外，对于 k-匿名性服务器的设计中采用的广告技术保护措施如何运作，我们非常乐意提供更多详细信息。 |
| 其他讨论论坛 | 申请为 W3C 设立额外的论坛，供非技术生态系统玩家分享反馈 | Privacy Sandbox 反馈表单适用于一般和特定评论（包括技术和非技术意见）。 Improving Web Advertising Business Group 是一个可通过每周通话和 GitHub 代码库进行讨论的论坛。 developer.chrome.com 上的 Privacy Sandbox 反馈页面介绍了其他用于提供反馈和参与讨论的机制。Chrome 还会继续举办公开咨询交流时间等活动，以促进问题和内容共享。此外，Chrome 在过去一个季度组织或参加了十几场行业活动。 |
| 时间表说明 | 关于 2023 年第 3 季度正式发布的确切日期的说明 | 根据 PrivacySandbox.com 上发布的时间表，正式版的目标是从 Chrome 115 版本开始发布。 |
| reCAPTCHA | Sandbox API 对 reCATPCHA 垃圾内容检测用例的影响 | 我们会定期从 reCAPTCHA 获得反馈，以确保 Privacy Sandbox 提案不会对网络安全或欺诈行为产生重大影响。他们正在制定自己的计划，为弃用第三方 Cookie 做好准备并做出调整，因此他们最适合解决这一问题。 |
| Chrome 扩展程序 | Privacy Sandbox 技术（例如防隐蔽跟踪 (ACT) 措施）是否适用于 Chrome 扩展程序？ | 我们尚未发布任何关于 ACT 是否适用于 Chrome 扩展程序的公告。但是，如果某项技术以暗中方式收集用户信息，这不符合我们的隐私权原则。 |
展示相关的内容和广告
主题
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| TAG 设计审核 | TAG 发布了 Topics 早期设计审核。 | 我们会一如既往地致力于 Topics，并在最新更新页面和本期中分享了我们对 Topics 承诺的最新动态。 我们逐条回复了 TAG 审核，并在此分享我们的宏观愿景。 Topics API 将继续作为广告生态系统在 2023 年应测试的 API 集合的一部分，我们希望收到的测试反馈和我们获得的实现者经验能够为将来实现跨浏览器标准这一领域所做的努力提供宝贵的贡献。我们期待继续与整个生态系统合作，探索如何简化可能的过渡，让 Topics API 可以成为商定的具有跨浏览器兼容性的标准。 |
| 使用主题的方法 | 支持 Chrome 在开发 Topics API 时采用的开放式方法 | 我们非常珍视您的想法，并期待继续与行业团体合作，开发能够为整个生态系统提供价值的 Topics API。 |
| （2022 年第 3 季度也有报告） 主题分类不够精细 |
宽泛的主题分类不包含更精细的主题，包括特定区域的主题。 | 第 1 季度更新： 我们正在持续改进分类，第 2 季度，我们将发布 Topics API 的更新分类。为了制定这种新的分类法，我们与整个生态系统中的公司密切合作。 我们正在积极寻求关于对生态系统最有用的分类的反馈。在评估是否增加主题数量或包含更精细的主题时，需要考虑一些因素，包括 1) 可能会对隐私造成的影响（更多主题可能会导致数字“指纹”收集风险）以及 2) 检索之前观察到的主题（例如，如果主题越多，广告技术平台过去看到所选主题的可能性就越小）。 |
| （2022 年第 4 季度也进行了报告） 对第一方信号的影响 |
主题信号可能具有很高的价值，因此会降低其他基于兴趣的第一方信号的价值。 | 我们认为针对用户兴趣投放广告是一个重要的网络用例，而 Topics 就是为了支持这种用例。我们知道，一些大型发布商担心 Topics 会对其第一方数据策略产生负面影响。我们期待进行生态系统测试，该测试能够让您深入了解 Topics 对发布商的影响。 |
| 与 Google Ads 无关的 Topics 用例 | 将 Topics 用于展示针对用户兴趣的广告以外的用途 | Topics 旨在满足针对用户兴趣投放广告这一用例的需求，我们认为，这对于免费开放网络来说是一个关键用例。我们目前正在寻求有关其他用例的反馈，并且正在进行评估。 |
| 默认启用状态 | 地区法律对 Topics 意见征求默认值的影响 | 我们无权对法律意见发表评论。 |
| （2022 年第 3 季度也有报告） 网站分类错误 |
在指定网站的主题分类错误时进行广告定位 | 第 1 季度更新： 第二季度，我们将宣布推出经过更新的 Topics API 分类器，并期待与该生态系统展开合作。 根据当前反馈，我们会综合运用人工挑选的替换列表（包含最热门的网站）和设备端机器学习模型，对网站进行分类。Chrome 会继续评估可供网站用于 Topics 分类的选项。任何实用程序改进都必须权衡隐私和滥用风险。例如，一些风险包括：网站使用自我标记这一方法将不同（可能敏感）的含义编入主题中；网站为谋取经济利益而虚假陈述其主题；网站攻击主题以掩盖其对他人的用处（例如，对用户的主题发布无意义的垃圾内容）。 公众可以使用通过 chrome://topics-internals 或此 Colab 提供的工具检查这些组件。我们希望通过测试不断改进分类功能，欢迎大家提供反馈，告诉我们分类可能有误的网站示例。 |
| 主题分类器 | 请求返回额外信息，以显示出于调试目的向调用方返回“No Topics”的原因 | 我们理解并认可，调试工具对开发者来说很实用，因为他们致力于将 Topics API 集成到他们的系统中。但是，如果公开其他信息（例如未返回任何 Topics 的原因），我们可能会在无意之中分享信息，让各方能够发现额外的详细信息（例如，如果用户处于无痕模式、已停用 API 等等），从而损害用户隐私。虽然目前我们不打算提供其他调试工具，但也欢迎您就哪些工具有价值提供反馈。 |
| 私密信息检索 (PIR) | 请求 Topics API 采用私密信息检索功能 | 我们之前已针对 PIR 进行了调查，并在此分享了一些取舍权衡。 |
| 出价信息流 | 在出价流中，主题表示不同于卖方定义的受众群体吗？ | Topics API 是由 Chrome 开发的 Privacy Sandbox 提案，有别于 IAB Tech Lab 的卖方定义的受众群体提案。我们希望两者在出价流中不同。了解 Topics 在 OpenRTB 出价请求中的表示方式。 |
Protected Audience API（以前称为 FLEDGE）
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| FLEDGE 功能可用性 | 阐明了 FLEDGE 功能（例如围栏框架强制执行、K-匿名性等）的测试和实现时间表。 | 我们发布了一篇博客文章，介绍了各种 FLEDGE 功能以及何时支持这些功能。随着我们不断开发 FLEDGE，欢迎您就本公告提供其他反馈。 |
| 商品呈现限制 | 请求放宽针对 FLEDGE 围栏框架的“由多个部分构成的广告”限制 | 正如我们在 2 月份所宣布的那样，至少在 2026 年之前，用户仍可以使用围栏框架，并且 urn-iframe 将支持 iframe 行为。欢迎就这一主题展开进一步讨论。 |
| 可伸缩性问题 | 随用量变化而变化的 FLEDGE 性能 | 我们正在积极跟进反馈，并了解更多背景信息，以便提供切实可行的解决方案。第一步是将反馈分为两类，并做到了以下几点：
|
| （2022 年第 3 季度也进行了报告） 出价逻辑的可见性 |
担心 DSP 出价逻辑将在 JavaScript 中显示 | 问题 1 更新： 我们分享了一项提案，该提案将限制攻击者以探索性（强制浏览）方式向服务器请求数据的能力，我们欢迎生态系统参与者分享他们对该提案的反馈或支持。 |
| 测试难度 | 让小型 DSP 能够正确测试 FLEDGE，并降低广告主只有兴趣通过大型 DSP 进行测试的风险 | 我们致力于与小型 DSP 合作，并强烈建议在 FLEDGE 正式版推出后，在 DSP 和各种规模的广告主之间扩大测试范围。我们非常希望了解我们可以如何以最佳方式协助他们与生态系统中的其他组织一起测试 FLEDGE，也欢迎您提出一些想法并付出行业努力，以激励广告主使用较小的 DSP 进行测试。 |
| 动态再营销 | 在弃用第三方 Cookie 后，FLEDGE 仍可使用动态再营销吗？ | 我们正在考虑如何回答这个问题，欢迎生态系统参与者分享更多关于他们打算如何使用动态再营销的见解。 |
| 欺诈/滥用 | 生态系统如何降低风险并阻止不法分子或买方将自己定位为理想受众群体？ | 我们期待与生态系统参与者就欺诈和滥用行为进一步互动，并欢迎您在这方面提供更多反馈。 |
| 用户偏好设置 | 保存用户偏好设置并用于广告选择的流程 | 对于特定广告，相关广告技术平台是最有利的一方，可以控制展示哪些广告素材或选择广告素材的方式。 |
| 定量测试方案 | 为了确保定量测试的公平性，应该针对不使用第三方 Cookie 的流量或仅使用 FLEDGE 的 SSP 的流量进行测试？如何避免混合使用来自第三方 Cookie 的信号？ | 我们非常感谢这些反馈，并将与 CMA 合作设计实验，以可靠地了解弃用第三方 Cookie 以及推出 Privacy Sandbox 提案对生态系统的影响。我们鼓励直接与 CMA 分享对 CMA 的定量测试方案的其他反馈。 |
| 文档更清晰 | 请求提供有关竞价配置的更清晰的文件 | 我们希望在未来几周内分享一篇博文，进一步介绍 FLEDGE 竞价报告。 |
| 并行处理 | 出价和竞价 (B&A) 服务是否支持并行处理？ | 使用出价 / 竞价服务器的广告技术平台可以启动多个可并行提供结果的服务器。 |
| 滥用缓解措施 | 使用私密状态令牌的 FLEDGE k-匿名性服务器是否足以确保用户隐私？ | k-匿名性的动机不太在意微定位，而是更注重在 FLEDGE 允许事件级报告的临时阶段建立一些后盾。我们分享了更多想法，欢迎其他反馈。 |
| ES 模块冲突 | 请求将 generateBid 作为全局函数丢弃，因为它与 ES 模块冲突 |
我们正在讨论此请求，欢迎您提供其他反馈。 |
| 组件竞价 | 要求发布商对竞价设计有更多掌控权 | 出价和竞价计划支持组件竞价，就像 Chrome 设备端竞价一样。 |
| B&A 时间表 | 明确向有兴趣测试 B&A 服务器的广告技术平台的时间表 | 我们刚刚更新了 B&A 说明，并更新了“时间轴”部分，在符合 CMA 要求后，添加了对 Chrome-B&A 测试不同阶段的时间表的明确定义。 |
| 超时控制方案 | 增强目前可用于 FLEDGE 的超时控制方案 | 这是一项很有趣的提议。我们会将此 API 加入待研究的提案队列中，并报告我们的开发进展。 |
| 广告素材出价流 | 能够根据广告素材查看和过滤胜出的出价 | 这是一项很有趣的提议。我们会将此 API 加入待研究的提案队列中，并报告我们的开发进展。 |
reportWin |
提议在 reportWin 函数中提供有关其他兴趣群体所有者（而不是胜出者）的最高出价信息 |
这是一项很有趣的提议。我们将考虑在汇总报告中添加其他信号，欢迎您点击此处提供其他反馈。 |
| 事件类型 | 在与 FLEDGE 集成时，跨衡量 API 实现事件类型标准化 | 这是一项很有趣的提议。我们会将此 API 加入待研究的提案队列中，并报告我们的开发进展。这将需要与我们在该领域更广泛的工作进行协调，因为这会影响 FLEDGE 以外的其他 Privacy Sandbox API。欢迎您在此处提供其他反馈。 |
| 事件级报告的长期解决方案 | 希望在第三方 Cookie 弃用后，仍保留某些数据（例如 highestScoringOtherBid） |
正如我们在 2 月的博文中所分享的那样，事件级竞价胜出报告将支持至少到 2026 年。目前，我们无法分享更多详细信息，但欢迎您就为什么在弃用第三方 Cookie 后保留某些数据至关重要提供进一步的反馈。 |
| 兴趣组限制 | 源站可以向其中添加单个浏览器的兴趣群体数量上限是多少？ | Chrome 允许每个所有者最多 1,000 个兴趣小组，最多 1,000 个兴趣小组所有者。这些是为了保障安全，不会在常规操作中遭到命中。 |
| 事件级信号 | 支持提案包含 generateBid 和 reportWin 的事件级信号，这些信号可用于机器学习训练 |
我们已在此处分享针对浏览器设计的信号和广告技术平台定义的信号的决定，并欢迎您提供其他反馈。 |
| 出价脚本 | 在出价脚本的网址中添加用户 ID。 | 这是不可能的，因为 FLEDGE 还额外要求，兴趣群体所有者、出价脚本网址和呈现的广告素材的元组必须保持 k-匿名化才能展示广告。 |
| K 匿名性强制执行 | 是否对 (componentAd, size) 对强制执行 k-匿名性？ | 会的。请参阅 turtledove/issues/312。 |
| 出价和竞价服务要求 | B&A 服务如何为参与者与设备端 FLEDGE 集成以及其他与 B&A 服务集成的参与者提供支持？ | 设计仍在最终确定，欢迎您点击此处提供其他反馈。 |
| 浏览后归因 | 是否支持浏览后归因？ | 目前，我们对可见度还没有任何标准定义，而是依靠广告素材本身来标记观看事件。请参阅 turtledove/issues/452。 |
| 相似细分受众群定位 | Privacy Sandbox 能否支持“类似受众群体定位”？ | 我们在此讨论用例，欢迎您提供其他信息。 |
| 实时监控 API | 关于实时 FLEDGE 监控方法的建议 | 我们正在讨论此方案，欢迎您点击此处提供其他资料。 |
| FLEDGE 报告 | reportWin 和 reportResult 应按随机顺序生成，以免漏报或漏报。 |
卖方必须先执行 reportResult()，然后买方执行 reportWin()，这样，来自 reportResult() 的卖方信号才能包含在 reportWin() 中。如需了解详情，请参阅说明。 |
| 自定义关键值 (K/V) 服务器 | 未来是否支持自定义 K/V 服务器？ | 我们正在讨论该问题，欢迎您提供任何其他信息。 |
| 顶级竞价 | 是否必须是广告服务器才能运行顶级竞价机制？ | FLEDGE API 未指定哪一方必须调用它；FLEDGE 的设计中没有这方面的要求。任何人都可以参与 FLEDGE 竞价（包括多卖方竞价）。正如 2022 年第 4 季度的报告中所述，FLEDGE 允许每个发布商选择竞价结构，包括顶级卖方和组件卖方的选择。 |
| API 范围 | FLEDGE 是否打算处理第一方数据？ | 我们将于 2023 年第 2 季度发布内容，阐明第一方数据确实可用于 FLEDGE，以便 1) 用作确定兴趣群体成员资格的逻辑，以及 2) 作为用户出价信号提供数据，以便在后续的出价逻辑生成中使用。 |
| 跨网域兴趣群体 | 可以创建跨网域兴趣群体 | 将浏览器添加到兴趣组时可用的任何信息都可用于通知该受众群体。逐步淘汰第三方 Cookie 后，可用于生成兴趣群体的跨网站数据将会受到限制。 |
| 客户端出价逻辑 | 将现有服务器端出价逻辑移植到客户端 | 我们有兴趣详细了解携号转网过程中哪些方面具有挑战性或目前欠缺，欢迎您提供任何其他反馈或见解。 |
| K/V 服务器值 | K/V 服务器值必须为字符串类型吗？ | 值必须是字符串，但它们可以在 JSON 或协议缓冲区中存储对象，并将它们序列化为字符串。 |
| 广告客户屏蔽名单 | 如需为买方提供广告客户屏蔽名单，应使用以下哪些信号？ | 适当的位置位于 auctionSignals 或 perBuyerSignals 中。 |
| 出价单位 | 支持不同的出价单位，例如每次安装费用和每千次展示费用 | 鉴于当前设计，我们希望详细了解为什么需要这样做，并且期待收到更多反馈。 |
| 竞价逻辑 | 是浏览器还是广告服务器来决定竞价的胜出者？ | 所有胜出者选择均在沙盒内执行，所有决策均由卖方的代码做出。浏览器只是提供一个封闭的私密环境，买方和卖方代码都在其中运行。 |
| 权限政策 | 源试用结束后，当前的 FLEDGE 权限政策是否会继续强制执行？ | 对于源试用，这两项功能的当前默认许可名单都是临时的，并且会发生变化。我们希望了解广告技术平台需要为这项变更做好准备多长时间，之后才会开始实施这项变更。 |
| 信号规模限制 | 可信出价信号请求将在具有相同 trustedBiddingSignalsUrl 的多个兴趣组合并；2 MB 的大小限制是一种限制条件。 |
存在针对设备端调用方的限制条件，用于防止设备上的资源过载。B&A 服务器的调用方将受到更宽松的限制条件。 |
| 报告信号 | 添加额外的信号，即脚本错误，以允许检索每个兴趣群体所有者和每个 computeBid 或 reportWin / reportResult 的客户端错误数量。 |
我们正在考虑此方案可能存在的隐私问题，欢迎生态系统参与者分享更多见解，告诉我们为什么需要这样做。 |
| K-Anon 窗口大小 | 从当前的 7 天上限扩大 K-Anon 时间范围。 | 我们正在考虑此问题，目前正等待（也欢迎）生态系统贡献更多反馈。 |
| 在不同设备上的效果 | 如果用户属于大量兴趣群体，FLEDGE 如何处理设备性能？ | 在 SSP 和 DSP 之间，FLEDGE 提供了多个超时、优先级和限制选项，使广告技术平台能够精细控制设备性能可能是设备属于大量兴趣群体时限制竞价参与的原因之一。 |
| B&A 服务测试 | 请求生态系统玩家在测试阶段使用自己的服务器，以便有更多日志可用于调试 | B&A 允许用户从已获批准的云服务提供商启动和扩缩服务器。为了保护用户隐私，我们在可信执行环境 (TEE) 中强制执行执行。我们即将发布有关 B&A TEE 调试的说明，并且正在开发支持此功能的功能。我们正在寻求关于该主题的更多反馈。 |
| 法规要求 | FLEDGE 是否会与不同国家/地区的云服务商合作，以支持遵守当地法规要求？ | 我们随时欢迎其他云提供商提供建议，但目前我们计划至少在强制执行第三方 Cookie 弃用时支持 GCP 和 AWS。如需了解详情，请参阅此说明。 |
衡量数字广告
Attribution Reporting（和其他 API）
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 噪声影响数据分析 | 关于如何执行数据分析以了解噪声影响的指南 | 我们分享了有关噪声和设计决策的其他文档，这些内容可用于更改噪声对广告技术数据的影响。 我们还提供了更详细的指南。 |
| Null 报告 | 阐明 null 报告的实现 | 我们目前正在制定实现 null 报告的方案，很快就会有更多详细信息分享。实现 null 报告有助于我们减少报告延迟，同时又不侵犯隐私。 |
| 噪音等级 | 根据归因回溯期时长调整噪声等级 | 我们欢迎这种方案，并正在考虑将其添加到规范中。我们欢迎您在此处提供其他反馈。 |
| 触发器数据大小 | 为什么触发器数据大小限制为 3 位？ | 该大小被限制为 3 位和 8 个不同的值，以确保有关用户的跨网站/上下文信息量是有限的。我们欢迎生态系统参与者提交反馈，以了解当前的事件级报告参数化是否合理。 |
| 事件级报告触发器 | 允许在重复信息删除键内设置优先级 | 我们正在探索此问题的解决方案，欢迎您提供其他资料。 |
| 调试支持 | 明确说明弃用第三方 Cookie 后的调试 | 我们希望在第三方 Cookie 被弃用后支持调试，并正在考虑相关选项。我们期待更多反馈和想法。 |
| 点击型转化的替代方案 | 请求获得更多指导，了解点击型转化的替代方案 | 我们鼓励生态系统在适用的转化衡量用例中使用 Attribution Reporting API 作为持久的私有衡量系统。还有其他替代方案，并且广告技术提供商将需要根据其所需的隐私保护和实用性需求来决定适当的解决方案。 |
| 结算使用场景 | 明确归因报告在多大程度上支持基于转化的结算用例 | 我们正在努力公开发布相关信息，以阐明 Attribution Reporting API 在结算方面的作用。Attribution Reporting API 最初并没有直接支持 CPA 结算，而是支持 CPC 和 CPM 结算，后者是大多数广告技术平台使用的结算结构。 未来如果有其他生态系统反馈，我们可能会支持这项功能。 |
| 用例支持 | Measurement API 用例文档 | 我们正努力阐明所有 Privacy Sandbox 报告界面的文档。 |
| 点击质量 | 请求添加信号，以区分广告获得的有意点击和意外点击 | 我们正在讨论此要求，欢迎您提供其他资料。 |
| 效果衡量解决方案 | 支持跨多个 DSP 的衡量解决方案 | 衡量服务提供商可以使用 Attribution Reporting API 在多个 DSP 之间进行重复数据删除。此外，我们还提议支持 attributionsrc 中的网址列表，以便 DSP 更轻松地支持衡量服务提供商 Attribution Reporting API 请求。欢迎就上述方案提供任何其他反馈。 |
| 事件级报告 | 请求在多少天内直接发送报告 | 广告技术平台已可以使用当前可用信息计算出此请求。我们尚未收到生态系统中的其他有关此请求的反馈，但欢迎您就该要求提供反馈。 |
source_registration_time |
在事件级归因报告中添加了 source_registration_time。 |
我们正在考虑这项请求，欢迎您就生态系统玩家是否认为这项实用功能提供更多反馈。 |
| 隐身模式 | 当用户处于无痕模式时，衡量解决方案是否可用？ | 不可以，当用户处于无痕模式时，无法使用效果衡量解决方案。在无痕模式下，第三方 Cookie 默认处于关闭状态。 |
| 数据净室 | Measurement API 是否与净室兼容？ | 典型的数据净室是一种环境，在这种环境中，来自不同来源的个人标识符数据会上传到数据库中，以基于底层数据的合并来运行分析。Privacy Sandbox API 的两个衡量框架分别是事件级报告和摘要报告。事件级报告确实包含广告技术平台提供的事件 ID，可在数据净室中使用，但关联的转化端信息将有限且杂乱无章。加密的可汇总报告不能直接在净室中使用，但汇总服务提供的摘要结果可以作为您的分析的输入或补充信息。 |
汇总服务
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| （2022 年第 4 季度也进行了报告） 报告延迟 |
预计的报告延迟是多长？ | 2023 年第 1 季度更新： 根据合作伙伴的反馈，我们分享了缩短延迟 和减轻延迟影响的提案。 在 WICG 调用期间，广告技术平台都支持这两种提案。 |
| 无重复规则 | 如果具有相同共享 ID 的可汇总报告已处理完毕，您如何处理“延迟的可汇总报告”？ | 我们分享了一项提案，旨在通过在可汇总报告的共享信息中添加额外的报告延迟以及汇总服务的共享 ID 定义，在一定程度上解决汇总 API 延迟损失带来的影响。我们欢迎大家对此提案提供反馈意见。 |
| 数据处理 | 使用隐私预算请求在尊重差分隐私的同时支持多次数据传递 | 我们正在讨论通过更灵活的隐私预算使用方式来支持此用例的可能性，欢迎您提供其他反馈。 |
| （2022 年第 2 季度也进行了报告）查询工效学设计 | 启用查询键聚合。 | 2023 年第 1 季度更新： 我们仍在考虑功能请求，但目前没有可分享的提案。 |
| 源试用限制 | 阐明汇总服务的范围，例如目前不适用于源试用的“不重复规则”。 | 我们正在考虑更新我们的文档，以阐明源试用和正式版将提供哪些功能。 |
Private Aggregation API
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 不公开汇总贡献预算 | L1 贡献预算的限制过于严格。 | 对 Private Aggregation API 的每次调用都称为一次贡献。为了保护用户隐私，可向个人收集的信息量是有限的。 对所有汇总键的所有可汇总值求和时，总和必须小于贡献预算。 根据当前设计，我们对特定报告来源在过去大约 24 小时内（滚动时间段）的贡献设定了限制。这就是反馈中提到的 L1 贡献预算。我们建议开发者根据预期数量（即，不要只使用 1 值）调整其贡献的值。因此，较为常见的事件应使用较小的值以避免用尽预算。 目前，我们正在寻求关于 Private Aggregation API 的贡献预算在数字边界和范围方面的一些反馈。我们正在考虑将范围从每个源站移至每个网站，并将现有范围移至每日边界大于 10 分钟的窗口。 |
限制隐蔽跟踪
用户代理缩减/用户代理客户端提示
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| UA-R 采用情况 | 在英国排名前 10,000 的网站中，只有 1% 使用程序化广告的网站正在发送 HTTP 客户端提示。尚未迁移的 DSP 可能会影响防欺诈功能。 | 在分析同一数据集后，我们发现，如果通过 HTML <meta> 标记和 JavaScript API 考虑 UA-CH 的使用，使用 UA-CH 的网站数量会显著高于反馈中提供的 1% 这一数字。根据这一点以及生态系统反馈等其他事实，我们有信心按照发布的时间表逐步推出减少 UA 的第 6 阶段，同时通知 CMA。我们注意到，网站已有将近两年为过渡做好准备的时间，对于尚未做好准备的网站，我们仍可进行弃用试用。 |
| 关于其他外形规格的提示 | 请求 UA-CH 以提供其他外形规格的设备，例如电视、VR | 我们欢迎这种方案，并正在考虑将其纳入设计中。我们欢迎您提供其他反馈。 |
| 自动测试 | 请求在 UAR 第 6 阶段发布之前解决无头 Chrome 中的 UA-CH 错误 | 相关 bug 已修复。 |
| iOS 对 UA-CH 的支持 | 一家依靠精细的 UA 信息来显示广告用例的网站指出，iOS 版 Chrome 不受支持。 | 对于非 Safari iOS 浏览器（包括 iOS 上的 Chrome），WebKit 项目需要先添加对 UA-CH 的支持，然后才能启用它们（因为它们控制网络堆栈）。 |
IP 保护（以前称为 Gnatcatcher）
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| （在第 4 季度中也进行了报告）地理定位用例 | IP 保护可能会阻止未来的合理地理定位用例，例如基于地理定位的内容个性化。 | 与 2022 年第 4 季度相比，我们的回应保持不变： “我们会与利益相关方通力合作，确保 Chrome 继续为正当的 IP 地址使用情形提供支持。我们希望了解有关 IP 地理定位粒度的生态系统反馈。” |
| 法规遵从 | 如果某个区域的人口不到 100 万，目前的 IP 保护阈值（100 万）会阻止网站使用 IP 地址来满足法规遵从要求。 | 我们正在与利益相关方合作，确保 Chrome 继续为正当的 IP 地址用例提供支持。我们正在寻求生态系统方面的反馈，希望了解 IP 保护方面的合规性。 |
| 滥用缓解措施 | 各方可以通过与其他方共享未遮盖的 IP 地址来规避 IP 保护。 | 我们知道，当前的 IP 保护提案在技术上可能无法阻止各方与其他方共享未遮盖的 IP 地址。我们正在制定缓解措施，以避免出现这种滥用风险。 随着我们不断完善该提案，我们希望提供更多反馈和讨论。具体而言，我们希望了解各方认为需要与其他方共享未遮盖的 IP 地址的任何用例。 |
| 网络屏蔽 | 各方可以使用 IP 保护代理规避网络屏蔽。 | 对于这种情况，执行屏蔽的实体将需要停用 IP 保护。我们已解决了此问题，欢迎您提供其他反馈。 |
| 受 IP 保护提案影响的 IP 地址屏蔽名单 | 许多广告技术公司使用基本的 IP 地址屏蔽列表（如 TAG 数据中心 IP 列表），以防止对极有可能具有欺诈性质（或至少无法变现）的广告资源出价。如果广告技术平台也是跟踪器且可能受到 IP 保护提案的约束，则该公司可能无法在购买广告资源之前对广告进行基本检查。 | 我们鼓励您就 IP 保护提案中潜在问题和解决方案提供更多反馈和展开讨论。一种方案是将类似的此类列表应用于 IP 保护，这样我们就不会代理来自先前标记的 IP 地址的客户端。 |
强化跨网站隐私边界
First-Party Set
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| （已在第 4 季度报告）网域限制 | 请求增加关联网域的数量 | 与 2022 年第 4 季度相比，我们的回复保持不变： “我们在 WICG 通话中已澄清，Chrome 致力于提供兼顾用户隐私兴趣的可用解决方案。为此，我们衷心希望感谢社区就可能受网域限制影响的特定用例提供反馈，以便团队能够考虑如何解决这些问题，同时继续保护用户隐私。” |
| 其他 FPS 提交内容 | 关于提交适用于 FPS 的全局列表的其他方法的建议 | 目前，我们正准备在 Chrome 中提供 First-party Set (FPS)，并设置一个集中式 GitHub 代码库来接受集合提交。我们希望 FPS 能够弥补现有网络平台解决方案的不足，为弃用第三方 Cookie 做好准备，因此我们希望通过这些解决方案了解网站作者是如何利用 FPS。随着集合列表不断增加，并且生态系统适应第三方 Cookie 之后的时代，我们也可以成熟的流程，使我们可以考虑采用替代的分散式方案，例如提出的方案。在当前流程中，我们预计会设定设定的生命周期，这将让我们能够不断改进接收流程。待提交流程成熟后，我们可以重新考虑这个想法。 |
| 代码库审核 | 对 FPS 提交代码库进行社区审核，以防止滥用。不法分子很容易导致使用 burner 源建议集的过程不堪重负，而且过多的请求可能会影响真正集提案的操作。 | 我们会尝试依靠技术验证检查，让检查尽可能客观。我们认为这是扩展提交流程的最可扩展方法。为了实现这一目标，我们还将努力确保该流程能够灵活应对垃圾内容 / 燃烧器提交。 |
| 关联的子集 | FPS 能否通过关联子集为第三方供应商/SaaS 流程用例提供支持？ | 第三方供应商 / SaaS 流程不属于 First-party Set 考虑范围。欢迎提供有关跨网站 Cookie 如何用于这些用例的更多反馈。 |
| FPS + CHIPS 集成 | 请求集成 FPS + CHIPS 以支持 A/B 测试等用例 | 我们正在讨论此用例，也考虑在 WICG 通话中对此进行进一步讨论，欢迎您点击此处提供其他意见。 |
| GDPR | 建议根据 GDPR 概念来建模的新 FPS 子集 | 我们在内部讨论了此方案，并对照收到的其他反馈以及我们的隐私保护目标进行了权衡。我们提供了答案，解释了我们这次不执行该方案的原因。 |
| 内存 | 纳入 FPS 列表后浏览器内存大小的预期变化 | 曾有过让浏览器以最小内存影响存储这类列表的先例，例如“断开连接跟踪保护列表”。虽然 First-party Set 列表将复制到每个 Chrome 客户端，但我们会继续监控文件大小，并确信可以优化内存占用。 |
Fenced Frames API
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 围栏框架限制 | 阐明围栏框架施加的限制 | 3 月份，我们更新了有关围栏框架的说明，其中提供了有关其功能的信息。欢迎提供其他反馈。 |
| 展开访问权限信息 | 请求扩展对相邻帧相关信息的访问权限 | 我们希望进一步了解为什么生态系统必须这样要求，并欢迎您提供任何其他反馈。 |
| 围栏框架和 iframe | 关于围栏框架和 iframe 之间的功能对等的问题 | 所有可用的 Privacy Sandbox API 和报告都能够以同样的方式用于 iframe 和 FencedFrame。 |
| 调整围栏框架的大小 | 限制帧大小变更会影响某些用例。 | 我们有兴趣详细了解受此限制影响的用例类型，欢迎您提供更多反馈。 |
共享存储空间 API
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 第三方 Worklet | 第三方是否可以向共享存储空间写入数据（按源进行分区）？或者调用其他 Workerlet 进行第三方衡量？ | 执行代码的浏览上下文的来源决定了将数据写入哪个共享存储空间。将第三方代码添加到网页中后，第三方代码可嵌入为具有自己的浏览上下文的 iframe，从而使第三方代码能够写入其来源。第三方代码还可作为脚本（而非 iframe）嵌入，后者不会切换浏览上下文，并且第三方可以向嵌入器的共享存储空间写入数据。请注意，只有该共享存储空间的所有者才能从该共享存储空间读取数据。 |
| 去重功能 | Chrome 生态系统之外的互动无法进行重复信息删除。 | 共享存储空间用于在 Chrome 中提供基于 Chrome 浏览器的唯一覆盖面输出。我们有意与广告技术平台合作，了解如何将这些输出用作其更广泛的覆盖面模型的一部分。我们知道，输出本身可能只涉及部分互动，并且有意与广告技术平台合作，探索可叠加在顶层的其他建模方法。 |
| 转化回溯期 | 请求设置转化率回溯期，以便查看转化次数随时间的变化 | 这可以通过使用共享存储空间在客户端处理各种转化路径来实现。通过安全的未分区浏览器存储空间，您可以更灵活地进行高级分析。 |
| 商品过期时间 | 申请将过期时间延长至 90 天 | 数据保留政策的更新时间：2022 年 11 月，指出每个密钥会在上次写入 30 天后被清除。欢迎您提供更多反馈，以了解新政策是否适用于整个生态系统。 |
| 广告素材轮播 | 广告素材轮播使用情形并不反映竞价后的实际操作。 | 我们希望了解更多买方广告技术公司关于广告素材轮播文档是否准确的问题。 |
条状标签
本季度未收到任何反馈。
FedCM
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 身份断言端点 | 明确允许对身份断言端点的任意请求。 | 我们一直在与 Mozilla 合作处理此拉取请求，以限制网站以静默方式发出跨源凭据请求的请求，而不给用户造成干扰，并且会继续审核并解决其他反馈。 |
| 预先填充身份 | 可以使用 FedCM 通过 FedCM 列表中的身份提供方预填充登录表单吗？ | 此用例存在以下问题：当未与用户互动的网站能够查询用户使用的最后一个 IDP 时，可能会导致信息泄露。我们正在进一步讨论此问题，欢迎其他反馈。 |
| 内容相关账号选择 | 关于在账号选择界面中添加情境信号的建议 | 我们正在考虑此提案，欢迎进行其他讨论。 |
打击垃圾内容和欺诈行为
Private State Token API（和其他 API）
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 收集调查问卷的功能 | 在第 1 季度初，我们完成了问卷调查结果的收集，了解各种反欺诈用例需要哪些功能，并公开分享这些结果（分钟， 结果） | 我们计划在开发新的提案和原型设计的过程中，针对为实现反欺诈功能而专门打造的可保护隐私的 API，参考这些反馈。我们希望优先开发有足够需求且有可依托的现有技术，在保护用户隐私的同时引入 Web 功能。例如，设备和启动完整性排名很高，并且许多平台都现有的 API 可以安全地共享设备完整性评估，因此它是社区小组中探索的理想之选。 |
| PST intent to Ship 反馈 | 鉴于我们打算推出新版本，考虑到我们使用了旧版 Privacy Pass，我们在继续处理过程中收到了相关顾虑。我们还收到了反馈，指出该规范在某些部分中不够明确，应进行改进以提高浏览器兼容性。 | 我们计划在推出 GA 之前实施许多建议的规范更改，以及一些 API 更改。这些反馈是在第一季度末收到的，因此，我们正在跟进 GitHub 问题，并提供具体详细信息和对发布计划的更新（截至本反馈报告发布时，这些更新仍在进行中）。 对于对该 API 做出的重大更改，我们愿意考虑这些更改，但我们认为最佳的进展方式是继续发布正式版，并收集更多开发者的实际反馈。我们希望继续讨论并实现浏览器标准化。当出现新标准时，我们将考虑采用并制定计划，以便仔细过渡到新标准。 |