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