2023 年第 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、Protected Audience 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 响应 |
|---|---|---|
| 生态系统就绪性 | SSP 强调发布商未准备好以及未执行所需部署工作的问题。 | Privacy Sandbox 专门侧重于为发布商提供培训，包括专门的在线讲座以及与发布商和 SSP 召开的会议，共同推动部署工作。 |
| 弃用第三方 Cookie | 2023 年第 4 季度，由于行业技术中断，用户对第三方 Cookie 弃用 (3PCD) 的担忧会加剧。 | 我们已经与 CMA 讨论了 Privacy Sandbox 的时间表，相关顺序正在为 2024 年下半年做好准备。Privacy Sandbox 将发布更详细的 3PCD 提升顺序的信息。根据承诺，3PCD 受 CMA 所解决的竞争疑虑的约束。 |
| Google Ad Manager | Google Ad Manager 拒绝公开 API Surface，从而导致测试难以进行。 | Google Ad Manager 提供的响应：出于 Google Ad Manager 的此响应中说明的原因，Google Ad Manager 的 Protected Audience API 集成计划不包含无法控制顶级竞价的 Google 发布商广告服务器。 |
| Google Ad Manager | Google Ad Manager 有一项非公开底价仅适用于 AdX 或公开出价 SSP。 | Google Ad Manager 的公开文档中指出，内容相关竞价的胜出者将传递给顶级评分逻辑，而不是任何组成部分竞价，包括 AdX 或公开出价。 此外，该文档还说明了顶层评分逻辑：“Ad Manager 会比较每个组成部分竞价的胜出出价，包括 Ad Manager 针对其买方的兴趣群体出价的胜出出价，以及最佳的内容相关广告（通过动态分配选择），并会投放出价最高的广告。” |
| Google Ad Manager | Google Ads 产品应遵守与第三方广告产品相同的规则。 | Google Ads 产品需要遵守与第三方相同的规则。 |
| Chrome 协助测试 | 为非 A 或 B 的浏览器添加标签。 | 我们目前不考虑这样做，因为我们的调查发现，添加非实验标签可能会使无痕模式下流量的隐私问题变得更加复杂。 |
| 广告代理机构 | 网站上没有 JavaScript 的代理机构或公司能否使用 Privacy Sandbox API？ | 任何人都可以调用 Privacy Sandbox API。代理机构或其他任何人希望直接基于他们能够的 API 开发技术。客户端 API 需要与客户端集成，就像 Cookie 一样。很多 API（如 Cookie）也具有 HTTP 标头接口。我们已经见过一个广告行业框架 Prebid，它构建了与 API 的客户端集成。其他组织也可以这样做。 |
| 客户端解决方案 | 一位工程师以前对 2012 年此类解决方案的可伸缩性表示顾虑，为什么 Google 还为 Privacy Sandbox 采用客户端解决方案？ | 隐私保护技术 (PET) 是一个研究领域，自 2012 年以来有了很大的发展，并由此诞生了商业可行的应用。Privacy Sandbox 的核心是 PET 的组合，这在十多年前并不可行。此外，个人计算能力的增强，消费者对浏览器的期望和对隐私权的监管期望也在提高。 |
| 机器学习 | Google 计划将 Privacy Sandbox 用于机器学习用途吗？ | 目前，很多广告技术生态系统都在使用机器学习技术，我们预计这一情况不会改变。Privacy Sandbox 不会阻止广告技术公司或其他任何人继续使用机器学习技术。Privacy Sandbox 也不要求与其 API 集成的公司使用机器学习技术。合理的做法是，各公司将继续以能够满足其客户需求的方式构建产品和服务，无论是否包括机器学习。Privacy Sandbox 集成商构建的任何机器学习显然是他们所知，因此不会被遮挡。 |
| 数据验证 | 公司如何验证他们使用 Privacy Sandbox 接收的数据是否准确无误，并且 Google 是否愿意通过媒体评分委员会 (MRC) 等实体进行审核？ | Privacy Sandbox API 是在为 Chrome 提供支持的开源平台中构建的。用于在可信执行环境中运行的 API 部分也是开源且可审核。希望检查代码的任何人都可以检查代码，包括 MRC。 |
| （在前几个季度也会报告）制作支持 | Chrome 采用什么流程来为影响生态系统的 Privacy Sandbox 技术问题和上报问题提供支持？ | Google 提供了一系列渠道，让广告技术平台能够报告技术问题并进行任何必要的上报以解决此类问题。此外，Chrome 预计会进一步构建和扩展流程，以解决影响生态系统健康状况的技术问题和上报情况。Chrome 致力于确保为这项工作提供相关资源。 如需详细了解提供反馈和上报公共论坛和非公开论坛，请参阅我们的开发者博文。 |
| Chrome 协助测试模式 | 详细了解 Chrome 协助测试模式的时间表和确切实现方式。 | 我们分享了一篇关于测试模式的博文，目前正在努力分享更多信息。 我们欢迎建议测试模式标签的尺寸。 |
| 与其他业界标准集成 | Privacy Sandbox API 是否会连接到 TCF v2.* 和/或意见征求模式？ | 我们不打算将 Privacy Sandbox API 直接与 TCF v2 或意见征求模式集成。不过，我们欢迎公司和行业贸易团体调整其产品和框架，以便与 Privacy Sandbox API 配合使用。例如，使用 TCF 等框架时，每个参与者都必须根据收到的 TCF 信号和关联的 TCF 政策确定自己的合规方法。我们希望各公司能够自行决定何时以及如何使用我们的 Privacy Sandbox 基础组件提供的各种功能。 |
注册和认证
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 限制 | 通过注册流程，Google 可以决定生态系统中的哪家公司可以使用 Privacy Sandbox API。 | 注册和证明流程实质上需要对实体进行验证（例如，实体具有邓氏编码，可以提供指向隐私权政策的链接等），并要求公开证明才能调用这些 API。能够成功满足注册要求的实体将进行验证。对于没有 DUN 的公司，我们将通过 Dun & Bradstreet 提供的免费加急流程获取 DUN。目的是加强 API 的隐私保护（通过上述措施），并为 Privacy Sandbox API 提高透明度，以便感兴趣的各方可以更好地了解谁在使用哪个 API 以及他们进行了哪些证明。我们愿意就此问题向业界提供更多反馈，这些反馈已用于制定相应流程。 |
| 重新注册开销 | 认证文件每 12 个月过期一次，并要求网站重新注册。 | 我们听取了生态系统的反馈，并相应地修改了方法。也就是说，文件将不再在 12 个月后或任何设定的时间段后过期。我们将更新注册开发者指南，提供更多背景信息。 |
| 证明文件 | 如何使用证明文件？ | 只要您打算继续调用这些 API，所有调用相关性和效果衡量 API 的公司都需要在强制执行截止日期之前将证明文件上传到他们的网站上并保留以供公众查看。 网站预计每小时会向 Privacy Sandbox 发出大约 1 个请求，其他潜在实体也可能发出查询请求。此操作将通过注册系统自己的机制来查询已注册实体的服务器，并确保证明文件有效。 证明将包含在透明度报告中，并向公众开放。我们希望公司能够按照其声明的证明行事，整个生态系统的其他成员和相关监管机构也是如此。 |
| 注册 | 是按网站还是按源进行注册？ | 注册在站点级别进行。 |
展示相关的内容和广告
主题
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 性能 | 对欧洲经济区 Topics 选择接受率的影响的性能问题。 | 我们建议相关的利益相关方就此问题与相关的数据保护机构联系。它们最适合用来解决此类顾虑，并影响使用隐私保护增强技术的应用是受法律激励，还是像跟踪一样受到处理，因而需要采用相同的方法来征求用户意见。后者可能会导致 Privacy Sandbox 中的 API 这样的 API 不能经常使用。 |
| 注册 | 下游出价方是否需要注册 Topics API 才能使用上游 SSP 中的 Topics 信号？ | 对于初始 Topics API 调用方以外的主题的下游接收器，其无需注册，但许多接收器可能已注册，用于其他 API 用途。在该计划的透明度工作过程中，我们将以程序化方式提供 Privacy Sandbox 注册者列表，这让感兴趣的 Topics API 调用方可以检查接收主题的收件人是否已注册（如果调用方需要）。 |
| 主题过滤 | 请求将另一个调用方的过滤应用于他们在网页上检索到的主题，以便只共享买方有资格检索的主题。 | 我们正在考虑此请求，并欢迎您生态系统提供更多反馈。 |
| 网站排除 | 阻止网站为用户的主题贡献内容。 | 默认情况下，系统不会调用主题。请务必注意，选择主题时不会考虑网页内容，并且系统会精心挑选所有主题以确保它们不敏感。网站还可以通过以下权限政策标题限制其网站，使其不会被纳入主题计算中：Permissions-Policy:
browsing-topics=() |
| Topics 观察 | 允许发布商授予 Chrome 根据网页内容（例如头部或正文）对主题进行分类的权限。 | 我们之前考虑过提供根据网页内容对网站进行分类的功能，但基于隐私和安全方面的顾虑决定不继续操作。该方案可以缓解其中的部分顾虑，但不确定具体程度。由于 CMA 实验期即将到来，我们预计不会在 3PCD 之前发生这种变化。欢迎您在此处提供其他反馈。 |
| Topics 观察 | 为发布商提供更精细的权限政策。 | 为发布商提供更精细的权限政策将使发布商网站对 Topics API 在整个生态系统中的效用产生负面影响，而不会对 Topics API 对网站本身的效用产生负面影响。如需详细了解该主题，请参阅更新权限政策以支持单独的检索和观察权限 GitHub 问题。 |
| 医疗与健康主题 | 为什么主题分类未涵盖医疗或健康类别中的主题？ | 医疗和健康类别被视为敏感主题，因此从主题分类中排除。 |
| 主题检索 | DSP 可更快地获取主题，而无需使用标头进行提取。 | 与创建跨源 iframe 并从中进行 document.browsingTopics() 调用相比，标头方法性能更高，费用更低。（调用必须使用跨源 iframe，因为用于观察主题的顶级上下文必须与访问主题的上下文相匹配。）此处已对此进行了详细讨论。 |
| 主题检索 | 支持在跨源脚本标记请求中通过标头传递主题的请求。 | 从安全角度来看，这是不可能的。每个文档及其执行环境都与一个源（即该文档的来源）相关联。在同一环境中加载和执行的第三方子资源被视为归文档来源所有。这是为了防止数据因未经同意而从一个来源泄露到另一个来源。 另一种方法是在 <script> 标记上提供 browsingTopics 属性。从安全角度来看，这应该是没有问题的，并且不会增加额外的延迟时间。我们欢迎有意向的各方提供
反馈。 |
| 认知度 | 提高公众对 Topics API 及其使用方式的认知度。 | 我们已与提供此反馈的利益相关方进行了接洽，并在 GitHub 上解决了此问题。 今后，我们将继续支持生态系统对该 API 的理解，并期待收到利益相关方的意见。与此同时，我们建议希望详细了解 Topics API 的利益相关方熟悉 Chrome 开发者指南中的文档。 |
| 通知 | 当某个网站正在观察用户的 Topics 信号时提醒用户的通知。 | 我们在 GitHub 上解决了此反馈。用户可以在 Chrome 帮助中心详细了解 Topics 控件。 |
| 机器学习 | 如何使用机器学习技术来推断用户主题？ | 我们正在讨论此问题，欢迎其他反馈。 |
| 对不同类型的利益相关方的实用性 | 小型广告技术公司可能无法观察 Topics，由于浏览器计算 Topics 的方式。 | 只有观察用户在过去三周内访问了与相关主题相关的网页的广告技术平台才会收到主题。如果广告技术平台在过去三周内未针对某个有关该主题的网站上的用户调用该 API，则返回的值将为空。 此功能意味着，如果广告技术平台的服务被大量网站所有者使用，因而有更多机会观察指定用户对网站的访问情况，那么此类广告技术平台可能会收到比其他广告技术平台更多的主题。此功能对于该 API 的隐私保护至关重要，因为它将有关用户的信息限制为只有已经能够观察到相同基础信息（目前通过第三方 Cookie）的各方才能查看。 |
| XHR 请求 | 何时会弃用将主题纳入 XMLHttpRequest (XHR) 请求？ |
正如 Chrome 在 2023 年 8 月宣布的那样，Chrome 在从源试用转换为正式版时，便开始停止对 XHR 的支持。 随着 Topics 逐渐增多，XHR 支持仅为已启用 OT 功能的用户提供，并在合并各个 OT 实验组时被完全弃用。 如果您将 Topics 与 XHR 搭配使用，您的网站将不会中断。只是这些主题不会添加到您的 XHR 请求标头中。我们建议您针对请求改用 fetch、使用 iframe 属性或使用 JavaScript API 检索主题。所有现代浏览器都支持提取操作，但 Internet Explorer 或 Opera Mini 不支持。 |
| 分类和分类器更新流程 | 有关主题分类和分类器发布频率的更多信息，以及公司如何为此类更新做准备。 | 与第 2 季度相比，我们的回应保持不变： 正如最近的博文中所分享的那样，我们预计分类将随着时间推移而不断演变，并且，我们预计分类的治理最终将过渡到代表整个行业利益相关方的外部方。我们还在 topics-announce 论坛中分享了公开范围渐增计划。 |
| 滥用行为 | 可能存在通过重定向链进行的攻击。 | 我们正在考虑此问题，欢迎其他反馈意见。 |
| 发布商广告资源类型 | Protected Audience 和 Topics 测试支持哪些类型的发布商广告资源？ | 对于 Protected Audience 和 Topics 可以使用的广告资源类型，它们本身并没有限制。 |
| 磨合时间 | 建议不要让新分类达到 100% 的磨合期。 | 根据生态系统中的这一反馈请求以及 PATCG 会议期间的讨论，我们宣布了推出新分类的计划。 |
Protected Audience API（以前称为 FLEDGE）
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 顶级竞价 | 能够使用 Google 的发布商广告服务器，而无需向 Google Ad Manager 授予顶级 Protected Audience API 竞价的控制权。 | Google Ad Manager 提供的响应： Google Ad Manager 的 Protected Audience API 方案不支持不受顶级 Protected Audience 竞价的控制的 Google 发布商广告服务器，原因如下。 为了在发布商广告投放市场中为客户提供合理的服务，Google 的发布商广告服务器需要保留对顶级 Protected Audience 竞价的控制权。作为发布商广告服务器，我们的职责是为发布商提供预测数据，以便他们协商直销广告系列而不会导致超量预订，并以最佳方式安排和投放直接预订。为此，您需要运行最终竞价，以比较所有符合条件的直接和间接需求。 预测和投放节奏是发布商期望广告服务器能够使用的核心功能。如果不能进行准确的预测，发布商最终可能会过度销售其广告资源，这会危及其商业声誉。投放节奏也至关重要，因为无法履行与广告客户的预订合同还可能会破坏发布商与广告客户的直接关系，从而对发布商的业务产生重大影响。 因此，简而言之，我们不会将发布商广告服务器的开展顶级 Protected Audience 竞价活动与发布商广告服务器的其他活动区分开来。 |
directFrom |
directFrom可让 Google Ad Manager 阻止发布商查看其内容相关竞价的价格。 |
Chrome 响应： 传递到 runAdAuction() 的信息无法确定是否来自卖方，除非卖方从自己的 iframe 调用 runAdAuction()。在多卖方竞价中，不可能让所有卖方都创建调用 runAdAuction() 的帧。directFromSellerSignals 从卖方源加载的子资源 bundle 中加载了内容，从而解决了这个问题。这样可以确保从卖方竞价配置传递到竞价的信息的真实性和完整性不会被操纵。如果发布商想要使用 Protected Audience API 来了解其技术提供商传递到 Protected Audience 竞价的任何信息，可以请求这些技术提供商提供此功能。Google Ad Manager 提供的回应： 我们多年来一直非常关注竞价的公平性，包括我们承诺：在发布商参与竞价之前，我们不会与其他买方分享任何无保证广告来源的价格（包括无保证的订单项价格），之后我们在向法国竞争管理局的承诺中再次进行确认。 对于 Protected Audience 竞价，我们打算利用 directFromSellerSignals 来兑现我们的承诺，在完成多卖方竞价中的竞价之前，不与任何其他竞价参与者共享任何竞价参与者的出价。需要说明的是，我们也不会与自己的组件竞价共享内容相关竞价的价格，如进一步说明顶级竞价动态因素更新中所述。 |
| 信息泄露 | 浏览器可能会公开敏感的业务逻辑和合同详情。 | 使用网络浏览器的人可以看到浏览器中发生的所有情况。当广告竞价发生在浏览器中时，使用浏览器的用户确实可以观看竞价过程，包括查看不同方选择出价多少。由于浏览器是用户的代理，因此我们认为无法或不需要尝试改变这种情况。不过，只有使用浏览器的人才能查看这些操作。任何服务器（包括 Google 的服务器）都无法观测到使用 Protected Audience API 运行的设备端竞价。 |
PerBuyerExperiment |
PerBuyerExperiment的当前值范围可让买方将情境数据与可信服务器请求相关联。 |
以这种方式使用 Protected Audience API 不符合 Privacy Sandbox 的强制性证明，该证明是 API 用户不得试图规避 Privacy Sandbox 保护措施。将来，键值对服务器在可信执行环境 (TEE) 中运行的要求将为防范此类攻击提供技术保护。 |
| 同源政策 | 放宽同源政策以允许子网域。 | 我们正在考虑此请求，欢迎您生态系统提供更多反馈。 |
| API 版本控制 | 请求获取版本控制和版本说明，以了解对 Protected Audience API 的更改。 | 我们正在考虑此请求，欢迎您生态系统提供更多反馈。 |
| 多 SSP 竞价 | 允许顶级竞价信号与组件信号 auctionSignals 执行 JSON 合并。 |
我们正在考虑此请求，欢迎您生态系统提供更多反馈。 |
| 出价限制 | 将参与出价的广告组成部分的数量限制从 20 个提高到 40 个。 | 我们正在考虑此请求，并欢迎生态系统提供更多反馈，说明为什么此请求会有用。 |
| （在前几个季度也会报告） Protected Audience 竞价的效果 |
测试人员提供的报告，说明 Protected Audience 竞价的延迟时间较长。 | 在延迟问题方面，Protected Audience API 大体遵循现有的标准范例：构建控制机制，让卖方决定出价方可以消耗多少时间和资源；构建工具，让买方决定如何充分利用为他们提供的资源。这些控件和工具目前已正式发布，但只有在买方和卖方采用后，它们才能充分发挥它们的优势。此外，Chrome 会继续在基础架构方面做出各种改进，以提升竞价速度（crrev.com/1190815、crrev.com/1199839、crrev.com/1201837、crrev.com/1198339、crrev.com/1197323）。 我们诚邀您就此项延迟工作的两半方面提供反馈：买方和卖方认为有用的新工具，以及 Chrome 工程师应调查观察到的瓶颈的报告。 |
| 买方过滤 | 添加了对基于兴趣群体的买方过滤的支持。 | 我们已建议 SSP 和 DSP 通过以下几种方式更改其设计来处理此问题：
|
| 发布商兴趣组控件 | 支持希望授权使用发布商创建的兴趣群体的发布商。 | 我们已就该要求与多方展开讨论。 我们相信，“委托”发布商创建的兴趣群体涉及的所有此类用例现在都可以适应，而且我们应该构建额外的支持，使某些用例在未来更顺畅地流动。 |
| （也在第 2 季度报告）可信执行环境 | 支持非公有云环境中的可信执行环境 (TEE)。 | 我们的回应与之前几个季度类似： 虽然我们在继续探索对基于公有云的解决方案以外的其他选项的支持，但目前还没有支持本地 TEE 的计划。鉴于 Privacy Sandbox 的安全性要求以及本地部署带来的巨大挑战，我们认为，在此阶段，继续扩展和改进云端部署（例如，在 AWS 之外同时支持 Google Cloud）对生态系统最有利。不过，我们欢迎您就此要求在隐私权和安全限制方面的必要性和可行性提供其他反馈。 |
| 可信执行环境 | TEE 服务路径中的组件（例如负载平衡器）可以观察所有流量并包含每个请求的 IP 地址信息。 | 目前，对于出价和竞价以及设备端 Protected Audience 竞价，IP 地址会以请求标头中的元数据的形式传递给不可信卖方的广告服务。如需了解详情，请参阅元数据转发。从长远来看，我们计划通过 IP 代理来代理广告技术平台和跟踪器流量，这会阻止组件观察投放路径中的所有流量。 |
| 存留时间 (TTL) | 服务必须请求设置新密钥之前的存留时间 (TTL)，还是采用灵活（或动态）模式？ | TTL 通常是静态的。目前，公开的 TTL 为 8 天，每 7 天轮替一次；对于聚合服务，私钥的 TTL 也是相同的。对于出价和竞价服务，系统会在非请求路径中每 N 小时提取一次私钥和公钥，并将其缓存在内存中，因此，轮替密钥与服务器获取这些密钥之间的延迟时间不超过 N 小时。密钥轮替和过期之间设有 1 天的缓冲期，以确保即使密钥生成失败，服务也可以继续运行。我们正在考虑延长 TTL 以更好地应对服务中断。我们计划在密钥泄露时手动强制执行密钥，并尽早让密钥失效。请注意，公钥会缓存在客户端上（目前为 24 小时），以确保在协调者服务中断时，服务仍可正常运行。 |
| 根据流量情况调整投放速度 | 出价和竞价服务支持“根据流量情况调整投放速度”。 | 买方可以根据发布商第一方数据或情境数据，指明对 Protected Audience 竞价的需求。卖方也可以在其广告服务器或 Ad Exchange 服务器中做出类似的决定。这些模型可以基于第一方数据和来自 Protected Audience 竞价的任何汇总报告进行训练。当没有 Protected Audience 竞价需求时，卖方可以使用此信息避免向出价服务器和竞价服务器发送请求。我们相信这可以有效地提升流量。 |
| 组件拍卖 | 会与组件卖方共享哪些顶级竞价信号？ | 组件竞价中的买方仅接收来自组件卖方的信号。我们希望尽快分享有关结合使用标头出价和 Protected Audience 竞价的综合竞价序列的文档。 |
| 视频呈现 | 支持使用 Protected Audience 和 Fenced Frame 呈现视频。 | Protected Audience API 支持使用依赖 iframe 的机制呈现视频。然而，我们尚未设计出与围栏框架兼容的解决方案，这也是我们决定将围栏框架强制推迟到 2026 年的原因之一。这意味着，如果合作伙伴现在决定强制执行围栏框架，则将不支持该合作伙伴的视频。 |
| 频次上限 | （也在前几个季度进行了报告） 在广告系列和广告组中按用户的频率控制。 |
我们的回应方式与之前报告相同： Protected Audience 还支持设备端竞价以及内容相关广告系列和品牌塑造广告系列的频次上限。共享存储空间上限和网站专用上限也可用于额外的频次上限控制。 |
| 广告偏好设置 | Protected Audience 是否提供按广告客户网站选择停用或屏蔽名单的方法，或者是否提供让所有兴趣群体属于同一所有者的方法？ | 用户可以通过多种方式阻止访问 Protected Audience API 和其他 Privacy Sandbox 功能。 |
| 出价和竞价脚本的来源网址采用同源政策 | 放宽要求所有指定用于加载脚本或 JSON 的网址的字段必须与所有者同源。 | 我们目前正在考虑此请求，欢迎生态系统中的更多其他反馈。 |
forDebuggingOnly |
如果在 3PCD 后仍保留 forDebuggingOnly，则有可能遭到滥用。 |
在过去几年中，当第三方 Cookie 被弃用后，生态系统一直向我们反馈。我们欢迎您就生态系统希望看到的缺失功能提供任何其他建议和反馈。 |
| 多个兴趣组 | 在同一出价中使用多个兴趣群体。 | 目前，Protected Audience API 不支持此功能，因为这会导致底层隐私模型发生变化。欢迎点击此处进行其他讨论。 |
| 设备端竞价 | Android 版 Chrome 是否支持设备端 Protected Audience 竞价？ | 会，Android 版 Chrome 将支持设备端竞价。 |
| （报告于 2023 年第 2 季度）点击相关数据 | 将与点击相关的数据添加到 BrowserSignals 中。 | 我们会继续评估此功能请求，并欢迎您就为何应优先考虑此功能提供更多反馈。 |
| 可信执行环境提供方 | 不同云提供商提供的可信执行环境产品是否存在实质性差异？ | 我们不了解任何重大差异，但我们建议生态系统查看公开部署指南，了解哪种解决方案最符合其需求。 Google Cloud。 AWS。 |
| （在前几个季度报告） 支持排除的兴趣组定位 |
支持排除兴趣群体定位的 API：仅在用户不属于兴趣群体时展示广告。 | 我们正在考虑实现此功能，并讨论相应请求。 |
| 内容违规 | 支持可让用户在围栏框架中举报由 Protected Audience API 投放的不良广告的功能。 | 我们认为，现有的 围栏框架广告报告机制为希望采用用户生成的“不良广告”报告流程的广告技术平台提供了很好的选择。如此一来，不良广告报告便会与目前的业界标准基本一致。如果仍有差距，欢迎提出其他功能请求，包括从第三方 Cookie 移除后到围栏框架渲染广泛呈现之前的这段时间。 |
| Private Aggregation API 报告 | 如何计算用户在该兴趣群体上花费的时间？ | 在 Chrome M116 及更高版本中，您应该能够使用 pull/639 定义的新近度。 |
| K-匿名性服务器 | 详细了解 K-匿名性服务器。 | 我们点击此处分享了有关 K-匿名性服务器的更多信息，欢迎其他反馈意见。 |
| 动态广告素材网址 | 支持无需预声明的广告素材网址，同时仍遵循 k-匿名性。 | 我们正在讨论此功能请求，欢迎您提供更多反馈，让我们知道为何应优先考虑此功能。 |
| K-匿名性要求 | 是否会对兴趣组更新重新引入 k-匿名性要求？ | 我们预计这篇 GitHub 博文中提到的职位不会发生变化。正如该博文中所公告的那样，我们决定取消对 Protected Audience 兴趣群体更新的 k-匿名性要求，此要求不会对 API 的总体隐私保护机制产生重大影响，并且我们计划日后在相关技术进一步开发、部署和采用时，考虑其他可能的更直接的保护措施（例如 IP 地址隐私或受信任的更新服务器）。 |
| 出价和竞价服务 Beta 版测试 | 出价和竞价服务 Beta 版测试何时开始？ | 如时间表和路线图中所述，出价和竞价服务测试的第一阶段将于 2023 年 11 月开始。 |
| 包版 | 请求支持广告网络的广告素材协调（SSP 和 DSP 属于同一家公司或媒体资源）。 | 非常感谢您就此用例提供反馈，我们希望了解是否有更多的广告技术平台有兴趣看到此类支持。欢迎您提供其他反馈。 |
| 原生广告 | 为原生广告提供围栏框架支持。 | 我们正在考虑为该用例提供支持，并讨论可能的解决方法和解决方案。 |
| k-匿名性 | 如何最大限度地增加达到 k-匿名性阈值的兴趣群体广告？ | 我们就此主题分享了一些战术指南。 |
| POST 支持 | 支持通过 POST 请求发送竞价数据。 | 我们正在评估此功能请求，欢迎提交更多 GitHub 问题，说明为何应优先解决问题。 |
| 报告粒度 | 对于“由多个部分构成的广告”，围栏框架广告报告的报告粒度如何？ | 当前的设计不允许捕获商品 ID 或位置，因为这可能会危害用户隐私。只能调用 reserved.top_navigation，系统会在用户激活（例如点击）广告组件围栏帧时发送该调用，从而引发顶级导航。 |
| 广告竞价 | 参与组件竞价的 SSP 本身是否可以触发其他组件竞价？ | componentSeller 不能包含 componentAuctions。多卖家竞价只有两个级别： 1. 组件并行竞价。 2. 顶级竞价（每个 componentAuction 中胜出的广告参与竞争）。 |
| 出价和竞价服务的可用性 | 在 Chrome 协助测试阶段，是否会提供出价和竞价功能？ | 在 Chrome 协助测试阶段，出价和竞价服务器不可用。 |
| 出价信号 | 允许浏览器请求和删除出价信号。 | 我们正在讨论此请求，欢迎提供其他反馈，说明为何应优先处理此请求。 |
generateBid() |
能够通过 updateURL 更新 InterestGroup 的 userBiddingSignals。 |
我们正在考虑此方案，欢迎其他反馈和讨论。 |
| 发布商广告资源类型 | Protected Audience 和 TOPICS 测试将支持哪些类型的发布商广告资源？ | 对于 Protected Audience 和 Topics 可以使用的广告资源类型，它们本身并没有限制。 |
| 服务器到服务器集成 | Protected Audience 是否需要在 SSP 和 DSP 之间直接集成？ | 如果 DSP 不需要在自己的服务器中处理情境信号，即可将经过处理的信息传递到其设备端出价功能，则无需在 SSP 和 DSP 之间直接集成。 |
B&A 中的 bid_currency 字段 |
支持出价和竞价服务中的 bid_currency 字段。 |
B&A 尚不支持 bid_currency，但我们计划在 2024 年 1 月底之前支持。请参阅此处的时间表。 |
perBuyerSignals |
perBuyerSignals 是否有大小限制？ |
每个买方信号的数量没有限制，但发送过多数据可能会对浏览器性能产生不利影响。 |
| 跨网站用例 | 我们可以在多个网站上使用 Protected Audience API 兴趣群体吗？ | Protected Audience 并非专为此类用例而设计，如 turtledove/issues/282 中所述。 |
| 兴趣组 HTTP 请求 | 在 HTTP 标头中添加兴趣组 Blob。 | 我们正在考虑此请求，欢迎您就此请求提供更多反馈。 |
| 广告质量控制 | 失去与跨网站信息相关的广告质量控制。 | 我们正在考虑此反馈，欢迎您提供其他反馈。 |
| Chrome DevTools | 传出的 Protected Audience 网络请求应该会显示在 Chrome 开发者工具的“Network”标签页中。 | 我们正努力在“网络”标签页中启用此功能，欢迎提供其他反馈，让我们了解应优先实现这一点的原因。 |
| 可信执行环境 | 何时会在可信执行环境监控说明中添加有关哪些指标影响隐私（及其程度）的详细信息？ | 我们正在使用此信息更新铺垫消息。更新后的说明功能将于 2023 年 11 月推出。 |
directFrom |
为什么 directFrom 未打包为 Web 软件包？ |
我们在此分享做出此决定的理由。 |
| 展示委托 | 在选择兴趣群体的结果是另一项定位操作的情况下，是否有可行的方法来执行展示委托？ | 多次嵌套竞价与我们的隐私保护目标不兼容，原因有两个。首先，当竞价胜出者在围栏框架内呈现时，Protected Audience 的隐私保护目标包括在不知道上下文的情况下呈现广告素材：周围页面的网址或第一方 Cookie 侵犯了隐私权。在这种情况下，嵌套竞价是不可行的。其次，Protected Audience 模型表示每次竞价的胜出者应仅基于来自另一个网站的数据。嵌套竞价是一种复合竞价方式，使广告客户能够根据涉及多个网站的资料选择广告。 |
| “静态数据”条件 | 进一步解释键值对服务信任模型中的“静态数据”条件。 | 键值对服务中的数据将加载到内存中并通过内存提供，而不会执行任何直读缓存。 |
| 买方数据信号 | 对于从 DSP 接收的 buyer_data 信号，是否有定义的大小限制？ |
目前，浏览器对从 DSP 接收的 buyer_data 信号没有施加任何限制。 |
衡量数字广告的效果
Attribution Reporting（和其他 API）
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 跨设备 | 规划好针对 Attribution Reporting API 的跨设备支持。 | 除了 3PC 之外，跨设备还带来了新的隐私保护挑战，并且根据用户可能使用的设备和平台范围，增加了技术分发挑战。我们正在探索潜在的解决方案，但专注于 Attribution Reporting 目前支持的关键用例，并且没有计划在移除第三方 Cookie 之前引入跨设备支持。 |
| （在前几个季度也会报告） 触发器数据大小 |
为什么触发器数据大小限制为 3 位？ | 该大小被限制为 3 位和 8 个不同的值，以确保关于用户的跨网站和跨上下文信息量是有限的。我们欢迎生态系统参与者提交反馈，以了解事件级报告的当前参数化是否足够。 |
| 转化漏斗 | 报告在转化中使用的多个网域。 | 由于添加多个目的地，此用例成为可能。我们欢迎您提供其他反馈。 |
| 同一网域在不同国家/地区提供支持 | 归因报告是否适用于具有相同网域但有多个国家/地区 TLD 的网站？ | 我们已与提出此问题的利益相关方讨论并解决了此问题。如果广告技术平台需要使用多个国家/地区的 TLD，则需要进行多次注册，每个国家/地区 TLD 进行一次注册。 |
| Protected Audience 和 Attribution Reporting | 广告技术平台能否同时获取 Protected Audience 竞价的浏览型转化和 Attribution Reporting 的点击型转化？ | 是，Privacy Sandbox 应同时支持 Protected Audience 中的浏览型转化和点击型转化。 |
| 可汇总报告延迟 | 进一步缩短可汇总报告的延迟时间。 | 我们最近收到了关于此问题的反馈，并在此处分享了他们的想法。 我们欢迎 YouTube 生态系统提供更多反馈。 |
| 可汇总报告延迟 | 通过引入服务器中介来减少延迟。 | 我们正在考虑此方案，欢迎其他反馈意见 。 |
| 事件级报告延迟 | 缩短事件级报告延迟时间。 | 灵活事件级配置中所述的完整事件级方案 |
| 来源报告来源（每个来源） | 如果限制每个来源报告网站的来源报告来源数上限，会阻止广告技术平台为单个发布商来源注册不同报告来源的来源。 | 我们已与提出此问题的利益相关方讨论过，在尝试其他涉及重定向的潜在解决方案之前，正在测试一种可能的解决方案：为每个来源报告网站使用 1 个报告来源。 我们也欢迎您就此上限向生态系统提供任何其他反馈。 |
| 问题报告 | 如何向 Chrome 报告 Attribution Reporting API 错误或问题？ | 目前，我们建议广告技术平台在 GitHub 上报告他们可能遇到的任何 Attribution Reporting API 错误。如果他们遇到与 Chrome 相关的问题，我们建议您创建 Chromium bug。您可以在互动和分享反馈中找到有关如何以及在哪里举报任何问题的链接。 |
| 去重功能 | 如何跨不同流水线和设备删除重复的转化？ | 跨设备和衡量流水线间的重复数据删除是目前已知的以及广告技术平台在使用 3PC 时面临的挑战。借助 Attribution Reporting API，广告技术平台可以决定何时注册特定转化并添加特定元数据，以指明他们已使用哪些衡量流水线（即汇总键的一部分）来跟踪转化，并将其与其他衡量流水线进行比较。 我们欢迎您就生态系统提供任何其他反馈。 |
| 重复信息删除和优先级 | 请求在删除重复信息之前优先拥有优先级。 | 我们正在考虑此请求，欢迎您提供其他反馈。 |
| 防欺诈 | 有恶意用户篡改事件级数据的风险。 | 报告验证不适用于事件级报告，原因请参阅“为什么此功能不支持事件级报告？”。 |
| 转化类型 | 如何区分归因报告中的浏览型转化和导航？ | 我们提供以下内置过滤选项：source_type。如需了解更多详情，请点击此处。 |
汇总服务
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 预算恢复 | 一些广告技术平台曾请求我们能够在报告出现失败、错误或遭到删除的情况时重新处理报告。 | 该团队正在探索以可保护隐私的方式解决此问题的方法。 |
| 网站注册 | 多个广告技术平台请求支持在同一帐号中处理多个源站，以用于按地理位置、广告主拆分数据等用例。鉴于客户端 API 注册现在是基于网站（而不是基于来源），因此广告技术平台也在预料到此行为。从来源注册到网站注册之间的迁移与客户端注册流程保持一致，可简化广告技术平台初始配置流程。 | 我们很快将启动汇总服务的迁移（从源注册到网站注册），并欢迎来自生态系统的反馈。 |
| 发布和弃用计划 | 已发布的汇总服务功能和补丁的发布和弃用时间表。该计划的目标是让广告技术平台了解我们的发布政策，使他们为即将发布的版本和弃用做好准备，并确保它们运行稳定、安全的服务版本。 | 我们最近发布了 Aggregation Service发布和弃用计划的提案，并欢迎您提供其他反馈。 |
| 协调者 | 如果协调者关闭汇总服务，会发生什么情况？ | 这两个协调器都需要完全可用，以便系统正常运行。我们的客户端库中的重试可以应对短期不可用的情况；如果两个协调器中的任何一个不可用，聚合作业将失败。 如果尚未用完用于保护隐私的预算，则可以重新运行作业。如果任何服务失败都会导致预算消耗，而系统没有向广告技术平台存储空间写入摘要报告，那么目前我们建议他们使用调试报告来使用本地测试工具获取结果。 此外，我们还在开发相关功能，以便在失败时恢复预算，以便广告技术平台可以重新运行其作业。 |
Private Aggregation API
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| Blob 网址 | 请求支持共享存储空间中的 Blob Url。 | Chrome M116 中新增了对 Blob Url 的支持。 |
限制隐蔽跟踪
用户代理缩减和用户代理客户端提示
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| JavaScript API | 用户代理客户端提示 JavaScript API 的可用性。 | 我们没有移除此功能的计划，因为这是我们的核心解决方案，适合希望主动访问冻结和减少的 UA 中默认可用的高熵数据以外的高熵数据。 |
| 设备和外形规格信息 | 让网站能够理解输入、输出以及访问网站的设备能够支持的其他信息。 | 我们根据生态系统的反馈，添加了对此请求的支持。 |
IP 保护（以前称为 Gnatcatcher）
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 符合条件的第三方流量 | 说明中提到的“符合条件的第三方流量”指的是什么？ | 我们了解此问题的重要性，并正在积极努力确定哪些第三方流量符合条件，哪些不合格。欢迎就这一主题提供反馈。 |
| 网络流量审核 | 支持企业对其网络执行网络流量审核。 | 只有嵌入在第一方网站中的第三方流量会受到影响，这应该会限制需要过滤的流量。此外，我们计划允许用户选择是否使用 IP 保护；对于企业控制的 Chrome，我们提供了用于停用 IP 保护的企业政策。最后，我们将探索向网络运营商提供哪些控件（如果有）来停用 IP 保护。欢迎就这一主题提供反馈。 |
| 访问权限控制机制 | IP 保护可能会影响使用 IP 地址进行访问权限控制的网络服务。 | 我们了解防欺诈用例的重要性，以及这些用例可能的影响。我们正在寻求生态系统的反馈，了解如何更好地支持通常依赖于 IP 地址的防欺诈用例。 |
| 两跳代理之间的通信 | 如何确保代理之间没有任何信息。 | 我们正在设计代理交互。我们的目标是尽可能减少通过业务、流程和技术方式分享此类信息的可能性。 |
| 非 Google 身份验证 | 支持非 Google 身份验证。 | 我们计划将来发布有关帐号身份验证的更多详细信息，不过我们初步讨论了一些注意事项。 |
| 跟踪器分类 | IP 保护如何确定跟踪器及其变体的构成要素？ | 我们了解此问题的重要性，并正在积极努力确定哪些第三方流量符合条件，哪些不合格。欢迎就这一主题提供反馈。 |
| 分析 | IP 保护可能会影响分析服务的准确性。 | 我们希望进一步了解 IP 保护的影响，并欢迎您从生态系统中获得其他反馈和示例。 |
| 代理 | 如果用户使用代理或已手动定义代理，在这种情况下，IP 掩码如何工作？ | 我们希望了解 IP 保护可能会对其他代理造成的影响。我们目前没有任何可分享的计划。欢迎就这一主题提供反馈。 |
| 高级方案 | “IP 保护”是一项付费功能吗？ | IP 保护将作为核心浏览器体验的一部分提供给 Chrome 用户。此功能并非付费功能。 |
| 代理服务器 | 用户会话期间是否会使用相同的代理服务器？ | HTTP/HTTPS 连接将使用一对代理，并向来源提供单个遮盖的 IP 地址。除此之外，对于必须使用相同服务器的不同 HTTP/HTTPS 连接，并没有硬性限制。 |
| 平台支持 | IP 保护功能在哪个平台上受支持？ | IP 保护功能最初适用于 Android 版和桌面版 Chrome。我们会继续评估如何将保护扩展到其他平台。 |
| 选择退出 | 用户能否停用 IP 保护？ | 我们计划让用户自主选择是否要使用 IP 保护。 |
| 匿名化 | 在“IP 保护”下，系统会对哪些类型的请求进行匿名化处理？ | 向符合条件的第三方网域的 HTTP/S 和 DNS 请求将通过隐私代理进行匿名化处理。我们将在后续说明中详细介绍如何确定要包含哪些网域。其余流量（例如其余 DNS 请求或其他 HTTP/S 流量）不受影响。 |
| 数据可见性 | 可以在 IP 保护中的第一个跃点访问网络地址。 | 在双跳代理模型中，第一个跃点（由 Google 控制）只能看到来源客户端 IP 和连接到第二个跃点的请求，而第二个跃点（由外部 CDN 控制）只能看到第一个跃点（代理 IP + 端口）和目标 IP 上的元组。对于从源站返回的响应，第二个跃点能够将响应转发到与请求关联的第一个跃点代理 + 端口，并且不需要了解有关原始客户端 IP 的任何信息（第一个跃点只是将响应返回给客户端，而不会获得关于目标 IP 的任何信息）。这样，第一个跃点仅获知客户端 IP 和第二个跃点，而第二个跃点仅获知目标 IP。 |
| WebView | Android WebView 将来是否会提供 IP 保护？ | 我们目前还没有计划要透露，但我们的目标是尽可能为广大客户提供这项保护。 |
“反弹跟踪缓解措施”相关提案
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 互动跟踪 | 如何跟踪用户互动？ | 跳出跟踪缓解措施可以跟踪两种类型的用户互动： 这些互动会与发生互动的网页中的顶级网站相关联。例如，如果用户点击嵌入式 iframe，其互动会与顶级网站（而不是嵌入式网站）相关联。 互动存储在数据库中，其中包含 schemeless etld+1 和互动时间。 互动可在 45 天内防止关联的网域被跳出跟踪缓解状态删除。 |
| 已列入许可名单的豁免 | 网域是否可以豁免？ | 我们正在考虑此请求，欢迎您从生态系统中获得其他反馈。 |
隐私预算
本季度未收到任何反馈。
强化跨网站隐私边界
Related Website Sets（以前称为 First-Party Set）
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 集中式方法 | 担心用于管理 Related Website Set 的集中式代码库方法。 | 易于访问的公开代码库对于 RWS 的设计至关重要，因为它提供了对提交内容的问责制。第三方 Cookie 功能最终是通过使用 Storage Access API 或 rSAFor API 提供的，其中 RWS 成员提供自动授予访问权限（而不是通过 Storage Access API 提示）。我们认为，像 RWS 提交流程这样的方法适用于自动授予的第三方 Cookie 访问权限。 |
| 正在重命名 JSON 文件 | API 名称发生更改后，是否需要更改托管的 JSON 文件名？ | 是的，提交准则已更改，主网域必须在 /.well-known/related-website-set.json 中提供 JSON 文件。无需更改 RWS 列表中的现有集，但如果对现有集提交了修改，则必须更改 JSON 文件。 |
| （已在前几个季度中报告）网域限制 | 请求增加关联网域的数量 | 正如 8 月 31 日的一篇博文中所宣布的，根据生态系统的反馈，我们已将关联网域数量上限提高到五个。我们已决定将相关网域限制增加到五个网域（以及 1 个主域名），以便与另一个主要浏览器提供的非常具有可比性的实现方案最为相符。 |
| 第三方 Cookie | Related Website Set 能否仅在停用第三方 Cookie 的情况下运行？ | 即使用户未屏蔽第三方 Cookie，Related Website Set 也可以正常工作；但这不会产生可观测的影响，因为相关 Cookie 无需任何 Related Website Sets 和 Storage Access API 即可使用。 |
| 合法修改 | Related Website Set 代码库如何防止非所有者修改集合？ | 根据提交指南，任何人都可以在 GitHub 上提交 PR 来修改 first_party_sets.JSON 文件。但是，如果 PR 获得批准（通过技术验证等），Google 会每周手动将其批量合并到规范 FPS 列表中（美国东部时间星期二中午 12 点）。如果恶意者尝试修改并非自己拥有的集，这不成问题，因为他们无法修改 .well-known 文件，因而验证将失败。 |
| 域名盗用 | 网域盗用可能会将相关网域数据暴露给未经授权的方。 | 这不可能，如此 Protected Audience GitHub 问题中所述。 |
Fenced Frames API
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 内容违规 | 允许用户举报可疑广告。 | 围栏框架不会阻止可疑广告举报。用户仍然可以与广告互动，并以常规方式向广告技术平台报告可疑广告。 |
| 与周围网站的互动 | 允许与周围或顶级网站互动。 | 我们希望了解这项申请的必要性，并欢迎 YouTube 生态系统提供更多反馈。 |
| 原生广告 | 为原生广告提供围栏框架支持。 | 我们正在考虑为该用例提供支持，并讨论可能的解决方法和解决方案。 |
共享存储空间 API
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 跨网域 | 允许跨网域通信以实现本地存储空间。 | 此用例目前不符合共享存储空间的隐私保护输出门控，但随着我们不断完善非分区存储提案，欢迎提供其他背景信息。 |
| Blob 网址 | 请求支持共享存储空间中的 Blob Url。 | Chrome M116 中新增了对 Blob Url 的支持。 |
条状标签
本季度未收到任何反馈。
FedCM
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 第三方 Cookie | 如果用户在 Chrome 设置中启用“阻止第三方 Cookie”，目前是否停用了 FedCM？ | 是的，FedCM 目前已停用。对于测试，我们建议您额外启用 chrome://flags/#fedcm-。未来，我们希望在不使用第三方 Cookie 的情况下支持 FedCM。 |
打击垃圾内容和欺诈行为
Private State Token API（和其他 API）
| 反馈主题 | 总结 | Chrome 响应 |
|---|---|---|
| 令牌过期 | 卸载 Google Chrome 后，令牌会丢失还是会被缓存？ | 如果用户卸载 Google Chrome，此令牌将会丢失。 |
| 令牌信息 | 颁发者如何确保私密状态令牌中已颁发的信息保持私密状态？ | 信息始终在令牌中保持私密状态，没有密钥的外部相关方无法解密信息。 |
| 演示出错 | 尝试运行私密状态令牌演示时出错。 | 我们已更新演示，现在应该可以正常工作。 |