2022 年第 3 季度的季度报告，其中总结了生态系统对 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 响应 |
| （第 2 季度也有报告）
对不同类型的利益相关方的实用性 |
担心 Privacy Sandbox 技术偏向于大型开发者，以及小众（较小）网站贡献的程度高于一般（大型）网站。 | 第 3 季度更新：
Google 已承诺 CMA 致力于设计和实施 Privacy Sandbox 提案，且不会因自我推销 Google 自己的业务来影响竞争，并且要考虑到数字广告领域的竞争以及对发布商和广告主（无论其规模如何）的影响。我们将继续与 CMA 密切合作，确保我们的工作符合这些承诺。 随着 Privacy Sandbox 测试的不断进行，我们将评估的关键问题之一是新技术对不同类型的利益相关方的影响。反馈在这方面至关重要，尤其是有助于我们进一步改进技术设计的具体、切实可行的反馈。 我们与 CMA 合作制定了定量测试方法，并且支持 CMA 发布有关实验设计的说明，以便向市场参与者提供更多信息，并有机会对建议的方法发表评论。 |
| （第 2 季度也有报告）
文档请求 |
请求获取详细说明如何管理测试、分析和实现的更多资源 | 第 3 季度更新：
感谢开发者发现我们当前的材料很有帮助，并致力于在未来几周和几个月内提供更多材料，以便开发者能够继续了解新技术如何为他们服务。 我们还举办了公开的开发者咨询交流时间会议，分享最佳做法和演示；此外还有问答环节，供产品和工程主管进行实时讨论/提问。 |
| 跨浏览器支持 | 采用 Privacy Sandbox API 的其他浏览器供应商。 | Apple、Mozilla 和 Microsoft 等其他浏览器供应商也会积极参与公共论坛，讨论隐私保护原则和基于浏览器的方法。在最近的 W3C 年度 TPAC 会议和持续进行的 W3C PATCG 论坛等论坛上，我们发现了趋同的迹象，这些论坛上的协作讨论也让我们深受鼓舞。 |
| 平台差异 | 要求尽可能在 Web 和 Android 之间保持一致的功能集，以帮助减少过渡所需的资源。 | 我们致力于使我们针对 Chrome 和 Android 采用的方法保持一致，以免在整个行业内造成混淆/零散。我们方法的任何差异主要是因为 Web 平台和移动应用平台之间存在必要的技术差异，开发者已经考虑到了这些差异。 |
| 用于测试 Privacy Sandbox API 的资源 | 难以分配足够数量
测试 Privacy Sandbox API，以应对当前经济形势下的不利形势。 |
Google 会不断改进为测试人员提供的文档和支持，以降低复杂性并协助他们采用这些 API。这些努力包括：API 专属邮寄名单、开放咨询交流时间，以及持续更新的 developers.chrome.com 动态。 |
| 沙盒 API 停用信号 | 请求提供“用户已拒绝沙盒 API”信号，广告技术平台和网站可以使用该信号。 | 我们看到过许多过往的案例，即网站会迫使用户更改自己的设置（例如“关闭第三方 Cookie”）来做出反应，有时包括在用户更改设置的情况下禁止访问网站。选择停用信号也可用作数字“指纹”收集的额外信号。目前，Google 不打算提供选择停用信号 |
| （第 2 季度也有报告）
更清晰的时间轴 |
更清晰、更详细的发布时间表 | 第 3 季度更新：
正如以下“根据反馈做出调整”部分中所述，Google 在 7 月份更新了 Privacy Sandbox 时间表，为市场留出更多时间进行初步测试和反馈，并在 Privacy Sandbox API 全面推出后，在弃用第三方 Cookie 之前留出更多时间进行测试。 |
| （第 2 季度也有报告）
第三方 Cookie 弃用时间表 |
为避免因第三方 Cookie 弃用而进一步延迟的请求 | 第 3 季度更新：
7 月份，Chrome 宣布了更新后的第三方 Cookie 弃用时间表，这反映了我们鉴于这些技术的复杂性及其对生态系统的重要性，以负责任的方式行事的承诺。在此次变更之前，我们考虑了来自监管机构和业界的反馈，并将继续与所有利益相关方密切合作。 |
| 第一方 Cookie | 是否也提议了针对第一方 Cookie 的限制？如果是这样，客户会对长期稳定性以及日后不可预测的浏览器更改所带来的风险产生担忧，并因此浪费了现在的工程工作。 | 我们尚未考虑过任何第一方 Cookie 限制。Privacy Sandbox 的重点是废弃第三方 Cookie。 |
展示相关的内容和广告
主题
| 反馈主题 | 摘要 | Chrome 响应 |
| （第 2 季度也有报告）
对不同类型的利益相关方的实用性 |
有人担心，网站之所以会有实用性，是因为网站的流量水平或内容的专业程度如何。 | 第 3 季度更新：
我们将通过测试来探索该 API 的实用性。按照承诺中第 17.c.ii 段的要求，Google 将与 CMA 分享此类测试的结果。Chrome 预计分类和其他参数会根据测试结果而变化。分类或参数的演变可能不需要向后不兼容的更改。此外，Chrome 期望在第三方 Cookie 弃用后，反馈能继续影响 Topics API 的演变。 |
| 隐私权政策/政策 | 请求移除按调用方的主题过滤要求。 | 根据来自隐私保护 KOF 人员、隐私保护倡导者、安全专家、数字权利团体和生态系统中其他人员的反馈，Chrome 选择此设计是为了仅向拥有相应访问权限的人员授予信息访问权限。这样做的原因包括但不限于：限制增量的跨端数据泄露；确保透明度和可解释性；采用易于实现和描述的方法；以及限制数字“指纹”收集的风险。收到 Topics 信号的发布商和第三方可以自行决定要与网站上的各方分享哪些信息。如果第三方确实分享了这类信息，Chrome 强烈建议它们开诚布公地向用户说明此类信息分享情况，并提供相关控制权。 |
| 网站分类错误 | 网站归类错误，这可能会导致广告定位不准确。 | 网站分类的方式是综合考虑人工挑选的替换列表（包含最热门的网站）以及设备端机器学习模型。Chrome 会继续评估可供网站用于 Topics 分类的选项。任何实用程序改进都必须权衡隐私和滥用风险。部分风险包括：
公众可以使用 chrome://topics-internals 或此 Colab 中提供的工具检查这些组件。我们希望通过测试不断改进分类功能，欢迎大家提供反馈，告诉我们分类可能有误的网站示例。 |
| 访问权限要求 | Topics 目前要求将 DOM 实体作为脚本或 iframe 在网页上以脚本或 iframe 的形式呈现，以求获得访问权限，这可能会导致广告生态系统中的播放器出现不良行为。 | 我们已合并 GitHub 解释器上的更改。我们打算支持在 HTTP 标头中使用主题。 |
| 主题分类不够精细 | 当前的主题分类过于宽泛，并且不包含更细化的主题，例如地区主题。 | 我们会持续不断地改进分类方法，我们期望分类法随着生态系统测试和输入的完善而不断完善。
我们正在积极征求对对生态系统最有用的分类法的反馈。在评估是增加主题数量还是包含更精细的主题时，需要考虑一些因素，包括：1) 对隐私的潜在影响（例如，主题越多，可能会带来数字“指纹”收集风险）以及 2) 能够检索之前观察到的主题（例如，如果主题越多，广告技术平台过去看到过所选主题的几率可能就越小）。在此基础上，Google 力争在现有过滤要求内最大限度地提升调用方检索之前观察到的主题的能力，力求实现实用性和隐私性。 |
| 主题限制 | 对于每个网站，三个主题的信息太少，广告客户无法投放广告。 | 来自生态系统的反馈，尤其是源试用的测试结果，将会继续影响该 API 的演变。需要注意的是，Topics 会对内容相关等其他信号进行补充，以帮助为访问者找到合适的广告。因此，除了主题之外，广告客户还可以获得更多信息。 |
| （第 2 季度也有报告）
用户控制和安全 |
某些主题可能代表敏感群体，用户需要采取更多控制措施来防止不良后果。 | 第 3 季度更新：
主题在提高用户控制权和知情权方面取得了重大进展。用户将能够选择停用主题、查看分配给他们的主题、移除主题，以及了解哪些公司正在指定页面上与其主题互动。此外，用户还可以通过删除浏览记录来清除自己的主题，而浏览记录是基于这些主题生成的。目前，这些控件在 Chrome 浏览器中是在设备级别实现的。我们欢迎大家继续就更高级的用户控制功能（例如开发者建议的控制方式）展开讨论；不过，我们需要确保新增的功能经过适当的校准，可以解决用户提出的问题，并且不会导致零星更改。 |
| 对 SEO 的影响 | 发布商调整网站的主机名以更好地反映 Topics，可能会对搜索引擎优化 (SEO) 造成负面影响。 | 我们会提醒网站，不要仅仅为了 Topics 而更改主机名。的确，网站或许能以这种方式影响为其分配的主题。但这样做对发布商的好处并不明确，如果网站试图欺骗分类模型，则会破坏 Topics 对整个生态系统的价值。主题的分配也并非一成不变；我们希望随着测试和输入的意见不断完善，我们会不断完善分类。在测试过程中，我们鼓励大家提供反馈，包括任何可能被错误分类的网站示例。 |
| 欺诈和滥用行为 | 应提供一种方法，供买方验证他们所看到的主题是否确实由浏览器生成。 | 感谢您建议为广告技术买方提供一种机制，用于验证卖方在程序化广告竞价中传递的主题。我们鼓励生态系统中的各方人士积极参与讨论，请点击此处。虽然我们目前正专注于其他优先级更高的改进，但我们知道这可能会成为设计的重要未来补充。 |
| 欺诈和滥用行为 | 允许对拥有 Topics 数据的合法用户的相关方进行公开审核，只需采用与第一方数据集相同的公开帖子和评价类型。 | 我们非常重视相关建议，并且认为公开问责是帮助实现 Privacy Sandbox 目标的重要工具。Topics API 调用本质上是公开的，因为任何人都可以访问网站并观察域对 JavaScript API 的调用。因此，个人和组织可以查看相关活动，并评估哪些网站在使用 Topics 及其使用方式。我们认为，这种方法比在 Topics API 本身的功能中评估网站的“合法性”要好。 |
| 对第一方信号的影响 | Topics 信号可能具有很高的价值，因此会降低其他基于兴趣的第一方信号的价值。 | 我们认为，针对用户兴趣投放广告是一种重要的网络应用场景，而 Topics 就是为此而生。如上所述，生态系统的其他利益相关方表示担心 Topics 可能不够实用，无法提供价值。在任何情况下，对分类的改进都需要持续努力，我们期望分类随着生态系统测试和输入而不断完善。 |
FLEDGE
| 反馈主题 | 摘要 | Chrome 响应 |
| FLEDGE 竞价 | SSP 如何为发送到 Google Ads 的数据设置格式，以便针对 FLEDGE 竞价进行出价。 | 我们鼓励参与测试的公司发布有关其测试计划的文档，并在适当情况下合作。
我们与 CMA 合作制定了定量测试方法，并且支持 CMA 发布有关实验设计的说明，以便为计划参与试验的市场参与者提供更多信息，并有机会就拟定的方法发表评论。 Ad Manager 团队在此处发布了面向有意通过将 Ad Manager 作为广告服务器的发布商测试 FLEDGE 的卖方的文档。 了解此处列出的其他技术详情。 |
| 嵌套围栏框架中的 FLEDGE | 围栏框架允许测试限制较少，同时在不确定的未来限制更多。这种未知的时间表给生态系统带来了挑战。 | 公司现在可以使用围栏框架测试 FLEDGE。为了提供更简单的新手入门选项，公司可以选择先实现 FLEDGE。实现 FLEDGE 后，他们可以使用 FLEDGE 设计测试围栏框架。 |
| 数据处理政策 | 针对兴趣群体 / FLEDGE 的数据处理政策是什么？ | 在 FLEDGE 设计中，存储在兴趣群体中的数据或与用户兴趣群体相关的数据仍会保留在设备端。此类数据不会发送到 Google 服务器。
Chrome 为 FLEDGE 计划制定的一些隐私保护措施确实会涉及与 Google 运行的 k-匿名性服务器进行交互。这种互动方式经过精心设计，不会分享有关用户的信息，并且会在可信执行环境 (TEE) 中运行，以确保整个广告生态系统中的信息保持一致。 \ Google 已承诺 CMA 设计和实施 Privacy Sandbox 提案，且不会通过自利 Google 自己的业务来扭曲竞争，而且要考虑到数字广告竞争以及发布商和广告客户受到的影响。我们将继续与 CMA 密切合作，确保我们的工作符合这些承诺。 |
| 年龄政策 | Chrome 如何确保 FLEDGE 创建的受众群体符合年龄限制？ | 发布商和广告客户最适合评估他们使用 FLEDGE 创建的受众群体是否符合适用法律。为进一步保护用户，即使任何已登录 Chrome 的用户未满 18 周岁，也不会为已登录 Chrome 的用户启用 Privacy Sandbox API，即使在测试期间也是如此。（对于未登录的用户，Chrome 不会收集可让浏览器推断用户年龄的个人资料信号）。 |
| FLEDGE 键值对服务 | 更清楚地说明了 FLEDGE 键值对服务允许的范围，例如键的数量和更新频率。 | 使用 FLEDGE 的公司可以拥有任意数量的键，只要能够容纳在 RAM 中即可。如需了解详情，请点击此处查看铺垫消息。
我们正在努力提供一种更快的方式来修改数据，欢迎针对任何要求提出建议。 |
| 测试 | 很难通过 Google Ads 测试 FLEDGE | 请参阅 Google Ads 新手入门文档，了解如何以最佳方式参与源试用并进行测试。 |
| 出价和竞价服务 API | Google 对出价和竞价服务 API 有何发展方向？它在设备竞价中是高于还是低于 Chrome 浏览器 FLEDGE？ | 我们会一如既往地致力于采用最新的 FLEDGE 设备端出价设计。出价和竞价服务旨在探索可行的解决方案，以便为设备计算能力或网速可能有限的部分用例提供支持。 |
| 汇总报告 | 请求支持根据 generateBid 可用的所有信号生成汇总报告。 | 我们计划很快公开分享更多这方面的内容。 |
| 内容相关广告 | 使用 FLEDGE 投放内容相关广告。 | 我们已考虑过此选项，但由于本讨论中说明的原因，目前不建议将 FLEDGE 用于内容相关广告。 |
| 在现实环境中进行测试 | 关于如何将 FLEDGE 与第三方 Cookie 隔离开来用于实际测试的指南。 | 我们正在研究如何提供测试人群。
我们与 CMA 合作制定了定量测试方法，并且支持 CMA 发布有关实验设计的说明，以便为市场参与者提供更多信息，并有机会就拟定的方法发表评论。 |
| 测试 FLEDGE 和 Attribution Reporting API | 使用 FLEDGE 实现 Attribution Reporting API 的最佳方式是什么？将 FLEDGE 与归因工具分开，或同时进行测试是否是一种好主意？ | 我们最终将支持将 FLEDGE 和 Attribution Reporting API 作为集成解决方案进行测试，但我们建议开发者先独立测试 Attribution Reporting API，然后在集成完成后使用 FLEDGE。 |
| 出价可见性 | 请求混淆出价。 | 可以在“generateBid()”或“scoreAd()”中设置断点，以从开发者工具访问出价值。Chrome 团队考虑了这份关于 FLEDGE 的反馈中提出的窄攻击途径。不过，Chrome 的安全和隐私权模型会将受信任的用户视为可利用自己设备上的信息执行所需的任何操作，因此没有切实可行的方法可以按请求隐藏出价数据。 |
| 文档请求 | 有关在实时生态系统中进行测试的文档和示例。 | 感谢开发者发现我们当前的材料很有帮助，并致力于在未来几周和几个月内提供更多材料，以便开发者能够继续了解新技术如何为他们服务。
我们还举办了公开外部开发者咨询交流时间活动，与产品和工程主管分享最佳做法和演示，同时进行问答环节，让大家能够实时讨论/提问。 |
| Private Aggregation API | 请求详细了解 Private Aggregation API？ | 我们提供了公开解说，其中包含我们此时能够分享的最新信息。随着此 API 的开发和用例定义，我们将提供更多文档。 |
| 数据延迟 | FLEDGE 键值对服务器数据检索是实时进行的吗？ | 少量过时（大约几分钟（而非数小时）），服务器可能会返回更新后的数据以进行查询，如一个未解决的 GitHub 问题中所述。同时，我们也期待收到开发者的反馈。 |
| 出价和竞价服务 | 如果使用了出价和竞价 (B&A) 服务，出价是否会对用户隐藏起来？ | 对于 B&A 服务器端方法，用户看不到单独出价，因为出价请求是直接从 SSP 竞价服务向 DSP 竞价服务发出的，因此无法在浏览器中查看。
但是，浏览器仍然可以看到胜出的出价（上文对混淆出价的请求进行了详细介绍）。 |
| 出价和竞价服务 | 如何在出价和竞价服务之间实现负载均衡？ | 我们目前没有任何关于负载均衡的指导，但从性能和隐私的角度来看，这是一个重要的问题。今后，我们将提供更多详细信息。 |
| FLEDGE 限制 | 请求将 JoinAdInterestGroup 的时长上限从 30 天增加到 90 天。 | 我们认为 30 天的数据保留期限与其他 Privacy Sandbox 广告 API 一致，例如归因报告中的 30 天限制和 Topics 中的 3 周回顾。该时间范围可满足广告技术平台的需求以及用户对隐私保护的期望。
不过，我们欢迎您继续就此问题在此处提供进一步的反馈。 |
| FLEDGE 中的共享存储空间 | 是否可以在 FLEDGE 中使用 Shared Storage API？ | 我们打算将来在 FLEDGE 中支持 Shared Storage API，并努力在即将进行的源试用中实现此功能。 |
| 按点击次数控制频次 | 在 FLEDGE 中，能否按点击次数（而非胜出次数）设置频次上限？ | FLEDGE 会指定围栏框架可以调用 navigator.leaveAdInterestGroup()（不带参数）来退出促使广告展示的兴趣群体；此调用可在首次收到点击时完成，以阻止日后出价（作为频次上限的一种形式）。目前，此解决方案不适用于多次点击后设置频次上限。 |
| 嵌套围栏框架中的 FLEDGE。 | 如果点击发生在嵌套的围栏框架上，则无法通过围栏框架广告报告功能报告点击。 | 我们在此处发布了解决此问题的提案。 |
| 计量项 | 需要关于如何在 FLEDGE 竞价中收集出价方的延迟时间数据的指导。 | 我们正在努力发布性能衡量文档。 |
| 报告 | 系统将如何处理 FLEDGE 报告？ | 有关胜出、竞价结果、事件（例如点击）的 FLEDGE 报告将通过 reportResult() 等 FLEDGE API 提供。在报告广告转化时，与 Attribution Reporting API 的集成将独立于 FLEDGE，但他们正在与生态系统进行讨论，寻找可行的方法。
Private Aggregation API 还可用于报告隔离的执行环境中的竞价结果。请点击此处查看铺垫消息。 |
| 兴趣组规模 | 广告技术平台是否有办法检查兴趣群体的规模（即兴趣群体中的用户数量）？ | 兴趣组成员资格由浏览器存储在用户的设备上，不会与浏览器供应商或其他任何人共享。
但是，从理论上讲，兴趣组所有者可以跟踪对 navigator.joininterestgroup(...) 的每次调用。跟踪此调用并不能保证 IG 的确切大小（因为用户可以随时退出群组），但它可以为所有者提供上限和大致大小。 |
| 性能 | 出价 JS/WebAssembly 代码是否会在每次竞价中都编译？ | 出价 JS/WebAssembly 代码在每次竞价期间都会编译一次。 |
| 性能 | biddingDurationMsec 的范围是什么？ | biddingDurationMsec 包括编译脚本所用的时间。此时间不包括下载时间、 wasm 编译时间、网络时间；从键值对服务器提取时间或 JS 编译之前的任何时间。 |
| 自定义 | 能否更新 adComponent，使其针对用户进行自定义？ | 当调用方在调用 JoinInterestGroup 或 Chrome 调用 dailyUpdate网址 时更新兴趣组时，可以更新 adComponent。这样一来，调用方就可以分别根据当前网站中的用户信息或 k-匿名信息来更新 adComponent。您可以在此处找到产品级乌龟的全新方案，其中包括 RTB House 对推荐用例核心指标的影响的一些分析。 |
| 兴趣组 | 兴趣群体所有者有可能有条件地移除特定用户吗？ | 兴趣组成员资格仅存储在用户的浏览器中，并且只能在用户端移除（例如，通过清除网站数据）。
不过，如果用户返回到受兴趣群体所有者控制的网页，兴趣群体所有者可以调用 navigator.leaveAdInterestGroup()（并围绕一些条件逻辑）。 |
| 性能 | 如何衡量 generateBid 的效果？ | 编译和执行时间可以通过 biddingDurationMsec 来衡量。您可以通过 chrome://net-export 来衡量下载时间。在较新版本的 Chrome 中，编译和执行时间将显示在开发者工具的“Performance”标签页中。 |
| 兴趣群体的更新频率 | 浏览器对兴趣群体的更新频率是多少？ | 对于过去 24 小时内未更新的兴趣群体，Chrome 会在调用 navigator.updateAdInterestGroups() 或有机会参与竞价时更新这些兴趣群体。如需了解详情，请点击此处查看铺垫消息。 |
| 聚合服务提供商 | 聚合服务何时支持其他云提供商？ | 我们目前没有在特定时间提供任何更新，但一旦掌握了更多信息，我们就会与您分享。目前只有 AWS 符合汇总服务的安全要求。 |
| FLEDGE 测试时间表 | FLEDGE 会在 BYOS 中测试多长时间？系统是否有足够的时间从 BYOS 模型切换到基于 TEE 的模型？ | 为确保生态系统有足够的时间进行测试，在第三方 Cookie 被弃用之前，我们预计不会要求使用 TEE。在过渡之前，我们会提前通知开发者，让他们开始进行测试和采用。我们目前没有进一步的信息，但一旦有了新的进展，就会与您分享。请点击此处查看最新信息。 |
| 数据大小限制 | 出价函数中 wasm 的数据大小限制是多少？ | 如此处所述，兴趣群体更新不能产生超过 50kb 的兴趣群体，但 wasm 的数据大小限制尚未定义，因此我们将不胜感激。 |
| 竞价信号 | challengeSignals 是否有标准化数据结构？ | 这一点尚未定义，但欢迎提供反馈。 |
| 查询广告技术服务器 | 是否可以从 K/V 服务器实时查询广告技术平台服务器数据？ | 不会，K/V 服务器在信任模型中运行，该模型会强制实施“禁止访问网络、磁盘访问、计时器或日志记录”，以避免泄露用户数据。如需了解详情，请点击此处查看信任模型解释器。 |
| 更新 adComponents 的频率 | 目前无法根据用户的浏览记录更新 adComponents 字段（目前仅在 IG 设置中） | Privacy Sandbox 旨在满足网络生态系统的需求，而不进行跨网站跟踪，这意味着会阻止访问其浏览记录。我们建议使用 Topics 等替代方案。 |
| 竞价结果 | 广告技术平台有办法知道竞价胜出率吗？ | 系统会分别在卖方和胜出的买方提供的竞价代码中调用 reportResult() 和 reportWin() 函数以报告竞价结果，因此这两个函数都有机会记录和报告竞价结果。 |
| （第 2 季度也有报告）
支持排除性兴趣组定位 |
支持排除兴趣群体定位的 API：仅在用户不属于兴趣群体时展示广告。 | 第 3 季度更新：
我们分享了一项新 提案 ，现希望就此征求反馈。 |
衡量数字广告
Attribution Reporting（和其他 API）
| 反馈主题 | 摘要 | Chrome 响应 |
| 源试用要求 | 仅针对源试用期间 / 期间移除了权限政策限制。 | 请在测试期间查看我们公布的 Permissions-Policy 变更。此次变更消除了利益相关方关注的基本问题，那就是允许 DSP 在更多跨源 iframe 上测试该 API。最初，DSP 需要与发布商/SSP 协调，以确保设置了正确的权限政策，以便在跨源 iframe 上测试该 API；但在进行此项变更后，DSP 将可以默认调用该 API，而 SSP/发布商可以在源试用期间根据需要停用该 API。 |
| 噪声 | 反馈噪声级别过高且影响了报告的实用性。 | 欢迎提供有关噪声的反馈，我们将根据您的反馈确定如何设置某些与噪声相关的参数。我们还希望发布更多资源、工具和其他文档，以帮助测试人员解决此问题。 |
| 跨网域转化 | 如何跟踪跨网域（例如具有 2 个或多个目标页面）的转化？ | 我们目前正在讨论此问题并征求反馈。 |
| 调试要求 | 请求允许开发者在部署 / 测试摘要报告时查看剩余的隐私预算？ | 您可以 在此处跟踪此项功能请求。 |
| API 使用政策 | 反馈，根据数字“指纹”收集等方面的限制，就谁可以使用指定 API 提供政策建议 | 这是一个非常有趣的想法，我们非常乐意与其他浏览器提供商以及更广泛的网络生态系统进行进一步探讨。 |
| 转化报告中的过期时间设置 | 请求为报告过滤条件提供支持 / 使报告失效时间不超过 24 小时。 | 时段级别的过期机制会带来隐私问题，因为广告技术平台能够知道用户访问广告主网站的确切时段。日级过期时间允许广告技术平台滤除无效展示，而无需确定用户访问网站的时间段。 |
| OT 令牌过期 | 请求提升现有 OT 令牌的有效性，以减少操作开销。 | 我们知道令牌必须续期，因此正在努力简化开发者操作，并提供进一步通知。 |
| 区域支持 | 聚合服务目前仅支持部分区域。 | 这是 Beta 版目前存在的限制。随着测试的推进，我们预计会在更多地区推出相应支持，但目前还没有明确的时间表。 |
| 事件级报告延迟 | 对于某些使用情形，事件级报告的延迟 2-30 天可能太长。 | 我们在此处分享了一个提案，让广告技术平台可以控制何时通过过期时间发送事件级报告。默认值为 30 天，但也可以设置短一点。 |
| （第 2 季度也有报告）
多接触点归因 |
允许进行多接触点归因，例如跨设备或跨应用归因。 | 第 3 季度更新：
当前的多接触点归因方法需要确定性地将用户在不同网站上的展示（以及身份）关联起来。因此，目前的这项功能与 Privacy Sandbox 的目标不符，后者旨在支持关键广告使用场景，而无需进行跨网站跟踪。 |
| FLEDGE 和 Attribution Reporting 集成时间表 | FLEDGE 和 Attribution Reporting API 集成的时间表是怎样的？ | 我们目前没有任何动态要与您分享，但会在我们能够确定具体时间表后公开提供更多信息。 |
| 多个触发器类型 | 请求在触发器注册方面提高灵活性。 | 我们提出了针对汇总 API 的重复信息删除系统，该系统可让广告技术平台更灵活地控制事件级报告和可汇总报告。 |
| 计量项 | 请求接收衡量数据，以了解广告资源是否表现出色。 | 非常感谢您提供反馈，并希望就此请求的用例提供更多信息。 |
| 转化过期时间 | 请求在触发器代码（而不仅仅是来源代码）上支持转化过期设置。 | 非常感谢您提供反馈，并希望进一步阐明此请求的用例。 |
| 批量报告 | 请求在批量报告中进一步衡量。 | 感谢您提供反馈，我们将继续思考这对汇总服务的影响。我们很想听听广告技术平台对批处理报告的看法及其预期频率，以及关于批处理策略在一年内如何变化的任何反馈。 |
| Epsilon | epsilon 的值何时确定？ | 我们正在积极与生态系统测试人员合作，以便最终确定 epsilon 值及其在 Google Analytics（分析）中的实现方式。该值将与导致价值决策的讨论一起公开显示。如果您有任何反馈，请发布到此 GH 问题中。 |
限制隐蔽跟踪
用户代理缩减
| 反馈主题 | 摘要 | Chrome 响应 |
| 部署依赖项 | 解决结构化用户代理 (SUA) 部署依赖项问题。 | 我们已推行“第 4 阶段”，也就是版本 101 及以上版本中的所有 Chrome 用户的小幅版本缩减。请参阅此处的更新。 |
| 测试 | 请求从 Meta 延长用户代理缩减源试用的期限。 | 我们延长了源试用的期限，并获得了取消流量限制以适应大型网站的权限。宽松的流量限制适用于所有网站，无论网站大小。 |
用户代理客户端提示
| 反馈主题 | 摘要 | Chrome 响应 |
| （第 2 季度也有报告）
反欺诈 / 反滥用问题 |
通过 UA-CH 可能无法使用某些功能：点击重定向跟踪器和欺诈性点击。 | 第 3 季度更新：
我们收到了多家公司的积极反馈，表示他们未发现任何对其反欺诈流水线的不利影响（点击此处和此处可查看结果）。 该团队会继续与反欺诈和效果衡量利益相关方一起调查这些潜在问题。 |
| 权限政策 | Permission-Policy 是否缓存？ | Permission-Policy 未缓存， 如此 GitHub 问题中所述。 |
Gnatcatcher（制作中）
| 反馈主题 | 摘要 | Chrome 响应 |
| 地理定位用例 | Gnatcatcher 可能会阻止未来的合理地理定位用例，例如基于地理定位的内容个性化。 | 我们正在与利益相关方合作，确保 Chrome 继续为正当使用 IP 地址的行为提供支持。 |
强化跨网站隐私边界
First-Party Set
| 反馈主题 | 摘要 | Chrome 响应 |
| 政策 | 担心 FPS 不符合 CMA 承诺中关于“适用的数据保护法律法规”的条款，因为 GDPR 不对一组网站中的网站数量施加限制，而 FPS 规定的上限为 3 个。 | Google 已承诺 CMA 设计和实施 Privacy Sandbox 提案时，不得通过自我推销 Google 自己的业务来影响竞争，同时考虑到对数字广告、发布商和广告主的竞争的影响，以及对隐私保护成效的影响以及对《数据保护法律法规》中规定的数据保护原则的遵守情况。提出的问题未披露任何与 GDPR 不兼容的情况。我们将继续与 CMA 密切合作，确保我们的工作符合这些承诺。请参阅下面的“根据反馈做出的更改”部分，了解更多详情。 |
| 文档 | 请求提供更多示例并更新现有的铺垫消息。 | 我们的解说中的示例正在接受审核，将根据需要澄清或移除所有示例。 |
| 偏好设置共享 | 提议对同一组别的群体做出偏好。 | 我们欢迎大家提供反馈，并在 此处积极讨论相关创意。 |
| 违规处置 | 透明的违规处置流程有被作恶方滥用的风险。 | 我们非常感谢大家的反馈意见，并会积极参与与 GitHub 上的利益相关方对话（考虑此问题中提出的要点，并希望纳入此问题中提出的建议）和其他论坛，以评估这种风险并确定潜在的缓解措施。 |
| 共同拥有的所有权 | 提案中关于共同所有权的机器可读声明。 | 我们欢迎并欢迎大家就我们的提案提出反馈意见。 |
| 子网域所有权 | 具有不同数据控制方、不同隐私权政策或由不同实体运营的不同子网域是否应该属于同一 First-Party Set？ | 根据反馈，我们计划移除常见的 eTLD 用例。 |
| 滥用缓解 | 请求详细了解滥用缓解措施。 | 我们正在考虑如何管理该流程，并将在未来几个月内分享更多详细信息。 |
| 潜在攻击途径 | 黑客可能会利用针对易于找到的网页的欺骗性关联集，为其他那些以欺骗性/独立方式显示的网页吸引流量。 | 我们正在积极收集公众意见，并研究可能解决此问题的方法。 |
| 设置验证 | 通过已征得用户同意的通用政策验证集。 | Web 标准社区和更广泛的生态系统中的多位成员都指出这种做法不可行。 |
| 网域限制 | 请求增加关联网域的数量。 | 我们正在积极讨论 FPS 中的网域限制，因此希望社区能就其用例所需的关联网域数量提供更多反馈。 |
| 子集服务交互 | 对服务和相关子集互动的疑虑。 | 欢迎您提供反馈，我们会考虑在未来的规范中提高这一点。 |
| （第 2 季度也有报告）
加强隐私保护 |
同一组中的网站过多可能会导致与第三方 Cookie 类似。 | 第 3 季度更新：
最新的方案建议，“关联”子集（不包括 ccTLD 和服务域名）最多仅限三个域名。Chrome 正在积极与生态系统互动，以确定此限制是否合适。 |
| （第 2 季度也有报告）
通用隐私权政策要求 |
我们无法为需要共同涵盖的所有产品和管辖区维护一份通用的隐私权政策。 | 第 3 季度更新：
不再要求必须提供通用隐私权政策。 |
Fenced Frames API
| 反馈主题 | 摘要 | Chrome 响应 |
| 为什么在 iframe 上使用新元素而不是属性？ | 与提案框架框架而非现有 iframe 提案相关的问题。 | 我们欢迎大家提供反馈，并且愿意了解如何整合 此处所讨论内容的当前状态。 |
| 围栏框架中的 Intersection Observer | 有关围栏框架内信息可见度的问题。 | 大家都在积极讨论并对此进行评论，请参阅此文档和 GitHub。我们欢迎合作伙伴与我们分享使用场景，以便更好地了解如何提供支持。 |
| 支持视频广告资源和原生广告资源 | 围栏框架是否支持视频广告资源和原生广告资源？ | 就视频播放功能而言，围栏框架与 iframe 没有区别，因此，它未在任何公开文档中明确列出。如果我们发现视频广告出现任何问题，请提交反馈，以便我们进一步调查。 |
| Web 软件包 | 使用 Fenced Frame x FLEDGE 时，将来通过网站捆绑包进行广告投放 / 呈现是否会成为一项要求？ | 长期目标是支持使用 Web Bundle 在围栏框架中呈现广告内容。不过，FLEDGE 的当前实现不支持此功能，并且需要呈现从 renderUrl 检索到的 HTML 资源。 |
| 素材资源尺寸 | 请求 render_url 支持设置广告位高度和宽度的宏，以便我们在响应中提供尺寸合适的广告素材 | 我们正在此处积极讨论这一问题。 |
共享存储空间 API
| 反馈主题 | 摘要 | Chrome 响应 |
| FLEDGE 集成 | 共享存储空间与 FLEDGE 将如何集成？ | 虽然我们目前尚未实现这一目标，但我们希望探索这一想法，看看能否确保隐私保护得到妥善保护。我们鼓励有意向的各方在共享存储空间 GitHub 代码库或 FLEDGE GitHub 代码库中提交此提案可支持的潜在用例的建议。. |
| 数据保留 | 清除共享存储空间会降低效用。是否已考虑延长保留期限或删除个别键/值的功能？ | 我们一直致力于在用户隐私与效用权衡之间取得平衡。我们欢迎您就此调整提供反馈，并鼓励合作伙伴在测试共享存储空间时提供更多反馈和详细信息。 |
| 负面信号 | Mozilla 对共享存储空间提案的负面信号。 | 感谢 Mozilla 对提案的仔细审核。我们计划在近期回复他们的反馈。 |
条状标签
| 反馈主题 | 摘要 | Chrome 响应 |
| 分区要求 | 针对第一方 Cookie 的“分区”属性添加了明确的行为要求。 | 我们在 PrivacyCG 通话中讨论了这一点，并跟进了 GitHub 问题 并添加了备注。我们将继续与浏览器、开发者和隐私权社区合作，就某种行为达成一致并加以指定。 |
| 经过身份验证的嵌入 | 由于不同的分区会影响经过身份验证的嵌入，因此 CHIPS 可能会影响当前的 SSO 登录流程。 | 我们已了解经过身份验证的嵌入用例，正在努力探索解决方案。 |
| Cookie 分区限制 | 有些应用场景担心目前的 10 个 Cookie 限制可能不够用。 | 我们即将弃用 Cookie 数量上限，使其内存上限变为 12kb。这样，我们就能解决 Cookie 限制方面的问题，同时确保性能和浏览器内存占用量不会受到不利影响。 |
| 源试用时间表 | 在移除主机名边界要求之后，扩展 OT。 | 根据生态系统的反馈，我们延长了源试用的期限。 |
| 在 Chrome 中测试限制 | 由于 Chrome 的当前限制，可以在 Firefox 中测试 CHIPS。 | Firefox 的实现方式大相径庭，Chrome 的 Cookie 限制较低，CHIPS 是一种选择启用机制，但 Firefox 默认会进行分区。 |
| （第 2 季度也有报告）
经过身份验证的嵌入 |
是否通过 CHIPS 保留登录状态？ | 第 3 季度更新：
系统当前不会保留登录状态，但这并不是 CHIPS 的预期用例。我们已了解经过身份验证的嵌入用例，正在努力探索解决方案。 |
FedCM
| 反馈主题 | 摘要 | Chrome 响应 |
| （第 2 季度也有报告）
潜在的攻击途径 |
通过链接装饰和计时攻击的潜在攻击途径。 | 第 3 季度更新：
我们与 Mozilla 合作，希望就如何解决计时攻击问题达成共识。点击此处查看相关详情。我们目前正在设计这项架构更改的原型，预计将在接下来的几个季度进行实验。 |
| 身份提供方 | 帐号选择器：单一身份提供方。请求允许多个身份提供方。 | 我们已与浏览器供应商和 FedID CG 合作，探讨如何实现允许多个身份提供方，并得出一个看上去值得一试的方案。请点击此处查看提案说明，我们预计会在接下来的几个季度开发原型并运行实验。 |
| 关于联合的已知问题 | 请求枚举联合可能在弃用第三方 Cookie 时遇到问题的情况。 | FedID CG 有一项工作项，即枚举此处和此处取消联合的方式。他们还在此处构建决策矩阵，将破坏情况映射到 Web 平台 API。 |
| 名词参数 | Nounce 参数是否会影响登录流程？ | 这可能被视为跨网站跟踪，但我们仍在收集反馈并分析如何处理此类情况。 |
| 用户意见征求 | 为每个来源关联不同的依赖方 (RP) 和用户意见征求。 | 此规范无法控制同一网域中的源共享 Cookie 的方式。该规范允许从 IDP 源到 RP 源的 idtoken，但由 RP 决定是应将用户的登录状态存储在锁定到该单个源的 Cookie 中，还是存储在与同一网域中的源共享的 Cookie 中。 |
| IDP 帐号
可移植性 |
供用户在两个 IdP 之间转移时选择迁移 IDP 的选项。 | 用户需要直接在所选择的新 IDP 的注册页面中（而不是通过 FedCM API）执行这类操作。 |
| 删除账号 | IDP 撤消：将计入 IDP 的帐号删除。 | 此功能请求已开放，可供大家参考，并且正在接受调查。 |
| 界面声明 | 关于浏览器特定界面的声明。 | 如需解决此问题，请参阅拉取请求。 |
| IDP 引荐检查 | IDP 检查 RP 的引荐来源网址。 | 向规范中添加了强制性的 IDP 引荐来源网址检查。请参阅拉取请求。 |
| 登录流程 | 根据 RP 偏好设置自定义的登录流程请求。 | 我们欢迎这一想法，并正在积极讨论它。 |
打击垃圾内容和欺诈行为
Trust Tokens API
| 反馈主题 | 摘要 | Chrome 响应 |
| 欺诈和滥用行为 | 是否有工具可以确保聊天机器人没有诱骗颁发者向其提供令牌，机器人没有接管分配给真实用户的令牌，并防止机器人发出恶意令牌？ | 虽然机器人或许能够从颁发者获取令牌，但我们鼓励颁发者限制其颁发令牌的频率，并采取可靠的方法来颁发令牌和更新其颁发逻辑，因为恶意操作者试图规避它们。如果签发令牌的逻辑不够稳健，颁发者在生态系统中的可信度可能会降低，因为网站会优先依赖更可靠的颁发者。 |
| 欺诈和滥用行为 | 信任令牌兑换者有没有办法指定他们仅接受来自特定实体的信任令牌？ | 是的，这是有可能的。解释中的信任令牌兑换部分介绍了其运作方式。 |
| 欺诈和滥用行为 | 是否有办法让信任令牌颁发者定义兑换者列表，并禁止其他人兑换令牌？ | 目前还不能，但相关团队正在调查此用例。 |
| 时间安排 | Trust Token API 何时正式发布？ | 一旦我们可以确定时间表，就会公开分享更多信息。 |
| （第 2 季度也有报告）
维护开销 |
不清楚协议支持多长时间的协议版本。 | 第 3 季度更新：
我们将在 API 中添加对多个并发版本的额外支持，以便在版本之间平稳过渡，但支持 / 废弃期限尚未定。 |