2022 年第 2 季度季度报告，总结了收到的有关 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 技术发布时间表。 | 我们会在 privacysandbox.com 上公布当前的部署时间表，并每月更新一次。这些时间考虑了 Chrome 开发者和 Web 开发者的开发时间，以及我们从更广泛的生态系统收到的有关测试和采用新技术所需时间的反馈。每项技术都要经历从测试到发布（启动）的多个步骤，而每个步骤的时间安排取决于我们在前一个步骤中了解和发现的情况。虽然我们目前尚未确定发布时间，但一旦确定，我们一定会在 privacysandbox.com 上更新我们的公开时间表。 |
| 对不同类型的利益相关方的实用性 | 担心 Privacy Sandbox 技术会偏向大型开发者，并且小众（小型）网站的贡献比通用（大型）网站更大。 | 我们了解到，有些开发者对 Privacy Sandbox 技术的影响存有疑虑。Google 已向 CMA 承诺，在设计或实施 Privacy Sandbox 提案时，不会通过偏袒 Google 自家业务来扭曲竞争，并会考虑对数字广告竞争、发布商和广告客户以及隐私保护成效和用户体验的影响。我们将继续与 CMA 密切合作，确保我们的工作符合这些承诺。
随着 Privacy Sandbox 测试的推进，我们将评估的一个关键问题是，新技术对不同类型的利益相关方的效果如何。在这方面，反馈至关重要，尤其是具体且切实可行的反馈，有助于我们进一步改进技术设计。 |
| 第三方 Cookie 弃用时间表 | 请求避免进一步推迟第三方 Cookie 弃用计划 | 我们收到了一些利益相关方的反馈，他们希望 Chrome 立即弃用第三方 Cookie；还有一些利益相关方认为，需要更多时间来测试和采用 Privacy Sandbox 技术。鉴于这些技术的复杂性以及正确处理这些问题对生态系统的重要性，我们会以负责任的方式推进相关工作。业界和监管机构的反馈对此流程至关重要。 |
| 第三方 Cookie 弃用时间表 | 申请延迟第三方 Cookie 弃用，以便有更多时间测试 API。 | 我们收到了一些利益相关方的反馈，他们希望 Chrome 立即弃用第三方 Cookie；还有一些利益相关方认为，需要更多时间来测试和采用 Privacy Sandbox 技术。鉴于这些技术的复杂性以及正确处理这些问题对生态系统的重要性，我们会以负责任的方式推进相关工作。业界和监管机构的反馈对此流程至关重要。 |
| 文件请求 | 请求提供更多资源，详细说明如何管理测试、分析和实现。 | 我们很高兴开发者认为我们目前提供的资料很有帮助。我们将在未来几周和几个月内提供更多资料，包括开发者咨询时间和技术文档，以便开发者继续了解这些新技术对他们有何帮助。
我们还举办了面向外部开发者的公开咨询交流时间，分享最佳实践和演示，并与产品和工程主管举行问答会，以便进行实时讨论/提问。 |
| 行业专业知识 | 与标准机构互动的 Chrome 团队缺乏广告生态系统方面的专业知识，无法妥善平衡隐私性和实用性。 | 我们深知自己肩负着重大责任，因此需要依靠具体的反馈来确保一切顺利进行。我们还认为隐私保护和效果是至关重要的必要设计准则。负责 Privacy Sandbox for the Web 的团队在广告生态系统中的工作年数总和已远远超过了 100 年。 |
展示相关内容和广告
主题
| 反馈主题
（按流行程度排名） |
问题和疑虑摘要 | Chrome 回复 |
| 对不同类型的利益相关方的实用性 | 有人提出了关于网站创造价值和价值分配的问题，认为这些价值取决于网站的流量水平或内容的专业程度。 | 我们将通过测试来探索该 API 的实用性。Chrome 预计分类法和其他参数会根据测试结果不断演变。分类法或参数的演变可能不需要进行向后不兼容的更改。此外，Chrome 预计在弃用第三方 Cookie 后，反馈将继续影响 Topics API 的演变。 |
| 分类 | 行业利益相关方希望参与对分类体系的影响。 | Chrome 仍欢迎用户就分类提供反馈。Chrome 非常期待收到有关修改分类法治理模式的反馈，并就其他行业机构如何在长期内更积极地参与分类法开发和维护进行讨论。 |
| 浏览记录不足 | 建议：如果用户的浏览记录不足以针对最近一周创建 5 个主题，则显示调用方在前几周看到的主题 | 在目前的设计中，这些字符是随机选择的。我们将调查与过往主题之间的相关性，并考虑是否有可能将其纳入考量范围，但需要考虑相关性可能带来的不利隐私保护因素。 |
| 代表发布商调用 Topics | 第三方服务提供商能否与发布商共享主题？ | 是的，我们希望用户以这种方式使用主题。 |
| 潜在攻击途径 | 识别噪声主题 | 根据生态系统中许多人的反馈，Chrome 选择了过滤主题并引入噪声。我们在制定这些决策时考虑到了隐私保护，分别限制了原本无法访问此类信息的用户访问信息的权限，并为用户引入了合理的否认机制。我们知道，这些决定有缺点，例如此处所述的攻击媒介。不过，我们认为隐私保护方面的好处大于潜在风险。我们欢迎就此决定进行公开讨论。 |
| 源试用资格要求 | 是否有办法检测用户是否符合 Origin 试用条件？ | 由于浏览器设置或其他因素，用户可能无法使用来源试用功能，即使他们访问的网页提供有效的试用令牌，并且他们的浏览器包含在已启用试用功能的群组中也是如此。
因此，在尝试使用源试用功能之前，应始终使用功能检测来检查该功能是否可用。 |
| 性能影响 | 主题的开销和延迟时间问题 | 我们正在征求反馈，希望您就避免使用费用高且运行缓慢的 x-origin iframe 的方法以及分离 Topics API 的提案（以便获取主题不会更改浏览状态）提供反馈。 |
| 拆分 Topics API 功能 | 更好地控制 API 的三个不同方面 | 我们了解该用例，并在 GitHub 中提出了一种可能的解决方法。我们目前正在等待生态系统提供有关是否构建此功能的进一步反馈。如需查看正在进行的讨论，请点击此处。 |
| 分类器时间表和文档 | 开发者已请求提供有关分类器的更多信息。 | 我们已在此处公开提供了有关该分类器的更多信息。
以及此处 以及此处。 |
| 用户控制和安全 | 某些主题可能代表敏感群体，用户需要更多控制功能来防止出现负面结果。 | 主题是用户控制和透明度的一大进步。用户将能够选择停用主题、查看系统为其分配的主题、移除主题，以及了解哪些公司在特定网页上与其主题互动。此外，用户还可以通过删除浏览记录来影响其“兴趣”。我们欢迎继续讨论更高级的用户控制功能，例如开发者建议的功能；不过，我们需要确保针对此 bug 中提出的问题，这些功能实际上能够消除风险（例如，仅移除主题“外语学习”，但不移除根据浏览记录生成该主题的网站，并不能完全保护用户）。 |
| 在包含 prebid.js 的网站上使用主题 | Topics API 是否可以在使用 prebid.js 的网站上使用？ | 简短回答是肯定的。如需了解详情，请点击此处。 |
| 在推荐微件中使用 Topics API | 我们可以在推荐微件（例如 Outbrain）中使用 Topics API 吗 | 在调用该 API 后，我们不会限制检索到的主题的用例（这取决于每个开发者的政策）。 |
| 隐私权 / 政策 | 关于按来电者过滤回答的用途的问题，以及某些第三方是否会与任何来电者分享其主题的问题。 | 根据生态系统中许多人的反馈，Chrome 选择了这种设计，以限制原本无法访问此类信息的用户访问信息。当然，收到主题的发布商和第三方可以自行决定要与其网站上的各方分享哪些信息。如果他们要进行此类分享，Chrome 强烈建议他们向用户公开透明地披露此类分享，并为用户提供控制功能。 |
| 噪声信号 | 如果在 5% 的时间里传送随机主题，可能会产生过多噪声 / 虚假信号。 | 噪声是保护用户隐私的重要方法，我们将通过测试探索主题的噪声水平与实用性。 |
FLEDGE
| 反馈主题
（按流行程度排名） |
问题和疑虑摘要 | Chrome 回复 |
| 测试协调 | 测试效果和收入影响 | 我们正在公开的 WICG 会议中积极讨论 FLEDGE 性能，以及如何在源代码试用和正式版发布期间为生态系统测试提供最佳支持。 |
| FLEDGE 的可信服务器 | 受信任的服务器何时可供测试？ | 感谢您的反馈。我们正在积极制定更详细的计划，以便在 FLEDGE 中使用可信服务器。 |
| 协议标准化 | 是否会有在 SSP 和 DSP 之间传递数据的通用协议，例如兴趣群体的通用标签？ | 我们欢迎 DSP、SSP 和更广泛的广告生态系统就规范的潜在标准化提供反馈。目前，为了进行初始测试，我们建议您直接与测试合作伙伴合作，因为他们正在尝试不同的方法。我们还鼓励广告行业组织参与制定标准，以便为其成员公司提供帮助，并计划继续与这些组织合作。 |
| 频次上限 | 广告系列和广告组内的每位用户展示频次控制功能。 | FLEDGE 还将支持设备端竞价和内容相关 / 品牌广告系列的频次上限。共享存储空间和特定于网站的上限也可用于额外的频次上限控制。 |
| FLEDGE 对性能的影响 | FLEDGE 竞价中的计算密集型出价方 | Chrome 正在与开发者积极讨论此举对网站性能的潜在影响。Chrome 欢迎在测试期间了解更多信息。 |
| 结合使用其他功能测试 FLEDGE | Attribution Reporting API 和 FLEDGE 中的事件级报告将如何搭配使用？ | 我们在最近的 WICG/conversion-measurement-api 通话中讨论了这个问题，详细会议记录的链接在此处。
会议摘要：围栏框架广告报告的当前设计支持将围栏框架内生成的 ID 与情境信息相关联。因此，在围栏帧内生成的事件级报告将可与服务器上的相同情境信息联接（使用 2 次服务器端联接，而不是 1 次）。 |
| 展示次数统计 | 买方和卖方之间应或可使用哪种展示次数统计方法 | FLEDGE API 已支持在竞价期间让卖方和买方在方法上保持一致。我们收到了有关替代实现方式的建议，但没有收到有关当前设计为何不适用于该生态系统的反馈。 |
| 展示多个广告 | 在给定围栏框中，是否可以在一次竞价中展示多个广告 | 目前，您可以通过组件广告（请勿与组件竞价混淆）实现此目的。为此，所有广告都必须属于同一兴趣群体。 |
| “卖方定义的受众群体 (SDA)”规范和 FLEDGE | FLEDGE 能否成为一种机制，防止买方根据广告请求从 SDA 构建个人资料？ | FLEDGE 旨在避免在发布商已知其访问者所处的 SDA 且定位为同网站时，出现不相关的信息泄露。如果您非常重视在 FLEDGE 内置的所有保护措施下支持在 SDA 上进行购买，那么一种解决方案可能是让卖方将 SDA 标签传递到设备端竞价，而买方广告技术平台创建自己的兴趣群体，其出价逻辑为“我要购买受众群体 X”。 |
| 支持美元以外的货币 | 支持使用美元以外的币种测试 FLEDGE | 感谢您提出此建议，我们已在功能请求待处理列表中添加了对其他币种的支持。我们希望能够尽快推出这项功能。 |
| 支持排除性兴趣群体定位 | 支持否定 Instagram 定位的 API：仅在用户不属于某个 Instagram 账号时展示广告。 | GitHub 问题中正在进行讨论，包括一些提出的支持选项。 |
| FLEDGE 中的多个 SSP | 在 FLEDGE 中实现多级竞价时，偏向 Google 的风险 | 我们在 FLEDGE 中添加了对多个 SSP 的支持，以便为广告客户提供公平竞争环境。根据承诺，Google 承诺在设计、开发或实施 Privacy Sandbox 方案时，不会通过偏袒自家广告产品和服务来扭曲竞争。Google 非常重视这一点，并非常乐意与利益相关方讨论他们对该技术具体方面可能有的任何疑虑。如需了解详情，请参阅 此处 Chrome 公开记录的组件竞价机制。 |
衡量数字广告的效果
Attribution Reporting API（及其他 API）
| 反馈主题
（按流行程度排名） |
问题和疑虑摘要 | Chrome 回复 |
| 多接触点归因 | 请求多触点归因支持的发布商 | 目前的多触点归因方法需要确定性地将用户在不同网站上的展示次数（以及身份）联系起来。因此，此功能目前的形式与 Privacy Sandbox 的目标不符。Privacy Sandbox 旨在在不进行跨网站跟踪的情况下支持关键的广告应用场景。在某些情况下，无需跟踪个别用户，即可近似分配功劳（例如，通过使用加权的随机优先级）。 |
| 噪声生成 | 关于报告中噪声级别的问题 | 在我们的初始实验中，开发者可以自行设置 epsilon 值，以便了解报告会如何根据噪声水平而发生变化。目前，开发者可以选择的 epsilon 值上限为 epsilon=64。我们之所以这样做，是为了让开发者更轻松地测试 API，并就合适的 epsilon 值向我们提供反馈。 我们还公开请求提供此类反馈。 |
| 测试协调 | 本地测试工具能否用于 OT？ | 可以，在 OT 期间可以使用本地测试工具。只要第三方 Cookie 可用，本地测试工具就可以与调试报告搭配使用。 |
| 查询工效学 | 启用查询键的汇总 | 我们同意，这似乎可以改善 API 的人体工学，并且几乎不会对隐私造成影响。我们会提出一项提案，看看是否有广泛共识认为该提案值得支持。 |
| 小型网站的数据准确性较低 | 较小的网站或广告系列可能会收到不太准确的数据。 | Chrome 认识到，基于噪声的隐私保护措施对较小的数据片段的影响更大。不过，通过在更长时间内汇总数据等方法，或许可以解决此问题；此外，我们还不清楚基于非常小的数据片段（例如一次或两次购买交易）得出的结论对广告客户是否有意义。在来源试用期间，Chrome 鼓励测试人员利用实验功能来测试各种隐私和噪声参数，以便他们就此问题提供更具体的反馈。 |
限制隐蔽跟踪
用户代理缩减
| 反馈主题
（按流行程度排名） |
问题和疑虑摘要 | Chrome 回复 |
| 漫游器防护 | UA-R 对防机器人攻击功能的影响 | 感谢您的反馈。我们正在收集有关聊天机器人防范方法的信息，以便在日后的设计中加以参考。 |
| 部署依赖项 | 解决结构化用户代理 (SUA) 部署依赖项的问题 | 我们已面向 101 及更高版本的 100% 用户推出“第 4 阶段”，即次要版本缩减。请点击此处查看更新。 |
用户代理客户端提示
| 反馈主题
（按流行程度排名） |
问题和疑虑摘要 | Chrome 回复 |
| 枚举所有受支持的提示 | 希望以程序化方式了解浏览器支持的所有提示。 | 感谢您的反馈，我们正在评估该功能请求。我们希望了解这是否是一种常见的用例。 |
| UA-CH 与用户代理标头的灵活性 | 与 rfc7231 中定义的 User-Agent 标头所提供的灵活性相比，UA-CH 过于规范化。 | 从最终实现跨浏览器互操作性和保护用户隐私（通过阻止任意添加高熵标识符）的角度来看，Chrome 认为 UA-CH 标头的规范性相较于 UA 字符串的灵活性而言是一项重要改进。
此问题仍处于未解决状态，以便其他人也能看到此问题并提供反馈。 |
| UA-CH：反欺诈 / 防滥用问题 | 通过 UA-CH 可能无法再使用的一些功能：点击重定向跟踪广告代码和欺诈性点击。 | 该团队正在与反欺诈和效果衡量利益相关方一起调查这些潜在问题。 |
| 性能 | 我们对通过 Critical-CH 获取提示的延迟时间（在首次加载网页时）存有疑虑。 | Chrome 正在研究如何提高性能。 |
Gnatcatcher（开发中）
| 反馈主题
（按流行程度排名） |
问题和疑虑摘要 | Chrome 回复 |
| 延迟问题 | 添加额外的跃点可能会影响延迟时间 | 我们正在考虑使用两跳代理，并探索如何在用户隐私和延迟时间之间找到恰当的平衡点。我们乐于接受反馈，并希望在 W3C 论坛中进一步讨论。 |
| 欺诈和漫游器防护 | 对欺诈和聊天机器人防范的影响，包括在欠发达国家/地区 | 我们会寻找各种方法以有意义的方式加强用户隐私保护，例如通过代理 IP 地址来实现这一点，而安全性是核心要求。与信誉良好的公司合作的两跳代理可确保可验证的用户隐私。我们还在探索新的信号，以帮助传达用户信任。 |
| 遵守当地隐私权法 | 国家/地区级地理位置数据报告会使遵守更精细的本地法规变得困难 | 我们已公开发布我们提议的原则，其中包括可能有助于网站继续遵守当地要求的方法。 |
增强跨网站隐私边界
First-Party Set
| 反馈主题
（按流行程度排名） |
问题和疑虑摘要 | Chrome 回复 |
| 对不同类型的利益相关方的实用性 | FPS 对小型发布商和大型发布商的影响 | Privacy Sandbox 的主要目标是通过用不依赖跨网站跟踪机制的解决方案替代当前做法，加强对用户隐私的保护。我们希望这些解决方案能够尽可能广泛地为不同类型和规模的利益相关方提供帮助。我们欢迎您就如何改进这些解决方案提供具体的实用反馈，并希望这些解决方案能够随着社区讨论和测试的不断进行而不断发展。 |
| 加强隐私保护 | 如果同一组中包含的网站过多，可能会导致与第三方 Cookie 类似的结果 | 感谢您的反馈。我们正在评估是否有合适的上限，以及合适的上限是什么，同时也尝试为用户和开发者提供处理措施或信号，以便他们了解何时达到此类上限。我们目前还没有具体的方案可分享，但希望很快就能分享。 |
| FPS 的生态系统支持 | 收集有关如何在隐私保护 CG 之外继续开发 FPS 的支持和疑虑 | 虽然我们更希望第一方数据集提案留在 PrivacyCG 中，但我们期待继续在 WICG 中推进该提案。我们还收到了许多支持继续讨论第一方组及其预期用例的声明，这让我们深受鼓舞。Google 一如既往地致力于寻找解决方案，以便在保护和尊重用户隐私的前提下，让网络继续发展壮大。 |
| 浏览器互操作性 | 其他浏览器的实现 | 我们深知浏览器互操作性对开发者的重要性，并将继续与其他浏览器合作，以追求 FPS 标准化。 |
| 常见的隐私权政策要求 | 我们无法为所有产品和需要纳入同一组的管辖区维护一个通用的隐私权政策。 | Chrome 仍在制定政策要求，并会记下您的反馈。 |
Fenced Frames API
| 反馈主题
（按流行程度排名） |
问题和疑虑摘要 | Chrome 回复 |
| 文档请求 | 与沙盒化 iframe 的差异 | 感谢您的反馈和建议。目前，GitHub 上正在就此进行讨论，我们希望通过讨论最终明确该要求，以便全面评估。如需查看公开讨论，请点击此处。 |
| 跨 API 功能 | 默认支持在围栏框架中生成归因报告 | 我们正在征求反馈，就一项提案进行讨论，该提案旨在默认允许 Attribution Reporting API 在已围定的框架的“不透明广告模式”下运行。我们鼓励有需要的开发者参与讨论。 |
Shared Storage API
| 反馈主题
（按流行程度排名） |
问题和疑虑摘要 | Chrome 回复 |
| 数据量限制 | 每个分区可以存储的数据量是否有限制？ | 是的，会有限制。如需了解详情，请参阅 GitHub 问题。我们需要存储空间配额。我们目前的提案是，每个条目的大小上限为 4 KB，键和值均限制为每个 1024 个 char16_t 字符，每个来源条目上限为 10,000 个条目，并采用一种机制来防止在来源容量已满时提交其他条目。我们正在积极征求对此处提出的具体限制的反馈。 |
| 用户知情权 | 用户对数据源和数据使用情况的知情权 | 感谢您的反馈，我们认为这是一个值得探索的有前景的方法。具体而言，我们正在评估是否有可能以向用户提供充分透明度的方式实现这一点。 |
CHIPS
| 反馈主题
（按流行程度排名） |
问题和疑虑摘要 | Chrome 回复 |
| 采用障碍 | CHIPS 是否应绑定到主机名？（无网域要求） | 我们将从 OT 中移除此要求，因为 OT 参与者反馈说，此要求增加了复杂性，并阻碍了 CHIPS 的采用。
我们将在隐私保护社区群组中讨论此要求，并将其作为标准孵化计划的一部分在此进行讨论。 |
| CHIPS 的广告用例 | CHIPS 是否可用于单个网站上的 Google Ads 用例？ | 在一个网站内跟踪用户属于允许的用例。我们 更新了开发者文章，以突出介绍此用例。 |
| 经过身份验证的嵌入 | 登录状态是否会在使用 CHIPS 时保留？ | 目前不会保留已登录状态，但这并不是 CHIPS 的预期用例。我们已了解经过身份验证的嵌入使用情形，并正在探索解决方案。 |
| 测试协调 | 测试分区是否需要用户执行其他操作？ | 只要 OT 令牌有效且存在于所访问网页的标头中，用户应该就可以使用该功能，而无需执行任何其他操作 |
| 浏览器兼容性 | 有兴趣了解其他浏览器如何处理分区 Cookie 属性。 | Chrome 将继续在 W3C 等公共标准组织中开展工作，以确定可在各浏览器中运行的设计和实现。 |
FedCM
| 反馈主题
（按流行程度排名） |
问题和疑虑摘要 | Chrome 回复 |
| 潜在攻击途径 | 通过链接装饰和时序攻击的潜在攻击途径 | 我们正在积极收集公众意见，并研究可能的解决此问题的方法。 |
| 允许使用多个 IDP 的用户体验 | 一次只能显示一个 IDP | 我们坚信要支持多家 IDP，并正在积极研究支持这些 IDP 的方法。 |
| 表达力 | 担心由于浏览器会呈现联合身份流程的一部分，因此很难捕获 IDP 希望向其用户呈现的所有细微之处。 | Chrome 正在探索添加品牌自定义（例如徽标、颜色）和字符串自定义（例如“访问这篇文章”而非“使用此账号登录”）的功能。
Chrome 知道这种权衡，并将继续与生态系统合作，尽可能涵盖更多内容，并尽可能丰富其表达能力。 |
| 适用性和互操作性 | 担心其他浏览器不会采用或实施 FedCM。 | Chrome 还一直在与其他浏览器供应商合作，在 FedID 社区组中寻找联合身份验证的通用解决方案。 |
| 建议移除注册流程中的个人数据要求 | (1) 一种用户体验，可向用户指明他们选择的是哪个 IdP，但不会表明系统会分享他们的电子邮件地址、照片和姓名，这样更注重隐私保护
(2) 使用情形 - 注册的用户体验和从 IdP 中选择声明的选项较少 |
我们同意您的意见，并正在探索如何以更注重用户体验和隐私保护的方式实现这些反馈。 |
| 用户与 IdP 的互动 | 如果超出风险阈值，用户需要与 IdP 直接互动 | 我们正在积极调查此反馈。 |
网络状态分区
| 反馈主题
（按流行程度排名） |
问题和疑虑摘要 | Chrome 回复 |
| 性能 | 对网络状态进行分区可能会导致与 CDN 的资源密集型连接增加 | 我们仍在研究网络状态分区的性能特性，包括衡量不同的可能键值方案。我们尚未在性能、安全性和隐私性之间做出权衡，需要收集更多数据。 |
打击垃圾内容和欺诈行为
Trust Tokens API
| 反馈主题
（按流行程度排名） |
问题和疑虑摘要 | Chrome 回复 |
| 监管反馈 | 担心在没有监管机构明确表明信任令牌长期可行性的情况下，投入时间和资源 | 我们的目标是打造适合整个生态系统的技术，因此业界和监管机构的反馈对此至关重要。在开发 Privacy Sandbox 的过程中，我们将继续与全球监管机构进行咨询，并向开发者提供相关提案，包括信任令牌。与所有新技术一样，公司应根据自己对监管要求的评估做出决策。 |
| 发布时间 | Trust Tokens 何时会发布到 GA？ | 我们会在 privacysandbox.com 上的公开时间表中提供当前的预计发布时间。一旦我们就正式版发布日期做出最终决定，便会通过 Chrome 的发布流程公开发布该日期，并更新该网站上的时间表。 |
| 信任令牌与其他令牌相比 | 鉴于其他令牌（例如私有访问令牌）正在标准化，信任令牌发挥着什么作用 | 我们正在参与标准化讨论，目标是尽可能与其他工作保持一致，同时支持每项技术提供的不同用例。例如，信任令牌和私密访问令牌都依赖于 Privacy Pass 协议。 |
| 数据量限制 | 每页最多 2 个可用于兑换代币的发卡机构，可能会造成限制 | 我们正在寻找长期方案，以便在确保用户熵不增加的情况下，安全地允许公司兑换令牌，可能需要对令牌兑换权限进行分区。 |
| 访问权限限制 | 只有已获批准（且已验证/未被欺骗的引荐来源）的来源才能验证令牌是否存在并兑换令牌 | 我们正在探索可供哪些人查看和兑换代币的方法。 |
| 设备支持 | JavaScript 运行时依赖项限制了在某些设备上的使用。TT 支持是否可以扩展到其他类型的设备？ | 我们可能会在未来的开发中考虑这一点，也非常期待在 W3C 论坛中听取开发者对此的更多反馈。我们还有一个未解决的问题，旨在讨论 HTTP 标头触发的令牌兑换，欢迎您提供反馈。 |
| 使用场景 | 不清楚信任令牌的正确用例。未明确说明预期用途。 | 我们的目标是推动反欺诈领域的创新，我们理解每家公司都可能会使用专有技术来使用信任令牌，因此我们没有对预期用途做出规定。不过，我们可能会扩充文档，在其中添加更多示例，以便考虑进行实验或采用该功能的合作伙伴参考。 |
| 信任令牌覆盖率 | 移除此“trust-token-redemption”功能政策应该会显著提高信任令牌覆盖率。 | 我们会在收集 OT 反馈并就后续步骤做出决定时考虑这一点。 |
| 发卡机构信任 | 为什么我们应信任签发信任令牌的网站？ | 没有关于成为发卡机构的准则，任何人都可以成为发卡机构。发布商应仅与他们信任的发卡机构合作。此外，广告生态系统中的其他合法参与者最终也会对与可疑或未知发卡机构相关联的流量降价（或停止购买）。 |
| 第三方嵌入式服务 | 第三方嵌入式服务可以兑换和/或请求信任令牌吗？ | 可以，第三方嵌入式服务可以签发和兑换信任令牌。 |
| 发卡机构生态系统 | 如果可以与其他公司共享信任信号，则可以实现更大的效用 | 信任令牌旨在成为一种低级基元，可供合作发卡机构/兑换机构使用，以共享信任/声誉信号。 |
| 维护开销 | 信任令牌操作底层的加密实现位于 BoringSSL 中；Google 是其唯一的维护者。如何管理该库的维护？ | 信任令牌依赖于标准化加密操作（请参阅隐私通行证协议），这些操作也可以在其他库中实现。我们建议开发者在其选择的库中请求/开发/维护对这些操作的支持。 |
| 维护开销 | 不清楚协议版本将被支持多久 | 我们正在研究并记录有关协议版本预期支持时间范围的更多具体信息。 |
| 发卡机构限制 | 如果您位于链条的更下游位置，则可能无法执行信任令牌 | 随着越来越多的组织开始使用信任令牌，我们越来越多地发现此类时间动态，并正在研究可能的解决方案。如前所述，我们正在寻找长期方案，以便让公司能够安全地兑换令牌，同时不会冒增加用户熵的风险，从而最大限度地降低网页上的位置或加载顺序的重要性。 |
正在孵化的新反欺诈解决方案
| 反馈主题
（按流行程度排名） |
问题和疑虑摘要 | Chrome 回复 |
| 设备完整性证明信号 | 通常会大力支持获取由平台证明并提供给网站的设备完整性信号 | 我们将继续收集反馈，并通过公开设计和迭代来推进该提案。 |
| 设备完整性证明信号 | 关于能通过新信号传达多少用户熵的问题，以及是否可以通过某些用例（例如用户登录银行）来证明熵值较高的信号。 | 我们倾向于提供高价值信号，同时尽可能减少用户熵，以保护用户隐私。 |
| 设备完整性证明信号 | 此信号是否会限制旧版设备或开源/修改版平台的访问权限？ | 在开发任何新信号时，都应将普惠大众作为一项关键原则，我们在继续孵化过程中，需要先解决这些重要问题。 |
| 设备完整性证明信号 | 一些人担心，新信号会导致安全和反欺诈公司过度依赖浏览器和平台
|
任何新信号都应视为补充数据，而不是浏览器的“信任”指示。我们完全预计安全公司会继续依赖自己的专有数据、模型和决策引擎，并将设备证明作为额外输入。我们希望任何新信号都能提升整个生态系统的检测能力，让欺诈行为更难以实施。 |
| Cookie 年龄信号 | 这个概念很有趣，但可能需要对适用的用例进行更多调查。 | 根据感兴趣的程度，Chrome 可能会对此概念进行进一步的构想，并将其制作成说明文档，以便日后获得生态系统反馈。 |
| 用于防范欺诈的可信服务器 | 这个概念很有趣，但可能需要对适用的用例进行更多调查。 | 根据感兴趣的程度，Chrome 可能会对此概念进行进一步的构想，并将其制作成说明文档，以便日后获得生态系统反馈。 |