反馈报告 - 2023 年第 1 季度

2023 年第 1 季度季度报告，总结了收到的有关 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 回复
测试和试用 如果 Privacy Sandbox API 在测试开始时尚未完成，测试结果对 CMA 评估的相关性 Privacy Sandbox API 的开发正在稳步推进。这些功能已在 Origin 试用版中推出，供您测试，并将于今年夏天面向 100% 的流量正式推出。

此外，我们还明确了某些功能（例如 FLEDGE 事件级报告、使用 iframe 的 FLEDGE 呈现）的时间表，这些功能最早不会在 2026 年之前受到影响。

我们鼓励生态系统测试这些 API，并根据测试人员在第三方 Cookie 被弃用后预计会依赖的功能，向 CMA 提供反馈。这有助于他们评估弃用第三方 Cookie 的可能影响。
用户控制功能 向生态系统提供有关 Privacy Sandbox API 用户控制影响的明确指南 我们无法就生态系统可以使用哪些用户控制功能提供法律建议。与此同时，Chrome 正在尝试向一小部分用户显示更新后的 Privacy Sandbox（“增强型广告隐私保护”）用户控件，这是我们持续改进 Privacy Sandbox 技术的一部分。更新后的语言和布局更清晰、更实用。在 Chrome 评估这些改进并决定是否将其推广到更广泛的用户群后，便可以与生态系统分享更多信息。
数据泄露 浏览器遭到入侵时，第一方数据可能会泄露给 Google 和其他方 我们的 FLEDGE 说明文档清楚说明，一个广告技术平台的数据只会与该广告技术平台共享（与其 worklet 或其受信任的服务器共享），或者在该广告技术平台明确共享数据时（例如，买方向卖方显示其想要展示的广告网址）。唯一的例外情况是，k-匿名性检查必须由全球集中式服务器执行，我们会继续投入大量资源来改进这一方面。如需详细了解我们对隐私保护的思考，请参阅 k-匿名性说明。

此外，我们还可以详细介绍在设计 k-匿名性服务器时采用的广告技术保护措施的运作方式。
其他讨论论坛 向 W3C 申请额外的论坛，供非技术生态系统参与者分享反馈 隐私沙盒反馈表单适用于一般和具体、技术和非技术方面的意见。
Improving Web Advertising Business Group 是一个论坛，可通过每周通话和 GitHub 代码库进行讨论。
Privacy Sandbox Feedback 页面介绍了提供反馈和参与讨论的其他机制。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，并在最新动态页面和本问题中分享了相关动态。我们逐点回复了 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 用于展示基于兴趣的广告以外的用途 Topics 旨在解决基于兴趣的广告投放场景，我们认为这对自由开放的网络至关重要。我们目前正在征求有关其他用例的反馈，并进行评估。
默认选择启用状态 地区性法律对“主题”默认用户意见征求的影响 我们无法对法律意见发表评论。
（也报告在 2022 年第 3 季度）
分类错误的网站		 针对给定网站的主题分类错误时，广告定位 第 1 季度更新：
我们将于第 2 季度宣布更新后的 Topics API 分类器，并期待与生态系统就此展开互动。
为回应当前反馈，系统会通过人工挑选的替换列表（包含最热门的网站）和设备端机器学习模型来对网站进行分类。Chrome 会继续评估网站为 Topics 分类做出贡献的选项。在考虑任何实用性改进时，都必须权衡隐私和滥用风险。例如，一些风险包括：网站使用自标签方法将不同的（可能敏感）含义编码到主题中；网站为了牟利而虚假陈述其主题；网站攻击主题以降低其对他人的实用性（例如，向用户的主题发送无意义的垃圾内容）。 公众可以通过 chrome://topics-internals 或此 Colab 中的工具检查这些组件。我们希望通过测试，分类功能会随着时间的推移而不断改进，对于可能被错误分类的网站示例，我们欢迎您提供反馈。
主题分类器 请求在向调用方返回“No Topics”时返回其他信息，以便调试 我们理解并感谢开发者在将 Topics API 集成到其系统时，能够使用调试工具。不过，如果我们公开其他信息（例如未返回任何主题的原因），可能会无意中分享信息，使相关方能够发现超出预期范围的其他详细信息（例如，用户是否处于无痕模式、是否停用了 API 等），从而侵犯用户隐私。虽然我们目前不打算提供其他调试工具，但欢迎您就哪些工具有用提供反馈。
私密信息检索 (PIR) 请求 Topics API 采用私密信息检索 我们之前曾研究过使用 PIR，并在此处分享了权衡。
出价串流 在出价流中，主题的表示方式是否与卖方定义的受众群体不同？ Topics API 是 Chrome 开发的一项 Privacy Sandbox 提案，不同于 IAB Tech Lab 的卖方定义的受众群体提案。我们希望这两者在出价串中以不同的方式表示。了解主题将如何在 OpenRTB 出价请求中表示。

Protected Audience API（以前称为 FLEDGE）

反馈主题 摘要 Chrome 回复
FLEDGE 功能可用性 阐明了 FLEDGE 功能（例如围栏帧强制执行、k-匿名性等）的测试和实现时间表。 我们分享了各种范围的 FLEDGE 功能的状态以及这些功能将在何时受支持。我们会继续开发 FLEDGE，欢迎您就此公告提供更多反馈。
商品呈现限制 请求放宽针对 FLEDGE 围栏框的“由多部分组成的广告”限制 正如我们在 2 月宣布的那样，至少在 2026 年之前，使用围栏框架将仍然是可选的，并且 urn-iframe 将支持 iframe 行为。欢迎就此主题进一步讨论。
可伸缩性问题 随着使用规模扩大，FLEDGE 的性能 我们正在积极跟进反馈并了解更多背景信息，以便提出切实可行的解决方案。第一步是将反馈分为两类，我们这样做了：
  1. SSP 驱动的过滤，用于优化 a) 自身和 b) DSP 上的每秒查询次数 (QPS) 负载。
  2. 兴趣群体 DailyUpdate 逻辑，用于优化 DSP 上的 QPS 负载。
（也已在 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 的超时控制方案 这是一个有趣的提议。我们会将其添加到待研究的方案队列，并报告进展情况。
广告素材出价串流 能够根据广告素材查看和过滤胜出的出价 这是一个有趣的提议。我们会将其添加到待研究的方案队列，并报告进展情况。
reportWin 提案：在 reportWin 函数中，提供有关胜出方以外的其他兴趣群体所有者的得分最高出价的更多信息 这是一个有趣的提议。我们会考虑在汇总报告中添加其他信号，并欢迎您在此处提供更多反馈。
事件类型 在与 FLEDGE 集成时，跨衡量 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) 服务器 未来是否支持自定义键值对服务器？ 我们正在讨论此问题，欢迎您提供更多信息。
顶级竞价 是否必须是广告服务器才能运行顶级竞价机制？ FLEDGE API 未指定哪一方必须调用它；FLEDGE 的设计中没有这方面的要求。任何人都可以运行 FLEDGE 竞价（包括多卖家竞价）。如 2022 年第 4 季度报告中所述，FLEDGE 允许每个发布商选择竞价结构，包括选择顶级卖方和组件卖方。
API 范围 FLEDGE 是否打算使用第一方数据？ 我们将于 2023 年第 2 季度发布内容，阐明第一方数据确实可与 FLEDGE 搭配使用，以便：1) 作为逻辑来确定兴趣群组成员资格；2) 作为用户出价信号馈送，以便在后续生成出价逻辑时使用。
跨网域兴趣群体 有可能创建跨网域兴趣群组 将浏览器添加到兴趣群体时提供的任何信息都可以用来为该受众群体提供信息。在第三方 Cookie 逐步淘汰后，可用于为兴趣群体创建提供依据的跨网站数据将会减少。
客户端出价逻辑 将现有的服务器端出价逻辑移植到客户端 我们希望详细了解移植过程中哪些方面存在挑战或目前缺乏，并欢迎您提供任何其他反馈或见解。
K/V 服务器值 K/V 服务器值是否需要为字符串类型？ 值需要是字符串，但可以将对象存储在 JSON 或协议缓冲区中，并将其序列化为字符串。
广告客户屏蔽名单 哪些信号适合向买方提供广告客户屏蔽名单？ 合适的位置是在 auctionSignals 或 perBuyerSignals 中。
出价单位 支持不同的出价单位，例如 CPI 和 CPM 我们想详细了解在当前设计的情况下，为何需要这样做，并期待收到更多反馈。
竞价逻辑 是浏览器还是广告服务器决定竞价的胜出者？ 所有胜出者选择都在沙盒中执行，所有决策均由卖方的代码做出。浏览器只会提供一个密封的私有环境，买方和卖方代码在其中运行。
权限政策 在源代码试用结束后，当前的 FLEDGE 权限政策是否会继续强制执行？ 对于起源试用版，这两项功能的当前默认许可名单是临时的，将会发生变化。我们希望了解在我们开始强制执行此项变更之前，广告技术平台需要多长时间来为此做好准备。
信号大小限制 可信出价信号请求会跨具有相同 trustedBiddingSignalsUrl 的多个兴趣群组合并；2MB 的大小限制是一个约束条件。 此限制适用于设备端调用方，以防止设备上的资源过载。来自 B&A 服务器的调用方将受到更宽松的约束条件。
报告信号 添加了额外的信号“script-errors”，以便检索每个兴趣群体所有者和每个 computeBid 或 reportWin / reportResult 的客户端错误数量。 我们正在考虑此提案可能带来的隐私问题，欢迎生态系统参与者就为何需要这样做分享更多见解。
K-Anon 窗口大小 将 K-Anon 窗口大小从当前的 7 天限制增加。 我们正在考虑这一点，并期待（也欢迎）从生态系统中获得更多信息。
在不同设备上的效果 如果用户属于大量兴趣群体，FLEDGE 如何处理设备性能？ FLEDGE 在 SSP 和 DSP 中提供了多种超时、优先级和限制选项，可让广告技术平台在设备处于大量兴趣群体中时，针对设备性能限制竞价参与情况进行精细控制。
B&A 服务测试 要求生态系统参与者在测试阶段使用自己的服务器，以便有更多日志可供调试 借助 B&A，用户可以从已获批准的云服务提供商处启动和扩缩服务器。为保护用户隐私，我们会强制在可信执行环境 (TEE) 中执行。我们很快就会发布有关调试 B&A TEE 的说明文档，并正在开发支持此功能的功能。我们正在征求有关该主题的更多反馈。
法规要求 FLEDGE 是否会与不同国家/地区的云服务提供商合作，以帮助客户遵守当地法规要求？ 我们一直欢迎有关其他云服务提供商的建议，但目前计划在强制弃用第三方 Cookie 时至少支持 GCP 和 AWS。如需了解详情，请参阅此说明文档。

衡量数字广告的效果

Attribution Reporting API（及其他 API）

反馈主题 摘要 Chrome 回复
噪声影响数据分析 有关如何对噪声影响执行数据分析的指南 我们分享了其他文档，介绍了噪声以及可用于改变噪声对广告技术数据影响的噪声和设计决策。

我们还提供了更详细的指南。
Null 报告 明确了 null 报告的实现 我们目前正在制定实现 null 报告的提案，很快就会分享更多详细信息。通过实现 null 报告，我们可以在不侵犯隐私的情况下缩短报告延迟时间。
噪音大小 根据归因时间范围调整噪声级别 我们欢迎此提案，并正在考虑将其添加到规范中。欢迎点击此处提供其他反馈。
触发器数据大小 为什么触发器数据大小限制为 3 位？ 大小限制为 3 位和 8 个不同的值，以确保限制用户的跨网站/情境信息量。我们欢迎生态系统参与者提交反馈，就事件级报告的当前参数化是否合理提供意见。
事件级报告触发器 允许在重复信息删除键中进行优先级排序 我们正在探索解决方案，欢迎您提供更多反馈。
调试支持 明确说明了在弃用第三方 Cookie 后如何进行调试 我们希望支持在弃用第三方 Cookie 后进行调试，并正在考虑各种方案。我们期待收到更多反馈和想法。
点击型转化替代指标 请求有关点击型转化替代方案的更多指导 我们鼓励生态系统将 Attribution Reporting API 用作适用于相关转化衡量用例的持久性私密衡量系统。还有其他替代方案，广告技术提供商需要根据其所需的隐私保护和实用性需求来决定合适的解决方案。
结算用例 明确 Attribution Reporting 将在多大程度上支持基于转化的结算用例 我们正在努力发布公开信息，以阐明 Attribution Reporting API 在结算方面的使用范围。Attribution Reporting API 最初的范围并未直接支持每次转化费用结算；它支持每次点击费用和每千次展示费用结算，这是大多数广告技术平台使用的结算结构。
如果有其他生态系统反馈，我们日后可能会支持此功能。
使用情形支持 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 采用情况 在英国排名前 1 万的网站中，只有 1% 的网站在使用程序化广告时发送 HTTP 客户端提示。未迁移的 DSP 可能会影响防欺诈功能。 在对同一数据集运行分析后，我们发现，如果您考虑使用 HTML <meta> 标记和 JavaScript API 的 UA-CH 使用情况，使用 UA-CH 的网站数量远远高于反馈中提供的 1% 这一数字。基于这一点以及包括生态系统反馈在内的其他事实，我们有信心按照已发布的时间表，继续逐步推出 UA 减少的第 6 阶段，同时及时告知 CMA。请注意，网站已经有近两年的时间来为过渡做好准备，对于认为自己还不准备好的网站，我们仍提供弃用试用。
针对其他外形规格的提示 请求 UA-CH 提供 TV、VR 等其他外形规格 我们欢迎您的建议，并正在考虑将其纳入设计中。欢迎您提供更多反馈。
自动测试 请求在 UAR 第 6 阶段发布之前解决无头 Chrome 中的 UA-CH 错误 相关 bug 已修复。
在 iOS 设备上支持 UA-CH 某个网站依赖于精细的 UA 信息来实现广告用例，但指出不支持 iOS 版 Chrome。 对于非 Safari 的 iOS 浏览器（包括 iOS 上的 Chrome），WebKit 项目需要先添加对 UA-CH 的支持，然后才能启用 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 地址的基本屏蔽名单（例如 TAG 数据中心 IP 地址列表），以防止对极有可能存在欺诈行为（或至少无法创收）的广告资源进行出价。如果广告技术公司同时也是跟踪器，并且可能受 IP 保护提案的约束，那么该公司可能无法在购买广告资源之前对广告执行基本检查。 我们鼓励您就 IP 保护提案中的潜在问题和解决方案提供更多反馈并进行讨论。一种方法是将类似的列表应用于 IP 保护功能，以便我们不代理来自之前被标记的 IP 地址的客户端。

增强跨网站隐私边界

First-Party Set

反馈主题 摘要 Chrome 回复
（也报告在第 4 季度）网域限制 请求扩大关联域名数量 我们的回复与 2022 年第 4 季度保持不变：

“我们在 WICG 通话中已明确表示，Chrome 致力于提供同时兼顾用户隐私权益的可用解决方案。因此，我们希望社区就可能受到网域限制影响的具体用例提供反馈，以便相关团队考虑如何在继续保护用户隐私的同时，解决这些用例。”
提交备选 FPS 提议为 FPS 提交全局列表的替代方法 目前，我们正准备在 Chrome 中发布第一方套装 (FPS)，并已设置一个集中式 GitHub 代码库来接受套装提交。我们希望 FPS 能够填补现有网站平台解决方案的空白，为弃用第三方 Cookie 做好准备，因此希望从他们那里了解网站作者如何利用 FPS。随着时间的推移，集合列表会不断扩大，而生态系统也会适应无第三方 Cookie 的世界，我们也可以让该流程更加成熟，以便考虑其他去中心化方案（例如我们提出的方案）。在当前流程下，我们预计会设定固定的生命周期，以便我们随着时间的推移改进接收流程。在提交流程成熟后，我们可以重新考虑这个想法。
代码库审核 对 FPS 提交代码库实施社区审核，以防止滥用。恶意行为者可以轻松利用一次性来源来提议集合，使该流程不堪重负，而大量请求可能会影响真实集合提案的操作。 我们会依靠技术验证检查，尽可能客观地进行检查。我们认为，这是提交流程最具扩展性的方法。为实现这一目标，我们还将致力于确保该流程能够抵御垃圾内容 / 临时账号提交内容。
关联的子集 FPS 能否通过关联的子集支持第三方供应商/SaaS 流程用例？ 第三方供应商 / SaaS 流程目前不在第一方组的适用范围内。欢迎您就如何将跨网站 Cookie 用于这些用例提供更多反馈。
FPS + CHIPS 集成 请求集成 FPS + CHIPS，以支持 A/B 测试等用例 我们正在讨论此用例，并考虑在 WICG 通话中进一步讨论此问题。欢迎点击此处提供更多反馈。
GDPR 提议根据 GDPR 概念创建新的 FPS 子集 我们在内部讨论了此提案，并将其与收到的其他反馈以及我们的隐私保护目标进行了权衡。我们已做出回复，说明了为何目前不会推进此提案。
内存 集成 FPS 列表后浏览器内存大小的预期变化 浏览器存储此类列表的先例表明，可以最大限度地减少内存开销，例如 Disconnect 跟踪保护列表。虽然 First-Party Sets 列表会复制到每个 Chrome 客户端的本地，但我们会继续监控文件大小，并有信心能够优化内存占用量。

Fenced Frames API

反馈主题 摘要 Chrome 回复
Fenced Frames 限制 明确说明 Fenced Frames 的限制 3 月份，我们更新了有关围栏帧的说明文档，其中介绍了围栏帧的功能。我们欢迎您提供任何其他反馈。
展开访问权限信息 请求扩大对相邻帧周围信息的访问权限 我们希望进一步了解为何生态系统要求这样做，欢迎您提供任何其他反馈。
Fenced Frames 和 iframe 关于围栏帧和 iframe 之间功能一致性的问题 所有可用的 Privacy Sandbox API 和报告都将以相同的方式适用于 iframe 和 FencedFrame。
调整 Fenced Frames 的大小 限制帧大小更改会影响某些用例。 我们很想详细了解受此限制影响的用例类型，也欢迎您提供更多反馈。

Shared Storage API

反馈主题 摘要 Chrome 回复
第三方 worklet 第三方能否写入按来源分区的 Shared Storage？或者调用其他 worklet 进行第三方衡量？ 执行代码的浏览器上下文的来源决定了数据会写入谁的共享存储空间。将第三方代码添加到网页后，第三方代码可以作为具有自己浏览上下文的 iframe 嵌入，这样第三方代码就可以写入自己的来源。第三方代码还可以作为脚本（而非 iframe）嵌入，这样就不会切换浏览上下文，并且第三方可以写入嵌入者的共享存储空间。请注意，只有该共享存储空间的所有者才能从该共享存储空间读取数据。
去重功能 系统无法对 Chrome 生态系统之外的互动进行去重处理。 共享存储空间旨在提供基于 Chrome 浏览器的独特覆盖面输出结果。我们希望与广告技术平台合作，了解如何将这些输出作为其覆盖面更广的模型的一部分来使用。我们理解，输出本身可能只占互动量的一小部分，因此有兴趣与广告技术平台合作，探索可叠加使用的其他建模方法。
转化回溯期 请求为转化率设置回溯期，以便查看转化随时间的变化 为实现此目的，您可以使用共享存储空间在客户端处理各种转化路径，这比使用安全的未分区浏览器存储空间进行高级分析更具灵活性。
商品到期期限 申请将失效期限延长至 90 天 数据保留政策已于 2022 年 11 月更新，其中规定，每个键都会在最后一次写入 30 天后清除。我们欢迎您提供更多反馈，以便了解新政策是否适用于整个生态系统。
广告素材轮播 广告素材轮播用例并未反映竞价后的实际操作。 我们希望听取更多买方广告技术公司的意见，了解广告素材轮替文档是否准确。

CHIPs

本季度未收到任何反馈。

FedCM

反馈主题 摘要 Chrome 回复
身份断言端点 明确允许对身份断言端点发出任意请求。 我们一直在与 Mozilla 合作处理此拉取请求，以限制网站在无需引起用户反感的情况下静默发出跨源凭据请求，并将继续审核和处理其他反馈。
预先填充身份 FedCM 能否用于使用 FedCM 列表中的身份提供程序预填充登录表单？ 此用例存在的问题是，如果未与用户互动的网站能够查询用户上次使用的 IDP，可能会导致信息泄露。我们正在讨论此问题，欢迎您提供更多反馈。
内容相关账号选择 关于在账号选择界面中添加情境信号的提案 我们正在考虑此提案，欢迎进一步讨论。

打击垃圾内容和欺诈行为

Private State Tokens API（及其他 API）

反馈主题 摘要 Chrome 回复
功能收集调查问卷 在第一季度初，我们完成了调查问卷的收集工作，了解了各种防欺诈用例需要哪些功能，并将调查结果公开分享（） 我们计划在开发可保护隐私的专用 API 以实现防欺诈功能的新提案和原型时，纳入这些反馈。我们预计会优先开发在满足足够需求且有现有技术可依托的情况下，将相应功能引入到网络中，同时保护用户隐私。例如，设备和启动完整性排名很高，并且许多平台都具有可安全共享设备完整性评估结果的现有 API，因此非常适合在社区群组中进行探索。
PST 意图发货反馈 在准备发布时，我们收到了关于继续发布的疑虑，因为我们使用的是较低版本的 Privacy Pass。我们还收到了反馈，指出规范在某些部分不明确，应进行改进以提高浏览器兼容性。 我们计划在 GA 发布之前实现许多建议的规范变更，以及一些 API 变更。反馈就在第一季度末收到，因此我们正在跟进 GitHub 问题，以了解具体详情并更新发布计划（截至此反馈报告发布时，该计划仍在完善中）。

对于对 API 进行的更大更改，我们愿意予以考虑，但我们认为，最好的做法是继续发布正式版，并从更多开发者那里获得实操反馈。我们希望继续进行这场讨论，并推动浏览器标准化。如果有新标准出现，我们会考虑采用该标准并制定相应计划，以谨慎过渡到该标准。