此页面由 Cloud Translation API 翻译。

反馈报告 - 2023 年第 3 季度
bookmark_border 使用集合让一切井井有条根据您的偏好保存内容并对其进行分类。

2023 年第 3 季度季度报告，总结了收到的有关 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、Protected Audience 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 回复
生态系统准备情况	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 具有一个秘密底价，该底价仅向 Ad Exchange 或公开出价 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 构建技术，他们可以。与 Cookie 一样，客户端 API 也需要与客户端集成。许多 API（如 Cookie）还具有 HTTP 标头接口。我们已经看到一个广告行业框架（即预出价）与这些 API 建立了客户端集成。其他组织也可以这样做。
客户端解决方案	2012 年，一位工程师曾对此类解决方案的可扩展性表示担忧，那么 Google 为何要为 Privacy Sandbox 采用客户端解决方案？	作为一门学科，可增强隐私保护的技术 (PET) 自 2012 年以来已取得长足进步，与此同时，可用于商业应用的 PET 也不断涌现。Privacy Sandbox 的核心是 PET 的组合，这种组合在 10 多年前是不可行的。此外，个人计算能力不断提升，消费者对浏览器的期望和监管机构对隐私保护的要求也越来越高。
机器学习	Google 计划如何将 Privacy Sandbox 用于机器学习用途？	如今，广告技术生态系统的大部分部分都使用机器学习技术，我们预计这种情况不会改变。Privacy Sandbox 不会阻止广告技术公司或任何其他人继续使用机器学习。Privacy Sandbox 也不要求与其 API 集成的公司使用机器学习。我们有理由相信，无论是否使用机器学习，公司都将继续以满足客户需求的方式打造产品和服务。Privacy Sandbox 集成商构建的任何机器学习模型显然都会为他们所知，因此不会对他们隐瞒。
数据验证	公司如何验证自己通过使用 Privacy Sandbox 收到的数据是否准确？Google 是否愿意通过 Media Ratings Council (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 & Bradstreet 提供免费的加速流程来获取邓氏编码。目的是通过上述措施增强 API 的隐私保护功能，并为 Privacy Sandbox API 增添一层透明度，以便相关方更好地了解哪些人在使用哪些 API 以及他们在进行哪些证明。我们欢迎业界就此问题提供进一步反馈，这些反馈已用于制定此流程。
重新注册开销	认证文件每 12 个月就会失效，网站需要重新注册。	我们听取了生态系统的反馈，并相应地修改了我们的做法。这意味着，文件将不再在 12 个月或任何设定的期限后过期。我们将更新注册开发者指南，在其中添加更多背景信息。
认证文件	如何使用认证文件？	所有调用相关性和效果衡量 API 的公司都必须在强制执行截止日期之前在其网站上上传认证文件，并使其保持公开状态（前提是您打算继续调用这些 API）。网站每小时可能会收到 Privacy Sandbox 发出的大约 1 次请求，其他潜在实体也可能会发出查询。这将通过注册系统自己的机制进行，以查询已注册实体的服务器并确保认证文件有效。认证将包含在透明度报告中，供公众查看。我们希望各公司都按照其声明的证明采取行动，生态系统的其他成员和相关监管机构也应如此。
注册	注册是按网站还是按来源进行的？	注册是在网站一级进行的。

展示相关内容和广告

主题

反馈主题	摘要	Chrome 回复
性能	关于欧洲经济区主题选择接受率对效果的影响的疑虑。	我们建议相关利益相关方就此问题与相关数据保护机构联系。他们最有能力解决此类问题，并影响法律是否会鼓励应用增强隐私保护技术，还是将其视为跟踪行为，从而要求采用相同的意见征求方法。后者可能会导致 Privacy Sandbox 中的 API 等 API 的使用频率降低。
注册	下游出价方是否需要注册 Topics API 才能使用上游 SSP 中的 Topics 信号？	除了初始 Topics API 调用方之外，主题的下游接收器不需要注册，但许多接收器可能会因使用其他 API 而注册。为了提高该计划的透明度，我们将以程序化方式提供 Privacy Sandbox 注册者名单，以便 Topics API 感兴趣的调用方（如果愿意）检查他们要向哪个收件人发送主题，以及对方是否已注册。
主题过滤	请求将其他调用方的过滤条件应用于他们在页面上检索到的主题，以便仅分享买方有资格检索的内容。	我们正在考虑此请求，欢迎生态系统提供更多反馈。
网站排除	排除网站，使其无法为用户的“兴趣”提供数据。	默认情况下，系统不会调用主题。请务必注意，在选择主题时，系统不会考虑任何网页内容，并且所有主题均经过精心挑选，以确保不涉及敏感内容。网站还可以通过以下权限政策标头限制其网站包含在主题计算中：`Permissions-Policy: browsing-topics=()`
主题观察	允许发布商授权 Chrome 根据网页内容（例如标题或正文）对主题进行分类。	我们之前曾考虑提供基于网页内容对网站进行分类的功能，但出于隐私和安全方面的考虑，决定不再继续推进。此提案可能会缓解其中一些问题，但具体程度尚不清楚。由于即将开始 CMA 实验，我们预计此项更改不会在 3PCD 之前生效。欢迎点击此处提供更多反馈。
主题观察	为发布商提供更精细的权限政策。	为发布商提供更精细的权限政策，可让发布商网站对 Topics API 对整个生态系统的实用性产生负面影响，而不会对 Topics API 对网站本身的实用性产生负面影响。如需更详细地讨论此主题，请参阅 Update permissions policy to support separate permissions for retrieve and observe GitHub 问题。
医疗和健康主题	为什么“主题”分类不涵盖“医疗”或“健康”类别中的主题？	医疗和健康类别被视为敏感主题，因此从“主题”分类中排除。
主题检索	一种更快的方式，让 DSP 无需使用标头提取即可获取主题。	与创建跨源 iframe 并通过该 iframe 进行 `document.browsingTopics()` 调用相比，标头方法的性能更高，费用更低。（必须使用跨源 iframe 进行调用，因为用于监控主题的顶级上下文必须与访问主题的上下文一致。）此处对此进行了详细讨论。
主题检索	请求支持在跨源脚本标记请求中通过标头传递 Topics。	从安全角度来看，这是不可能的。每个文档及其执行环境都与单个来源（即文档的来源）相关联。在同一环境中加载和执行的第三方子资源被视为归文档的来源所有。这是为了防止在未经用户同意的情况下，数据从一个来源泄露到另一个来源。另一种方法是在 `<script>` 标记上提供 `browsingTopics` 属性。从安全角度来看，这应该是干净的，并且不会增加额外的延迟时间。我们欢迎相关方提供反馈。
认知度	提高公众对 Topics API 及其用途的认知度。	我们已与提供此反馈的利益相关方联系，并在 GitHub 上解决了此问题。今后，我们将继续帮助生态系统了解该 API，并期待听取利益相关方的意见。与此同时，我们建议想要详细了解 Topics API 的利益相关方熟悉 Chrome 开发者指南中的文档。
通知	当网站在观察用户的“兴趣”时，系统会发出通知来提醒用户。	我们已在 GitHub 上回复此反馈。用户可以在 Chrome 帮助中心详细了解“主题”控件。
机器学习	如何使用机器学习推断用户的兴趣？	我们正在讨论此问题，欢迎您提供更多反馈。
对不同类型的利益相关方的实用性	由于浏览器计算 Topics 的方式，较小的广告技术公司可能无法观察到 Topics。	只有在过去三周内观察到用户访问了与主题相关的网页的广告技术平台才能接收此主题。如果广告技术平台在过去三周内未在与此主题有关的网站上针对相应用户调用该 API，则返回的值将为空。这项功能意味着，如果有更多网站所有者使用某个广告技术平台的服务，那么该平台就更有可能观察到给定用户的网站访问情况，因此可能会比其他广告技术平台获得更多主题。此功能对该 API 的隐私保护至关重要，因为它会将用户相关信息的提供范围限制为仅限已能够观察到相同基本信息（目前是通过第三方 Cookie）的各方。
XHR 请求	何时将弃用在 `XMLHttpRequest` (XHR) 请求中添加 Topics？	正如 Chrome 在 2023 年 8 月宣布的那样，在从源试用版过渡到正式版时，Chrome 开始弃用对 XHR 的支持。随着主题的逐步推广，XHR 支持仅适用于启用了 OT 功能的用户，在各个 OT 实验组合并后，XHR 支持已被完全弃用。如果您将 Topics 与 XHR 搭配使用，您的网站不会中断。只是不会将这些主题添加到您的 XHR 请求标头中。我们建议您为请求改用 `fetch`、使用 iframe 属性，或使用 JavaScript API 检索主题。所有新型浏览器都支持提取功能，但 Internet Explorer 或 Opera Mini 不支持。
分类法和分类器更新流程	详细了解“主题”分类法和分类器发布节奏，以及公司如何为此类更新做好准备。	我们的回复与第二季度保持不变：正如近期的博文中所述，我们预计该分类法会随着时间的推移而不断演变，并且最终会由代表整个行业利益相关方的外部方来管理。我们还在 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 SellerSignals`	`directFrom SellerSignals` 可让 Google Ad Manager 阻止发布商看到其内容相关竞价的价格。	Chrome 回复：除非卖方从自己的 iframe 调用 `runAdAuction()`，否则传入 `runAdAuction()` 的信息未知是否来自卖方。在多卖方竞价中，所有卖方都无法创建调用 `runAdAuction()` 的帧。`directFromSellerSignals` 通过从卖方的来源加载的子资源软件包加载内容来解决此问题。这样可以确保从卖方竞价配置传入竞价的信息的真实性和完整性无法被操纵。如果发布商希望使用 Protected Audience API 了解其技术提供商传入 Protected Audience 竞价的任何信息，可以向这些技术提供商申请使用此功能。 Google Ad Manager 提供的回复：我们多年来一直非常重视竞价公平性，包括承诺在其他买方在竞价中出价之前，不会与其分享发布商的任何无保证广告来源（包括无保证订单项价格）的价格。我们后来在向法国竞争管理局做出的承诺中重申了这一点。对于 Protected Audience 竞价，我们打算利用 `directFromSellerSignals` 来履行承诺，在多卖方竞价结束之前，不会与任何其他竞价参与方分享任何竞价参与方的出价。需要说明的是，我们也不会将内容相关广告竞价的价格与我们自己的组件竞价共享，如进一步阐明顶级竞价动态更新中所述。
信息泄露	浏览器可能会泄露敏感的业务逻辑和合同详细信息。	使用网络浏览器的用户可以看到浏览器中发生的所有事情。在浏览器中进行广告竞价时，浏览器的所有者确实可以观看竞价过程，包括查看不同方选择的出价金额。由于浏览器是用户的代理，因此我们认为无法或不应尝试更改这一点。不过，只有使用该浏览器的用户才能查看这些操作。任何服务器（包括 Google 服务器）都无法观察到使用 Protected Audience API 运行的设备端竞价。
`PerBuyerExperiment GroupId`	当前值范围 `PerBuyerExperiment GroupId` 允许买方将情境数据与可信服务器请求相关联。	以这种方式使用 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 通过以下几种方式更改其设计来处理此问题：将一些工作移至 DSP 的键值对服务器。 SSP 创建一些情境信号并将其提供给 DSP。为 DSP 缓存情境信号的 SSP。
发布商兴趣群体控制	为希望委托使用发布商创建的兴趣群组的发布商提供支持。	我们已就该要求与许多相关方进行了讨论。我们认为，现在可以满足所有涉及“委托”发布商创建的兴趣群体的用例，此外，我们还应提供额外的支持，以便将来某些用例的流程更加顺畅。
（也报告在第 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 竞价需求时避免向出价和竞价服务器发送请求。我们认为，这是一种有效的流量管理方式。
组件竞价	与组件卖方共享哪些顶级 auctionSignal？	组件竞价中的买方只能接收来自组件卖方的信号。我们很快就会分享有关将标头出价和 Protected Audience 竞价结合使用的整体流程的文档。
视频渲染	支持使用 Protected Audience 和 Fenced Frames 呈现视频。	Protected Audience API 支持使用依赖于 iframe 的机制呈现视频。不过，我们尚未设计出与围栏帧兼容的解决方案，这也是我们决定将围栏帧强制执行推迟到 2026 年的原因之一。也就是说，如果合作伙伴现在决定强制执行围栏帧，则该合作伙伴将无法获得视频支持。
频次上限	（也曾在前几个季度报告过）广告系列和广告组内的每位用户展示频次控制功能。	我们的回复与之前的报告保持不变： Protected Audience 还将支持设备端竞价以及内容相关广告系列和品牌广告系列的频次上限。共享存储空间和特定于网站的上限也可用于额外的频次上限控制。
广告偏好设置	Protected Audience 是否提供了按广告客户网站选择停用或列入屏蔽名单的方法，或者是否提供了退出同一所有者的所有兴趣群组的方法？	用户可以通过多种方式阻止访问 Protected Audience API 和其他 Privacy Sandbox 功能。
出价和竞价脚本来源网址的同源政策	放宽了以下要求：所有用于指定脚本或 JSON 加载网址的字段都必须与所有者的源相同。	我们目前正在考虑此请求，并欢迎生态系统提供更多反馈。
`forDebuggingOnly`	如果 `forDebuggingOnly .reportAdAuctionWin` 在 3PCD 后仍保留，则可能会被滥用。	过去几年，我们一直在收到生态系统关于在弃用第三方 Cookie 后 Protected Audience 功能缺口的反馈，我们正在努力制定一项计划，以便在弃用第三方 Cookie 后支持这些功能，同时不影响 Privacy Sandbox 的目标。我们欢迎您就生态系统希望看到的缺失功能提供任何其他建议和反馈。
多个兴趣群体	在同一出价中使用多个兴趣群体。	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 在可用于的广告资源类型方面没有固有的限制。
服务器到服务器集成	是否需要在 SSP 和 DSP 之间进行直接集成才能使用 Protected Audience？	如果 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 开发者工具的“网络”标签页中。	我们正在努力在“网络”标签页中启用此功能，并欢迎您提供更多反馈，说明为何应优先启用此功能。
可信执行环境	有关哪些指标会影响隐私保护（以及影响程度）的详细信息何时会添加到可信执行环境监控说明中？	我们正在更新该说明文档，以添加这些信息。更新后的说明文档将于 2023 年 11 月发布。
`directFrom SellerSignals`	为什么 `directFrom SellerSignals` 未打包为 Web 软件包？	我们已在此处说明了此决定的理由。
展示次数委托	是否有任何可行的方法来实现展示机会委托，即选择兴趣群体的结果是另一项定位操作？	出于以下两个原因，多重嵌套竞价与我们的隐私保护目标不相符。首先，当竞价胜出方在围栏框内呈现时，我们为 Protected Audience 设定的隐私保护目标包括：在不知道情境的情况下呈现最终的广告素材，即周围网页的网址或第一方 Cookie 会侵犯隐私。在这种环境中，嵌套竞价不可行。其次，Protected Audience 模型规定，每个竞价的胜出方都应仅基于一个额外网站的数据。嵌套竞价可以加深这种影响，从而有可能根据多网站配置文件选择广告。
静态数据标准	进一步说明键值对服务信任模型中的静态数据标准。	键值对服务中的数据会加载到内存中并从中提供，而不是执行任何直读缓存。
买方数据信号	从 DSP 收到的 `buyer_data` 信号是否有定义的大小限制？	目前，浏览器对从 DSP 收到的 `buyer_data` 信号没有任何限制。

衡量数字广告的效果

Attribution Reporting API（及其他 API）

反馈主题	摘要	Chrome 回复
跨设备	规划如何为 Attribution Reporting API 提供跨设备支持。	除了 3PC 之外，跨设备还会带来新的隐私保护挑战，并且鉴于用户可能会使用各种设备和平台，还会带来技术分发方面的挑战。我们正在探索潜在的解决方案，但目前将重点放在归因报告目前支持的重要用例上，并且没有计划在移除第三方 Cookie 之前推出跨设备支持。
（也报告在前几个季度）触发器数据大小	为什么触发器数据大小限制为 3 位？	大小限制为 3 位和 8 个不同的值，以确保用户的跨网站和跨情境信息量受到限制。我们欢迎生态系统参与者提交反馈，就当前事件级报告的参数化是否足够提出意见。
转化漏斗	报告转化中使用的多个网域。	由于添加了多个目的地，因此可以实现此用例。欢迎您提供更多反馈。
支持使用同一域名在不同国家/地区投放广告	归因报告是否适用于具有相同网域但具有多个国家/地区顶级域名的网站？	我们已与提出问题的利益相关方讨论并解决此问题。如果广告技术平台需要使用多个国家/地区顶级域名 (TLD)，则需要进行多次注册，每个国家/地区顶级域名对应一次注册。
Protected Audience 和归因报告	广告技术平台能否同时获取 Protected Audience 竞价的浏览型转化和归因报告的点击型转化？	是的，Privacy Sandbox 应同时支持 Protected Audience 中的 VTC 和 CTC。
可汇总报告延迟	进一步缩短可汇总报告的延迟时间。	我们最近收到了一些关于此问题的反馈，并在此处分享了一些想法。我们欢迎生态系统提供更多反馈。
可汇总报告延迟	通过引入服务器中介来减少延迟。	我们正在考虑此提案，欢迎您提供更多反馈。
事件级报告延迟	缩短事件级报告延迟时间。	灵活事件级配置中介绍的完整版灵活事件级方案可以将事件级报告延迟时间缩短到 1 小时，但会带来噪声方面的权衡。
每个来源的报告来源	每个来源报告网站的来源报告来源数量上限可防止广告技术平台为单个发布商来源注册来自不同报告来源的来源。	我们已与提出此问题的利益相关方进行了讨论，并在尝试涉及重定向的其他潜在解决方案之前，测试了“每个报告来源网站使用 1 个报告来源”这一潜在解决方案。我们也欢迎您就此限制提供任何其他生态系统反馈。
问题报告	如何向 Chrome 报告 Attribution Reporting API 的错误或问题？	目前，我们建议广告技术平台在 GitHub 上以问题的形式报告他们可能遇到的任何 Attribution Reporting API 错误。如果他们遇到与 Chrome 相关的问题，我们建议创建 Chromium bug。如需了解如何以及在何处举报任何问题，请参阅互动和分享反馈。
去重功能	如何跨不同渠道和设备去重转化？	跨设备和衡量流水线删除重复数据是广告技术平台目前在使用第三方 Cookie 时面临的一个已知问题。借助 Attribution Reporting API，广告技术平台可以决定何时注册特定转化，并添加特定元数据来指明他们使用了哪些衡量流水线来跟踪转化（换句话说，汇总键的一部分），以便与其他衡量流水线进行比较。我们欢迎您就此提供更多生态系统反馈。
去重和优先级	先请求优先级，然后再进行去重。	我们正在考虑此请求，欢迎您提供更多反馈。
欺诈防护	恶意用户篡改事件级数据的风险。	报告验证不适用于事件级报告，原因如为什么此功能不支持事件级报告？中所述。
转化类型	如何在归因报告中区分“观看”和“导航”？	我们提供了以下内置过滤选项：`source_type`。如需了解更多详情，请点击此处。

汇总服务

反馈主题	摘要	Chrome 回复
预算恢复	一些广告技术平台要求在报告出现失败、错误或被删除的情况下，能够重新处理报告。	该团队正在探索以可保护隐私的方式解决此问题的方法。
网站注册	多家广告技术平台已请求支持在同一账号中处理多个来源，以便按地理位置、广告客户等维度拆分数据等用例。鉴于客户端 API 注册现在是基于网站（而非来源），广告技术平台也预计会出现这种行为。从来源注册改为网站注册，可通过与客户端注册流程保持一致性来简化广告技术平台新手入门流程。	我们很快就会推出从来源注册到网站注册的汇总服务迁移，欢迎生态系统提供反馈。
发布和弃用计划	已发布的汇总服务功能和补丁的发布和弃用时间表。该计划的目标是让广告技术平台了解我们的发布政策，以便他们为即将发布的版本和弃用版本做好准备，并确保他们运行的是稳定且安全的服务版本。	我们最近发布了一份汇总服务发布和弃用计划的提案，欢迎您提供更多反馈。
协调者	如果汇总服务的协调者发生故障，会发生什么情况？	这两个协调者都需要处于完全可用状态，系统才能正常运行。客户端库中的重试功能可应对短暂的不可用情况；如果这两个协调者的任何一个不可用时间较长，汇总作业将会失败。如果隐私权预算尚未用尽，则可以重新运行作业。如果任何服务故障导致预算消耗，但未将摘要报告写入广告技术平台存储空间，我们目前建议他们使用本地测试工具通过调试报告检索结果。我们还在开发一些功能，以便在作业失败时恢复预算，以便广告技术平台能够重新运行作业。

Private Aggregation API

反馈主题	摘要	Chrome 回复
Blob 网址	请求支持在共享存储空间中使用 Blob 网址。	Chrome M116 中新增了对 Blob 网址的支持。

限制隐蔽跟踪

用户代理缩减和用户代理客户端提示

反馈主题	摘要	Chrome 回复
JavaScript API	推出了 User-Agent Client Hints JavaScript API。	我们没有移除此功能的计划，因为它是我们为希望主动访问冻结的 UA 和缩减后的 UA 中默认提供的数据之外的高熵数据的合作伙伴提供的核心解决方案。
设备和外形规格信息	网站能够了解访问该网站的设备支持的输入、输出和其他信息。	我们已根据生态系统的反馈添加了对此请求的支持。

IP 保护（以前称为 Gnatcatcher）

反馈主题	摘要	Chrome 回复
符合条件的第三方流量	说明中“符合条件的第三方流量”是指什么？	我们深知这个问题的重要性，并正在积极确定哪些第三方流量符合条件，哪些不符合条件。欢迎就此主题提供反馈。
网络流量审核	支持企业为其网络执行网络流量审核。	只有嵌入在第一方网站中的第三方流量会受到影响，这应该会限制需要过滤的流量量。此外，我们计划让用户选择是否使用 IP 地址保护功能，对于由企业控制的 Chrome，将有企业政策可用于停用 IP 地址保护功能。最后，我们正在研究将为网络运营商提供哪些控件（如果有）来停用 IP 地址保护功能。我们欢迎您就此主题提供反馈。
访问权限控制	IP 保护功能可能会影响使用 IP 地址进行访问控制的 Web 服务。	我们理解防欺诈用例的重要性，以及对这些用例的可能影响。我们希望生态系统提供反馈，以便我们更好地支持通常依赖于 IP 地址的防欺诈用例。
2 跳代理之间的通信	如何确保代理之间没有信息。	我们正在设计代理互动。我们的目标是通过业务、流程和技术手段，尽可能降低此类信息共享的可能性。
非 Google 身份验证	支持非 Google 身份验证。	我们计划日后发布有关账号身份验证的更多详细信息，不过我们已分享了一些初步注意事项。
追踪器分类	IP 保护功能如何确定什么构成跟踪器及其变体？	我们深知这个问题的重要性，并正在积极确定哪些第三方流量符合条件，哪些不符合条件。欢迎就此主题提供反馈。
分析	IP 保护功能可能会影响分析服务的准确性。	我们希望进一步了解知识产权保护功能的影响，欢迎生态系统提供更多反馈和示例。
代理	如果用户使用的是代理或手动定义了代理，在这种情况下 IP 掩码会如何运作？	我们希望了解 IP 保护功能对其他代理服务的影响。目前，我们没有任何计划可以分享。欢迎就此主题提供反馈。
付费内容	IP 地址保护功能是否为付费功能？	IP 保护功能将作为核心浏览器体验的一部分面向 Chrome 用户提供。这项功能不会收费。
代理服务器	用户会话期间是否会使用相同的代理服务器？	HTTP/S 连接将使用一对代理，并向源显示一个经过掩码的 IP 地址。此外，不同 HTTP/S 连接没有硬性限制，可以使用不同的服务器。
平台支持	知识产权保护功能将在哪些平台上受支持？	IP 保护功能最初将在 Chrome（Android 版）和 Chrome（桌面版）上推出。我们会继续评估如何将此保护措施扩展到其他平台。
选择停用	用户能否停用 IP 地址保护功能？	我们计划让用户选择是否要使用 IP 保护功能。
匿名化	在知识产权保护功能下，哪些类型的请求会被匿名化？	系统会通过隐私代理对发送到符合条件的第三方网域的 HTTP/S 和 DNS 请求进行匿名化处理。我们将在即将发布的说明中详细介绍我们如何确定要包含哪些网域。其余流量（例如其余 DNS 请求或其他 HTTP/S 流量）不受影响。
数据可见性	在 IP 保护的第一个跃点期间，系统可能会访问网络地址。	在两跳代理模型中，第一跳（由 Google 控制）仅会看到来源客户端 IP 和连接到第二跳的请求，而第二跳（由外部 CDN 控制）仅会看到第一跳上的元组（代理 IP + 端口）和目的 IP。对于从源返回的响应，第二跳可以将响应转发到与请求关联的第一跳代理+端口，而无需了解原始客户端 IP 的任何信息（第一跳只会将响应返回给客户端，而无需了解目标 IP 的任何信息）。这样，第一个跃点只会学习客户端 IP 和第二个跃点，而第二个跃点只会学习目的地 IP。
WebView	IP 保护功能未来是否会面向 Android WebView 提供？	我们目前没有任何计划可以分享，但我们的愿景是尽可能广泛地提供此保护。

跳出跟踪缓解措施

反馈主题	摘要	Chrome 回复
互动跟踪	如何跟踪用户互动？	跳出跟踪缓解措施会跟踪两种类型的用户互动：用户激活，如 HTML 规范中所定义。这些基本上是点击、按键、触摸屏点按等。成功的 webauth 断言。这些是指用户点按安全密钥或使用通行密钥作为身份验证方式的情况这些互动与发生互动的网页上的顶级网站相关联。例如，如果用户在嵌入的 iframe 中点击，相应互动会与顶级网站相关联，而非嵌入的网站。互动会存储在一个数据库中，其中包含无架构 etld+1 和互动时间。互动会在 45 天内保护关联的网域免遭跳出率跟踪缓解措施状态删除。
已列入许可名单的豁免	域名可以豁免吗？	我们正在考虑此请求，并欢迎生态系统提供更多反馈。

隐私预算

本季度未收到任何反馈。

增强跨网站隐私边界

Related Website Set（以前称为 First-Party Set）

反馈主题	摘要	Chrome 回复
集中式方法	对使用集中式代码库管理相关网站集的方式存有疑虑。	一个易于访问的公共代码库是 RWS 设计的关键，因为它可确保提交内容的责任。第三方 Cookie 功能最终是通过使用 Storage Access API 或 rSAFor API 提供的，RWS 会员资格可提供自动授予的访问权限（而非通过 Storage Access API 的提示）。我们认为，对于自动授予的第三方 Cookie 访问权限，RWS 提交流程等方法是一项适当的要求。
重命名 JSON 文件	随着 API 名称的更改，托管的 JSON 文件名称是否需要更改？	是的，提交指南已发生变化，主网域必须在 `/.well-known/related-website-set.json` 上提供 JSON 文件。 RWS 列表中的现有集合无需更改，但如果有针对现有集合提交的修改，则必须更改 JSON 文件。
（也报告在前几个季度）网域限制	请求扩大关联域名数量	正如 8 月 31 日的博文中所宣布的那样，我们已根据生态系统的反馈，将关联的网域数量上限提高到 5 个网域。我们决定将关联的网域数量上限提高到 5 个网域（外加一个主网域），这与另一款主要浏览器提供的最具可比性的实现最为相符。
第三方 Cookie	关闭第三方 Cookie 后，Related Website Set 是否无法正常运行？	即使用户未屏蔽第三方 Cookie，相关网站集也能正常运行；但由于相关 Cookie 可用，无需使用相关网站集和 Storage Access API，因此不会产生任何明显影响。
合法修改	相关网站集代码库如何防止非所有者修改集？	根据提交指南，任何人都可以在 GitHub 上提交 PR 来修改 `first_party_sets.JSON` 文件。不过，如果 PR 获得批准（通过技术验证等），Google 会每周手动将其批量合并到规范 FPS 列表中一次（美国东部时间周二中午 12 点）。如果恶意行为者尝试修改不归其所有的集合，则不应构成问题，因为他们无法修改 `.well-known` 文件，因此验证将会失败。
域名盗用	域名盗用可能会将相关域名数据泄露给未经授权的各方。	这不可能，如此 Protected Audience GitHub 问题中所述。

Fenced Frames API

反馈主题	摘要	Chrome 回复
内容违规	允许用户举报可疑广告。	围栏框不会阻止系统举报可疑广告。用户仍可按照常规方式与广告互动，并向广告技术平台举报可疑广告。
与周围网站互动	允许与周围或顶级网站互动。	我们希望了解为何需要此请求，并欢迎生态系统提供更多反馈。
原生广告	对原生广告的围栏帧支持。	我们正在考虑支持该用例，并讨论可能的权宜解决方法和解决方案。

Shared Storage API

反馈主题	摘要	Chrome 回复
跨网域	允许跨网域通信以实现本地存储。	此用例目前不符合 Shared Storage 的可保护隐私的输出门限，但我们欢迎提供更多背景信息，以便我们改进对非分区存储的提案。
Blob 网址	请求支持在共享存储空间中使用 Blob 网址。	Chrome M116 中新增了对 Blob 网址的支持。

CHIPs