Web 隐私沙箱：不断变化的隐私格局及其对您网站的影响

Chrome 将在整个 2023 年通过隐私沙盒计划对隐私进行更改，同时构建新技术来保护用户信息的私密性。 同时，网络出版商和品牌正在改变他们的数字战略，以帮助保持依赖第三方 cookie 的广告收入和有价值的营销分析。

这种对扩展浏览器隐私的推动推动了对网站个性化的更多需求。

在本次会议中，Google 开发者倡导者 Sam Dutton 介绍了即将发生的变化，分享了隐私沙盒计划的目标，并帮助您更好地了解如何进行调整以确保您拥有所需的数据来帮助您的业务和网站保持稳定向前进。

会议幻灯片：

成绩单：

山姆·达顿：大家好，我是山姆·达顿。 我是伦敦 Chrome 团队的一名开发者倡导者。 非常感谢你今天加入我。 在接下来的 25 分钟内我会做三件事。 我将为您概述隐私沙盒 API。 我将解释您现在需要做什么，并向您展示如何成为一名测试人员并加入 API 的讨论并提供反馈。

因此，让我首先解释为什么我们需要隐私沙盒。 你们中的许多人都非常了解背后的故事，但值得快速重申一下我们为什么需要这个以及我们是如何走到今天这一步的。 因此，Privacy Sandbox 是一项旨在帮助构建一组隐私保护 API 的计划，以支持为未来的开放网络提供资金的商业模式，而无需第三方 cookie 等跟踪机制。

现在您可能已经在 Google I/O 上看到了这个示例。 这是一个典型的站点，包含来自不同来源的组件。 当然，可组合性是网络的超能力之一。 你有一张来自一个来源的地图，一些来自另一个来源的脚本，等等，当然还有广告，不管我们喜欢与否，无论未来如何，广告已经成为收入的重要来源和商业的驱动力网。

现在在历史的这一点上，我认为浏览器和 CMS 需要支持广告用例。 所以有什么问题？ 好吧，广告选择、转化测量、欺诈检测、设备定制以及许多其他用例都依赖于跨站点身份，使用的机制在构建时并未考虑隐私。

现在，不仅是第三方 cookie，指纹识别也用于跨站点跟踪用户行为，或者站点请求个人信息，例如电子邮件地址，此外，第三方生态系统非常复杂，尤其是对于广告。 甚至开发商、广告商或出版商也不了解第三方服务的供应链。

所以当然，当我访问一个网站时，我并不知道所有相关的第三方以及他们对我的数据做了什么，而不仅仅是我，研究表明人们真的很关心控制他们的数据。 隐私问题越来越多地推动人们选择在线做什么，世界各地的监管机构都在加强隐私要求，而且这种情况发生得非常快。

因此，考虑到有多少企业依赖有效的在线广告，有多少出版商依赖广告来通过他们的网站获利，以及一大堆其他用例，这对整个网络生态系统来说都是一个问题，而不仅仅是科技公司和广告平台。 但当然，因为网络是一个开放平台，所以改变建议需要接受和反馈，Chrome 等浏览器不能也不想单方面行动。

浏览器不是浏览器供应商可以孤立地做出决定的产品，现实情况是，网络并不是为当今平台的许多核心要求而设计的，这些要求包括广告欺诈检测、身份管理和所有这些其他要求用例和很快。 因此，我们需要的是为这个以隐私为中心的网络专门构建的技术，这就是隐私沙盒的用武之地。

因此，Chrome 一直与网络社区以及行业利益相关者和监管机构合作，开发新的隐私保护技术，以支持健康、可持续的生态系统。 现在，一旦这些新的专用 API 可用，我们需要确保公司有时间采用它们，以便我们可以安全地逐步停止 Chrome 中对第三方 cookie 的支持，并继续我们的工作以减轻其他类型的跟踪。

现在，该计划的核心原则集是网络的潜在隐私模型，由 Google 的隐私专家和计算机科学家开发。 这种隐私模型为设计技术制定了一套基本规则，这些技术可以满足我谈到的网络平台用例，同时也遵守我们不断变化的隐私需求。

特别是，该提案涵盖了如何在不损害隐私的情况下启用跨站点连接的难题。 现在，Privacy Sandbox API 的主要创新之一是使浏览器能够代表用户行事，从某种意义上说，回到浏览器的核心角色，即我们所说的用户代理。

使用当前技术，数据由第三方收集、汇总和共享，以跟踪用户跨站点浏览。 隐私沙盒 API 可以允许广告拍卖转换测量和这些其他任务由用户设备上的用户浏览器完成。

因此，我们需要通过跨浏览器供应商、平台、广告商、出版商广告技术、用户、监管机构和隐私社区的协作来重建广告平台和网络，尤其是像您这样使用 CMS 平台的开发人员。

因此，考虑到所有这些，我只想让您快速浏览一下 Privacy Sandbox API 本身。 所以在谷歌，这是一个跨网络和 Android 的共享计划。 Android 上的隐私沙盒专注于引入新的更私密的广告解决方案，无需跨应用标识符。

当然，Web 和 Android 共享相同的原则，并且正在为 Android 开发一些 Web 提案。 然而，Web 和 Android 移动平台当然依赖于根本不同的技术。

所以这是在 Android 上的一项独特举措，但对于那些构建 Android 应用程序以及在 Web 上工作的人来说，这是一个需要密切关注的举措。 因此，谷歌一直在与全球范围内的合作伙伴合作测试新的 API。

数百家公司参与公共论坛，无论是 W3C，还是在 GitHub 等上解释问题，发表观点和分析，加入行业圆桌会议，与 Chrome 和 Android 分享反馈，当然，还参与测试。

别搞错了，Privacy Sandbox 有很多要求要满足，而且一路走来会很艰难。 我的意思是，我认为好消息是，所有这一切的结束将拥有对用户来说更安全、更私密的平台，对广告商、出版商、开发商，当然还有像 WordPress 这样的平台来说更好。

所以我不打算描述所有的隐私沙盒 API。 相反，我想专注于隐私沙盒中的三个主要广告 API。 这就是主题、FLEDGE 和归因报告。 我们的主题和 FLEDGE 被称为相关 API。

Now Topics 根据用户最近的浏览历史记录提供用户兴趣的高级信号。 主题可以结合上下文信号和第一方数据来选择相关广告。

FLEDGE 支持更精细的再营销和自定义受众用例，在这些用例中，营销人员希望接触到对特定网站或产品表现出兴趣的受众，但当然，要以保护隐私的方式实现这一点。

最后，归因报告是 Chrome 为保护隐私的活动衡量提出的建议，提供匿名的性能报告以及人们何时查看或点击广告，然后继续完成购买或其他类型的转化。

因此，这些 API 已经在 Android 和桌面和移动设备上的 Chrome 中进行了一段时间的测试。 如果您正在使用广告技术平台，则需要确保您了解这些平台解决这些用例的计划，以及这些 API 在未来没有第三方 cookie 或其他跟踪机制的情况下满足的用例。

因此，现在我们已经对使用 Chrome 标志激活的 API 进行了一段时间的技术测试，现在最初只为一小部分 Chrome 用户激活了原始试用版。 所以现在我们处于实用程序测试阶段，50% 的 Chrome Canary 开发和测试版用户在提供有效令牌的页面上激活了广告来源试用 API，5% 的稳定用户。

现在，这当然只占 Chrome 总流量的一小部分，但足以让真实用户对 API 进行有限测试。 我们现在正朝着在 Chrome 稳定版中发布的方向迈进，默认情况下所有用户都可以使用 API，稍后我会回到时间表。

因此，重申一下，对于单个用户，您可以使用 Chrome 标志激活 API，但要进行大规模测试，您需要参加 Privacy Sandbox 原始试用，稍后我将分享链接以获取有关如何完成所有操作的指导.

因此，顺便说一下，Chrome 也在更新用户隐私控件，例如 UI 并且隐私沙盒控件实际上作为广告 API 原始试用版的一部分提供。 人们将能够查看和管理与其浏览相关的兴趣或完全关闭 API。

所以实际上还有其他三种隐私沙盒技术，我认为您可能还想测试或肯定要标记给您的任何第三方提供商。 首先，筹码。 这就是具有独立分区状态的 Cookie 允许开发人员选择一个 cookie 来分区存储，每个顶级站点都有一个单独的 cookie jar。

第一方集允许由同一实体拥有和运营的相关域名声明自己属于同一第一方和私有状态令牌。 您可能听说过这个初始名称，即 Trust Tokens。 这是一个 API，用于将有限数量的信息从一个浏览上下文传递到另一个浏览上下文，例如，跨站点帮助打击欺诈，但不使用被动跟踪技术。

所以首先，让我们更深入地了解主题 API。 主题 API 提供了一种机制来启用基于兴趣的广告，但不允许第三方跟踪用户浏览活动。 因此，从某种意义上说，API 具有三个主要组成部分，首先，基于兴趣的广告需要对感兴趣的主题进行分类。

Topics API 分类法如下所示。 这是一个公开维护的人类可读主题列表，避免了敏感主题。 现在，随着与网络生态系统的协商，这可能会随着时间的推移而改变和发展，这意味着像您这样的人，我们需要您对此以及其他一切的反馈。

因此，Topics API 需要根据用户的浏览活动来推断他们的兴趣，但正如我所说，这样做是为了保护他们的隐私。 因此，用户设备上的浏览器再次根据他们最近的浏览活动，为用户在他们设备上的浏览器中记录最感兴趣的主题。

目前，主题通过使用机器学习将用户访问的页面主机名映射到分类法中的主题来实现这一点。 现在与主题分类法本身一样，该方法将随着时间的推移而发展。 但是从浏览活动中推断兴趣需要取得正确的平衡。

如果您有太多关于用户浏览情况的详细信息，这对隐私不利，但粒度太少意味着 API 没有用。 我认为从某种意义上说，这里要理解的主要事情是感兴趣的主题只是找到与用户相关的内容的一个信号。

因此，一旦浏览器为用户推断出感兴趣的主题，主题就需要为 API 调用者提供访问他们为用户观察到的感兴趣主题的权限。

因此，当用户浏览网页时，API 有两个阶段。 API 调用者（例如，可能是广告技术平台）调用页面上的 API 以表示他们想要观察当前页面和当前用户的主题。

现在，API 调用者可以访问他们为用户观察到的主题。 现在，所有这一切都必须在不透露更多关于用户浏览活动的信息的情况下完成，除了所观察到的感兴趣的主题之外。

因此，主题 API 提供了两种方法来观察用户感兴趣的主题，然后访问观察到的那些主题，首先是使用 JavaScript API 或使用获取请求中的请求和响应标头。

Topics API 调用者可以向浏览器发出它已观察到用户主题的信号的第一种方法是从嵌入在用户访问的站点上的 iframe 调用 document.browsingTopics。

现在，稍后 API 调用者可以调用相同的 document.browsingTopics 方法来访问它为当前用户观察到的主题。 顺便说一下，此方法需要 iframe 的原因是观察主题的上下文必须与访问主题的上下文相同。

另一种观察和访问主题的方法是使用获取、请求和响应标头。 首先，API 调用者需要向其来源的 URL 发出获取请求，包括选项参数中的浏览主题 true 对象。

如果对获取请求的响应包含一个 Observe-Browsing-Topics ?1 标头，那么，这会向浏览器发出信号，表明调用者希望浏览器记录调用者已经为当前用户观察了当前用户感兴趣的主题页。 我希望这是有道理的。

现在，可以通过访问 sec-browsing-topics 请求标头从调用者的提取请求中检索用户观察到的主题。 所以这是从开始到结束的整个过程。 我知道时间问题，所以我现在不会详细介绍，但我们稍后会分享它，这样您就可以看到它是如何工作的，整个过程，我们将为每个 API 提供它。

您可以试用使用 JavaScript iframe 方法观察和访问主题的主题演示，或者您可以试用我们使用获取请求标头方法的演示。 chrome://topics-internals 显示当前用户的主题、为主机名授予的主题和有关 API 实现的技术信息。

您还可以运行主题合作实验室，以使用主题分类器模型测试主题推理。 在我离开主题之前，现在有三个主要的未解决问题，我们如何才能根据用户的浏览活动更好地推断他们感兴趣的主题？ 我们如何改进分类法的内容和结构，使其在保护用户隐私的同时更有用？ 我们如何改进 API 的整体架构？

我认为这里要记住的一件事是我们是否有主题或不同的东西，我们仍然需要满足它的用例。 接下来，FLEDGE。 因此，这是一个用于设备广告选项的 API，无需跨站点第三方跟踪即可服务于再营销和自定义受众用例。

我认为 FLEDGE 的代码细节稍微多一点，因为它比主题更复杂。 因此，FLEDGE 过程分为三个部分。 首先，广告购买者将用户或个人浏览器真正添加到所谓的兴趣组中。 这些类似于自定义受众，但兴趣组成员身份存储在用户设备的浏览器中。

现在，当用户访问显示广告的网站（例如发布商网站）时，广告销售商可以发起广告拍卖来为他们选择广告，而借助 FLEDGE，该拍卖可以在用户的​​设备上运行。

为了选择广告，拍卖代码运行来自买家的出价逻辑和来自卖家的拍卖逻辑。 最后，浏览器会向买卖双方提供的端点发布拍卖报告。

所以我只是非常简要地逐步介绍 FLEDGE。 首先想象一个用户访问在线鞋店，进行一些浏览。 广告技术平台或广告商自己进行 JavaScript 调用以告知浏览器加入兴趣小组。 这个组的名称可能类似于 Trail Running Shoes。

兴趣小组的配置对象可能如下所示。 在此示例中，鞋店的广告技术人员可能有一个兴趣小组用于再营销，他们希望将用户添加到该小组，并且他们将这个小组很好地称为 Trail Running Shoes。 鞋店的广告技术平台调用加入广告兴趣组，要求用户的浏览器使用我刚刚向您展示的配置加入他们的 Trail Running Shoes 兴趣组。

第二个参数指定兴趣组的持续时间，上限为 30 天。 现在用户访问了一个发布广告的网站。 在这个例子中，一个新闻网站。 选择要向用户显示的广告的拍卖由卖家使用运行广告拍卖在用户设备上以 JavaScript 运行，卖家可能是广告技术平台，但也可能是发布商本身，在本例中是新闻网站。

现在，此拍卖为用户浏览器所属的每个兴趣组以及来自卖家和浏览器本身的其他因素选择最合适的广告给定出价。

现在查看代码，发布商或在发布商网站上销售广告空间的平台为广告拍卖创建配置数据。 然后卖家要求浏览器运行广告拍卖以在浏览器中选择一个广告，运行广告拍卖返回的值被传递到一个称为围栏的元素，这样网站就可以展示获胜的广告。

现在，围栏框架可用于显示广告，但无法与其周围的页面进行交互。 然后卖家和获胜的买家每个人都有机会执行日志记录和报告，这是通过调用 navigator.reportresult 完成的。

最后，如果一切顺利，用户点击或点击广告，现在归因报告 API 将接管。 同样，我们有一张图表显示了从开始到结束的整个过程，我们将在主题演讲后与您分享。

现在，最后我想向您介绍一下用于广告衡量的 Privacy Sandbox API，即归因报告。 归因报告用于衡量广告点击或广告展示何时带来了转化。 例如，当浏览新闻网站上的广告导致在在线鞋店购买商品时。

现在与主题和 FLEDGE 一样，此 API 旨在避免跨站点跟踪。 因此 API 允许两种类型的测量结果，事件级别报告和摘要报告。 那么让我简要描述一下它是如何工作的。

首先让我们看一下事件级别的报告。 因此，可以使用特定于归因报告 API 的属性来配置广告链接，这样就可以在转换端通过请求来统计观看次数和点击次数。

现在，当用户点击广告或看到广告然后进行转换时，浏览器会生成一份报告，广告公司或广告技术人员在该报告中包含两条数据。 第一，他们想要的有关广告点击或展示的任何数据，这些数据可以非常详细，例如创意 ID、有关发布者的信息、时间戳等。 其次，关于广告转化的一小部分数据。

现在，为了保护用户隐私，这个不能太详细。 稍后浏览器会发送关于——好吧，该报告包含我刚刚向广告技术人员或广告商解释的数据，其中包括延迟以帮助避免用户跟踪。

该报告包含两部分数据，有关广告点击或展示的详细数据、事件和有关转化的高级数据。 所以这是一个事件级别的报告。 现在让我们看一下摘要报告。

现在生成摘要报告的浏览器 API 类似，但结果和机制略有不同。 同样，当用户点击广告或看到广告然后进行转换时，浏览器会生成报告，广告公司或广告技术人员可以在该报告中包含他们想要的有关广告点击或展示的任何数据以及他们想要的任何数据想要了解广告转换，但此报告已加密。

这是一种隐私保护，因为此报告包含有关转换和印象的详细数据。 因此，如果报告未加密，则可用于跨站点跟踪。 稍后，浏览器将再次发送此加密报告，但会有一小段延迟。

通过这种方式，广告技术平台将从许多用户那里收集许多报告，然后将所有报告发送到一个被调用的聚合服务，该服务将聚合所有这些报告，解密它们，添加一些噪音以保护用户隐私，然后返回最终结果，最终结果称为总结报告。 它包含许多用户的测量数据。

这就是归因测量。 我希望这是有道理的。 我将链接到更多资源，以帮助您更详细地了解和测试 Privacy Sandbox API。 但我想提及的最后一件事是 Privacy Sandcastle。

这是一个结合了所有主要 Privacy Sandbox API 的演示。 它是由我们在东京的团队建造的。 它仍然很新。 但您可以从 GitHub 获取代码并在本地运行它，它旨在帮助您了解所有这些 API 如何组合在一起。

在结束之前，我想回顾一下 Privacy Sandbox 的时间表。 如您所见，我们即将开始交付 API 的季度即将到来，这意味着它们将默认在 Chrome 稳定版中可用，并准备好在生产规模上进行测试。 现在这只是日历上很短的时间，我可以看到自己。 我快到时间了。

所以我认为你现在需要做的一些事情。 首先，了解 Web 和 Android 的时间表。 确保您和您的第三方提供商已为即将发生的变化做好准备。 其次，审核您的网站以了解它们在哪里依赖第三方 cookie 和其他已弃用的机制。 我们将在今天的活动结束后分享工具链接和操作说明。

接下来，询问您的第三方提供商，例如广告技术平台等，在没有第三方 cookie 或其他跨站点跟踪机制的情况下，他们如何准备满足其核心用例，最后，测试 Privacy Sandbox API 并提供反馈并要求您的第三方供应商也这样做。

如果他们不舒服，请问他们为什么不好，然后让我们知道该问题的答案是什么。 因此 privacysandbox.com 提供时间表、常见问题解答以及有关跨平台工作的更多信息。 我将在此次活动后分享 URL，但您可以从 developer.chrome.com 的隐私沙盒部分找到我在这里提到的很多内容。

特别是，这里有解释如何为我们提问和提供反馈的资源，您可以在 developer.chrome.com 上找到有关原始试用的更多信息。 我们还创建了一系列短视频和文章来帮助解释 Chrome 概念，例如原始试用、Chrome 标志、闪烁内容等。

所以谢谢你的聆听。 我就是这样。 就像我说的，如果您确实需要支持，请访问这些资源，或者您可以在 Twitter 上直接给我 SW12 发消息。 非常感谢。