第三方

什么是第三方？

完全独立的网站很少见。《HTTP 网络年鉴》显示大多数网站（约 95%）包含一些第三方内容。

年历将第三方内容定义为托管在某个共享公开来源上的内容，此类内容广泛用于各种网站，不受单个网站所有者的影响。这些元素可能是图片或其他媒体，例如视频、字体或脚本。 图片和脚本所涵盖的内容比其他这些内容更重要。第三方内容对于网站开发并不是必不可少的，但也可能是必不可少的；您几乎肯定会使用从公共共享服务器加载的内容，无论是网页字体、视频的嵌入式 iframe、广告还是 JavaScript 库。例如，您可能使用 Google Fonts 提供的网页字体，或使用 Google Analytics（分析）衡量分析数据；您可能添加了社交网络中的“赞”按钮或“登录”按钮；您可能嵌入了地图或视频或通过第三方服务处理了购物；您可能正在通过第三方监控工具为自己的开发团队跟踪错误和日志记录。

出于隐私保护方面的考虑，建议采用略微不同且更为宽泛的定义：第三方资源（尤其是第三方脚本）由共享的公开来源提供，并广泛使用（如图所示），但同时也是由网站所有者以外的其他人撰写。在考虑如何保护用户的隐私免遭他人盗用时，第三方作者身份这一个方面至关重要。这将引导您考虑存在哪些风险，然后根据这些风险决定如何或是否使用第三方资源。如前所述，这些内容有助于您了解背景，进而了解需要做出哪些权衡，以及这些取舍的含义。

一般来说，在讨论“第三方资源”时，这里的含义并不明确：第一方和第三方之间的区别在于其使用情境。从其他网站加载的脚本属于第三方资源，用于加载脚本的 HTTP 请求可能包含 Cookie，但这些 Cookie 实际上并不是“第三方 Cookie”；它们只是 Cookie。它们是“第三方”还是“第一方”取决于该脚本是加载在您网站的某个网页上还是在脚本所有者的网站上。

我们为什么使用第三方资源？

通过第三方，您可以非常方便地向网站添加功能。这些可能是向用户公开的功能，也可能是不可见的开发者功能（如错误跟踪），但它们会减少您的开发负载，并且脚本本身由其他人（即您所包含服务的开发团队）维护。这一切都得益于网络的可组合性：能够将多个部分组合在一起，形成一个大于它们总和的整体。

HTTP 归档的网络年历中给出了很好的说明：

第三方会源源不断地提供图片、视频、字体、工具、库、微件、跟踪器、广告以及您可以想象到的嵌入我们网页的任何其他内容。这样一来，即使是最非技术人员也能创作内容并发布到网络上。如果没有第三方，网络可能是非常单调乏味、以文字为主的学术媒介，而不再是丰富、沉浸式、复杂的平台，已经成为我们许多人日常生活不可或缺的一部分。

第三方资源有哪些用途？

访问某些信息

当您在网站上使用第三方资源时，不管是什么内容，系统都会向该第三方传递一些信息。 例如，如果您包含来自其他网站的图片，用户浏览器发出的 HTTP 请求将传递引荐来源网址标头，其中包含您的页面网址以及用户的 IP 地址。

跨网站跟踪

继续以同一个示例为例，当图片从第三方网站加载时，它会包含 Cookie，当用户下次请求该图片时，系统会将该 Cookie 发送回第三方。这意味着第三方可以知道您的网站正被使用他们的服务，并且可以发回 Cookie，其中可能会包含该用户的唯一 ID。这意味着，当用户下次访问您的网站或包含该第三方的资源的任何其他网站时，系统会再次发送该唯一 ID Cookie。这样，第三方就可以针对用户的访问位置建立日志：您的网站、使用同一第三方资源的其他网站，以及整个网络。

这就是跨网站跟踪：允许第三方收集用户在许多网站上的活动日志，前提是这些网站都使用来自同一第三方的资源。资源可能是字体、图片或样式表，其中全部都是静态资源。也可能是动态资源：一段脚本、一个社交媒体按钮、一则广告。所包含的脚本可以收集更多信息，因为它是动态的：它可以检查用户的浏览器和环境，并将该数据传回其发起者。任何脚本在一定程度上都可以做到这一点，没有以脚本形式呈现的动态资源（例如社交媒体嵌入内容、广告或分享按钮）也可以做到。如果您查看热门网站上的 Cookie 横幅的详细信息，就会看到一个组织列表，这些组织可能会向您的用户添加跟踪 Cookie，以生成其活动图片，从而创建该用户的个人资料。可能会有数百条记录。如果第三方免费提供服务，那么对于他们而言，经济可行的方法是收集这些数据，然后利用这些数据创收。

目标隐私威胁模型是浏览器应保护其用户的隐私权问题类型，一份实用指南。 在撰写本文时，这份文档仍在讨论中，但它对存在的各种隐私威胁进行了一些简要分类。第三方资源带来的风险主要包括“不必要的跨网站识别”（一个网站可以在多个网站上识别同一用户）和“敏感信息披露”（即网站可能会收集用户认为敏感的信息）。

二者间有一项关键区别：即使第三方没有从网站收集额外的敏感信息，不必要的跨网站识别也可能会带来不良影响，因为这会剥夺用户对其身份的控制权。获取用户的引荐来源网址、IP 地址和 Cookie 本身就是不必要的披露。使用第三方资源时，系统会一并说明您将如何以可保护隐私的方式使用这些资源。其中一部分工作由您作为网站开发者负责，另一些则由浏览器作为用户代理完成；也就是说，代理代表用户执行操作，尽可能避免敏感信息泄露和不必要的跨网站识别。下面，我们将详细介绍浏览器级别和网站开发级别的缓解措施和方法。

服务器端第三方代码

我们之前对“第三方”的定义特意改变了 HTTP 年历的客户端方法（与其报告相符！）以包含第三方作者信息，因为从隐私保护的角度来看，第三方是指对您的用户有所了解的任何人，而不是您。

这包括提供您在服务器上使用的服务的第三方，也包括客户端。从隐私保护的角度来看，了解第三方库（例如 NPM、Composer 或 NuGet 中包含的库）也很重要。您的依赖项是否将数据传递到边界之外？如果要将数据传递到日志记录服务或远程托管数据库，而如果库还向其作者添加了“phone home”，那么这些库可能会侵犯用户隐私，因此需要对其进行审核。基于服务器的第三方通常必须由您传递用户数据，这意味着您可更好地掌控向其公开的数据。相比之下，基于客户端的第三方（网站上包含并由用户浏览器提取的脚本或 HTTP 资源）可以直接向用户收集某些数据，收集过程不由您中介。本单元主要探讨如何识别您选择包含和向用户展示的客户端第三方，而这正是由于您可以采用的中介方式较少的缘故。但有必要考虑保护服务器端代码，以便您了解来自它的出站通信，并可以记录或阻止任何意外的通信。关于如何实现这一点的详细信息不在我们的讨论范围之内（并且很大程度上取决于您的服务器设置），但这是您的安全和隐私立场的另一个方面。

为什么要谨慎对待第三方？

第三方脚本和功能非常重要，而我们作为 Web 开发者的目标应该是集成此类功能，而不是放弃它们！但也有潜在问题。第三方内容可能会导致性能问题，还可能产生安全问题，因为您将外部服务引入信任边界内。但第三方内容也会导致隐私问题！

在我们谈论网络上的第三方资源时，不妨将安全性问题视为第三方可以从贵公司窃取数据的问题；与隐私问题形成鲜明对比的是，隐私问题是指您所添加的第三方未经您（或当事人）同意会窃取或获取您用户数据的访问权限。

例如，“网络刷机”会窃取信用卡信息。第三方资源是指用户输入信用卡详细信息的页面中包含的第三方资源，可能会窃取这些信用卡详细信息并将其发送给恶意的第三方。创建这些快速浏览脚本的人在找地方隐藏它们时，很有创意。 一份摘要描述了浏览脚本如何隐藏在第三方内容中，例如用于网站徽标、网站图标和社交媒体网络的图片，以及 jQuery、Modernizr 和 Google 跟踪代码管理器等热门库、实时聊天窗口等网站微件以及 CSS 文件。

隐私权问题略有不同。这些第三方是您的产品/服务的一部分；为了维护用户对您的信任，您需要确信用户可以信任他们。如果您使用的第三方收集用户相关数据，然后滥用这些数据、使数据难以删除或发现、数据泄露或违反用户的预期，您的用户可能会认为这是他们对您的服务的信任，而不只是对第三方的信任。这是您在网络上的声誉和关系。因此，请务必问问自己：您是否信任您在网站上使用的第三方？

能否举一些属于第三方的例子？

我们所讨论的是“第三方”，但实际上它分为不同的类型，它们可以访问的用户数据量也不同。 例如，与添加 <iframe> 或 <script> 元素相比，向从不同服务器加载的 HTML 中添加 <img> 元素会使该服务器的用户信息有所不同。这些只是示例，而非完整的列表，但了解您的网站可以使用的各种第三方内容类型之间的区别会很有帮助。

请求跨网站资源

跨网站资源是指您网站上从其他网站加载的任何内容，它不是 <iframe> 或 <script>。示例包括 <img>、<audio>、<video>、由 CSS 加载的网页字体以及 WebGL 纹理。这些请求都是通过 HTTP 请求加载的，并且如前所述，这些 HTTP 请求将包含其他网站先前设置的所有 Cookie、发出请求的用户的 IP 地址以及当前网页的网址作为引荐来源网址。过去，所有第三方请求均默认包含此类数据，但我们会尽量减少或隔离各种浏览器向第三方传递的数据，如下文的“了解第三方浏览器保护措施”部分所述。

嵌入跨网站 iframe

除了 Cookie、IP 地址和引荐来源网址三者外，通过 <iframe> 嵌入到您网页中的完整文档可以请求对浏览器 API 的更多访问权限。可供 <iframe> 页面使用的确切 API 及其请求访问权限的方式因浏览器而异，目前正发生变化：请参阅下文的“权限政策”，了解目前针对限制或监控嵌入式文档中的 API 访问权限所做的努力。

执行跨网站 JavaScript

加入 <script> 元素后，系统会在网页的顶级上下文中加载并运行跨网站 JavaScript。这意味着，运行的脚本对您自己的第一方脚本所执行的所有内容都拥有完全访问权限。浏览器权限仍会管理这些数据，因此，请求用户的位置（例如）仍然需要用户同意。但是，此类脚本可以读取网页上存在或作为 JavaScript 变量提供的任何信息，这不仅包括作为请求的一部分向第三方传递的 Cookie，还包括仅用于您网站的 Cookie。同样，加载到网页上的第三方脚本可以发出与您自己的代码相同的所有 HTTP 请求，也就是说，它可以向后端 API 发出 fetch() 请求以获取数据。

在依赖项中包含第三方库

如前所述，您的服务器端代码还可能包含第三方依赖项，这些依赖项与其强大功能无法区分开来；从 GitHub 代码库或编程语言库（npm、PyPI、Composer 等）添加的代码可以读取与其他代码相同的数据。

了解第三方

因此，您需要对自己的第三方供应商名单及其在隐私权、数据收集以及用户体验方面的立场和政策有一定了解。然后，这种理解将成为您一系列权衡的一部分：服务的实用性和重要性，及其需求对用户的干扰、不便或不安静程度。第三方内容可以代您承担网站所有者的繁重工作，从而提供价值，让您能够专注于自己的核心能力；因此，在牺牲用户舒适度和隐私的同时，换取更出色的用户体验是值得的。请勿将用户体验与开发者体验混淆：“我们的开发团队能够更轻松地构建服务”对用户来说不是一个有说服力的故事。

如何理解这一点就是一个审计过程。

审核您的第三方

了解第三方的工作就是审核流程。无论是从技术层面还是非技术层面，您都可以为单个第三方和整个集合执行此操作。

进行非技术审核

第一步是非技术：阅读供应商的隐私权政策。如果您包含任何第三方资源，请查看隐私权政策。这些文档内容详尽且详尽，而且有些文档可能会采用一些在先前的单元中明确发出警告的方法，例如过于笼统的声明，并且不包含任何关于如何或何时移除所收集数据的指示。请务必注意，从用户的角度来看，在您的网站上收集的所有数据（包括由第三方收集的数据）都将受到这些隐私权政策的约束。即使您一切都正确无误，但如果您清晰明确地介绍了自己的目标，并超出了用户对数据隐私和敏感度的预期，用户也可能需要为您选择的第三方的任何行为负责。如果客户的隐私权政策中有任何内容会降低用户信任，因而您不愿在政策中加以说明，请考虑是否有替代供应商。

这项指标可与下文进一步讨论的技术审核协同发挥作用，因为它们可以相互补充信息。您应该了解由于业务原因（例如广告网络或嵌入式内容）而添加的第三方资源。这是开始非技术审核的好位置。技术审核还可能会找出第三方，尤其是出于技术而非业务原因纳入的第三方（外部组件、分析、实用程序库），并且这份名单可以与侧重于业务的第三方名单合并。这样做的目的是，让作为网站所有者的您了解要添加到网站中的第三方在做什么，同时您作为企业能够向法律顾问提供这些第三方目录，以确保自己履行所有必要的义务。

进行技术审核

在进行技术审核时，务必将相关资源作为网站的一部分使用；也就是说，不要在自动化测试框架中加载依赖项并以此方式进行检查。请确保您查看的依赖项如何作为实际网站的一部分（部署在公共互联网上，而不是测试或开发模式）。以新用户的身份查看自己的网站，能够带来极大的指导。使用干净的新个人资料打开浏览器，使您未登录且未存储任何协议，然后尝试访问您的网站。

如果您提供了用户帐号，请在您自己的网站上注册新帐号。您的设计团队已从用户体验的角度编排了这一新用户获取流程，但从隐私保护的角度来看可作为说明。不要只是在条款及条件、Cookie 警告或隐私权政策上点击“接受”，而应将“使用您自己的服务”设为自己不披露任何个人信息或安装任何跟踪 Cookie 的任务，然后看看能否做到这一点，以及做到这一点的难度如何。此外，您不妨查看一下浏览器开发者工具，了解用户在访问哪些网站以及将哪些数据传递到了这些网站。开发者工具会提供一系列单独的 HTTP 请求（通常位于名为“Network”的部分），您可以从此处看到按类型（HTML、CSS、图片、字体、JavaScript、由 JavaScript 发起的请求）分组的请求。您还可以添加新列，以显示每个请求的域名，该列中会显示正在联系多少个不同的地点，还可能有一个“第三方请求”复选框，用于仅显示第三方。（使用 Content-Security-Policy 报告进行持续审核也很有用，下文将进一步介绍。）

Simon Hearne 的“Request Map Generator”工具也有助于大致了解公开可用的页面发出的所有子请求。

此时，您可以将那些被确定为参与非技术审计的以业务为中心的第三方（即，与您有财务关系以便使用其资源的一系列公司）。这样做是为了将你认为正在使用的第三方的列表（来自财务和法律记录）与你实际使用的第三方列表（通过查看你的网站发出的第三方 HTTP 请求）进行匹配。您应该能够确定每个业务第三方发出了哪些技术出站请求。如果您在技术审核中无法识别针对由业务关系标识的第三方的请求，请务必找出原因，并使该第三方资源能够指导测试：可能第三方资源仅在特定国家/地区加载，或仅在特定设备类型上加载，或者面向已登录用户加载。这会扩大您要审核的网站区域列表，并确保您能看到所有出站访问。（或者，它可能会标识您付费但未使用的第三方资源，这始终会让财务部门更加愉悦。）

缩小向您希望纳入审计的第三方的要求列表后，点击单个要求即会显示其所有详细信息，尤其是向该请求传递的数据。此外，您的代码发起的第三方请求接着又发起许多其他第三方请求，这种情况也很常见。这些额外的第三方也会“导入”到您自己的隐私权政策中。这项任务费时费力但很有价值，并且通常可以运用到现有分析中；您的前端开发团队应该已经出于性能原因审核请求（也许借助 WebPageTest 或 Lighthouse 等现有工具），而将数据和隐私审核集成到该过程中可以简化该过程。

web.dev 请求映射。
（大幅简化的）web.dev 请求地图，其中显示请求第三方网站的第三方网站，等等。

正确做法

使用干净的新用户个人资料打开浏览器，这样您就没有登录并且没有存储的协议；然后打开浏览器开发工具的“网络”面板，查看所有发出的请求。添加新列以显示每个请求的网域，并选中“第三方请求”复选框以仅显示第三方（如果存在）。然后，执行以下操作：

  • 访问您的网站。
  • 如果您提供了用户帐号，请注册新帐号。
  • 尝试删除您创建的帐号。
  • 在网站上执行一两次常规操作（具体执行什么操作取决于您的网站做什么，但要选择大多数用户执行的常见操作）。
  • 执行已知涉及第三方依赖项的一两项操作。这可能包括将内容分享到社交媒体、开始结账流程或嵌入来自其他网站的内容。

在执行每项任务时，请按照说明查看“Network”面板，记录不属于您的网域请求的资源。这些是你的部分第三方。要做到这一点，一个好方法是使用浏览器网络工具以 HAR 文件中的网络请求日志捕获网络请求日志。

HAR 文件和记录

HAR 文件是网页发出的所有网络请求的标准化 JSON 格式。 要获取特定网页的 HAR 文件，请在以下位置添加：

Chrome

打开浏览器开发者工具（菜单 > 更多工具 > 开发者工具），转到“网络”面板，加载（或刷新）页面，然后选择右上角“无节流”下拉菜单附近的向下箭头保存符号。

Chrome 开发者工具网络面板，其中突出显示了“下载 HAR”符号。
Firefox

打开浏览器开发者工具（依次点击菜单 > 更多工具 > Web 开发者工具），转到“网络”面板，加载（或刷新）页面，然后选择右上角限制下拉菜单旁边的齿轮符号。从菜单中选择全部另存为 HAR**。

Firefox 开发者工具“网络”面板，其中突出显示了“全部另存为”选项。
Safari

打开浏览器开发者工具（依次点击菜单 > 开发 > 显示 Web Inspector；如果您没有“开发”菜单，请在菜单栏中依次点击 Menu > Safari > Preferences > Advanced > Show Develop menu 启用此菜单），转到“Network”面板，加载（或刷新）页面，然后选择右上角的 Export（位于“Preserve Log”右侧；您可能需要放大该窗口）。

Safari Web Inspector“Network”面板，其中突出显示了 HAR 导出选项。

如需了解详情，您还可以记录传递给第三方的内容（在“请求”部分），不过此类数据通常经过混淆处理，无法用于解读。

集成第三方的最佳做法

您可以针对您的网站使用的第三方设置自己的政策：根据他们的做法更改您使用的广告提供商，或他们的 Cookie 意见征求弹出式窗口的多余程度或干扰程度，或者是否要在您的网站上使用社交媒体按钮，或是否跟踪电子邮件中的链接或 utm_campaign 链接，以便在 Google Analytics（分析）中跟踪您的 Twitter 推文。开发网站时要考虑的一个方面是分析服务的隐私性和安全性。一些分析服务会明确以保护隐私为代价来达成目标。通常情况下，也可以使用第三方脚本本身加强隐私保护：您不是第一个希望改善用户隐私并保护用户免受第三方数据收集的团队，可能已经有解决方案。最后，与过去相比，许多第三方提供商现在对数据收集问题更为敏感，并且通常可以添加一些功能或参数，以保护用户更安全的模式。以下是一些示例。

添加社交媒体分享按钮时

考虑直接嵌入 HTML 按钮：网站 https://sharingbuttons.io/ 提供了一些精心设计的示例。 或者，您可以添加纯 HTML 链接。需要权衡的是，您将失去“分享次数”统计信息，也无法再在 Facebook Analytics（分析）中对客户进行分类。这是一个在使用第三方提供商与接收较少分析数据之间做出取舍的示例。

更笼统地说，当您嵌入来自第三方的某种交互式 widget 时，通常可以改为提供指向该第三方的链接。这表明您的网站不提供内嵌式体验，但会将与第三方分享数据的决定从您转移给用户，用户可以自行决定是否按照自己的方式进行互动。

例如，您可以添加 Twitter 和 Facebook 链接，以便在 mysite.example.com 上分享您的服务，如下所示：

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

请注意，Facebook 允许指定要分享的网址，Twitter 允许指定网址和一些文本。

嵌入视频时

当您嵌入来自视频托管网站的视频时，请在嵌入代码中查找隐私保护选项。 例如，对于 YouTube，请将嵌入网址中的 youtube.com 替换为 www.youtube-nocookie.com，以避免将 Cookie 置于查看嵌入页面的用户身上。在通过 YouTube 生成分享/嵌入链接时，您还可以选中“启用隐私权保护增强模式”。这是一个使用第三方提供的保护级别更高的模式的一个示例。 （https://support.google.com/youtube/answer/171780 对此进行了更详细的说明，并专门针对 YouTube 的其他嵌入选项进行了说明。）

在这方面，其他视频网站提供的选项较少：例如，在撰写本文时，TikTok 不支持在没有跟踪的情况下嵌入视频。您可以自行托管视频（这是使用替代方案），但需要完成更多工作，尤其是要支持许多设备。

与前面讨论的互动式微件一样，通常也可以用指向提供网站的链接替换嵌入的视频。 这种方式的互动性较低，因为视频不会以内嵌方式播放，用户可自行选择是否观看。这可用作“Facade 模式”的示例，“Facade 模式”使用名称将交互式内容动态替换为需要用户操作才能触发互动的内容。嵌入的 TikTok 视频可以替换为指向 TikTok 视频页面的普通链接，但只要再多做一点工作，就可以检索并显示视频的缩略图并将其设为链接。即使所选视频提供商不支持轻松嵌入视频而不跟踪视频，许多视频主机都支持 oEmbed，该 API 在获得视频或嵌入内容的链接时，会返回其程序化详情，包括缩略图和标题。TikTok 支持 oEmbed（如需了解详情，请参阅 https://developers.tiktok.com/doc/embed-videos），这意味着您可以（手动或以编程方式）使用 https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173 将指向 TikTok 视频 https://www.tiktok.com/@scout2015/video/6718335390845095173 的链接转换为有关该视频的 JSON 元数据，从而检索要显示的缩略图。例如，WordPress 通常使用它来请求嵌入内容的 oEmbed 信息。您可以通过编程方式来显示“外观互动”效果，并可在用户选择点击视频时切换为嵌入或链接到互动式视频。

嵌入分析脚本时

Google Analytics（分析）旨在收集用户信息以便用于分析，这正是它的用途。分析系统本质上是一种用于收集和显示访问情况和用户相关数据的服务，为便于实现而在第三方服务器（如 Google Analytics [分析]）上进行。此外，还有一些自托管的分析系统，例如 https://matomo.org/，但与使用第三方解决方案相比，这种方法更复杂。但是，在您自己的基础架构上运行此类系统可以帮助您减少数据收集，因为它不会离开您自己的生态系统。另一方面，管理、移除数据并为其设置政策则由您负责。如果跨网站跟踪是秘密进行的，或者是由于使用根本不需要收集数据的服务而产生的副作用，则很多问题都可从跨网站跟踪入手。从明显的设计上看，分析软件旨在收集数据，目的是让网站所有者了解其用户。

历史上一直有一种方法，即尽可能收集所有有关一切的数据，就像巨大的渔网一样，稍后再进行分析，以找出值得关注的模式。这种思维在很大程度上引发了对数据收集的不安和不安的感觉，详见本课程第 1 部分。现在，许多网站会先确定要问哪些问题，然后收集具体且有限的数据来回答这些问题。

如果您的网站和其他网站使用某个第三方服务，并且您通过您将这些第三方服务的 JavaScript 代码添加到网站中，并为每个用户设置了 Cookie，那么请务必考虑这些第三方服务可能会进行不必要的跨网站识别，也就是跨网站跟踪用户。虽然有些可能，也可能不会，但是此处的隐私保护立场是，除非您有充分的理由认为或知道，否则此类第三方服务实际上会执行跨网站跟踪。这本身并不是避免使用此类服务的理由，但在评估使用此类服务的权衡时需要考虑这一点。

过去，在分析时，我们只决定是否要使用它：收集所有数据并危及隐私以换取数据洞见和规划，或者完全放弃数据洞见。然而，情况已经不同了，现在通常可以找到在这两种极端情况之间找到的中间点。请查看您的分析服务提供商，了解用于限制收集的数据并减少其存储量和时长的配置选项。由于您拥有之前介绍的技术审核的记录，因此您可以重新运行该审核的相关部分，以确认更改这些配置确实会减少收集的数据量。如果您是在现有网站上进行这种转换，则可以为您提供一些可量化的衡量指标，并供用户写入其中。例如，Google Analytics（分析）提供多项选择启用（因此默认处于关闭状态）隐私权功能，其中许多功能可能有助于遵守当地的数据保护法律。设置 Google Analytics（分析）时需要考虑的一些选项包括，将已收集数据的保留期限（“管理”>“跟踪信息”>“数据保留”）设置为低于 26 个月的默认值，以及启用一些技术性更强的解决方案，例如部分 IP 匿名化（如需了解详情，请参阅 https://support.google.com/analytics/answer/9019185）。

以保护隐私的方式使用第三方

到目前为止，我们已经讨论了如何在应用的设计阶段保护您的用户免受第三方的侵扰，同时您规划应用的用途。决定根本不使用某个特定第三方是此规划的一部分，而审核使用情况也属于这一类别：您的隐私立场会由您做出决策。然而，这些决策从本质上来说并不是非常精细；选择使用某个第三方或不是使用某个第三方，则不是一项微妙的决策。您很可能希望介于两者之间：需要或计划使用特定的第三方产品，但要减少任何侵犯隐私权的趋势（无论是有意还是无意）。这是在“构建时”保护用户的任务：添加保护措施来减少您预料不到的损害。所有这些都是新的 HTTP 标头，您可以在传送网页时提供这些标头，用以提示或命令用户代理采取某些隐私保护或安全规范。

引荐来源网址政策

正确做法

将政策设为 strict-origin-when-cross-origin 或 noreferrer，可防止其他网站在您链接到其他网站或被网页作为子资源加载时收到引荐来源网址标头：

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

也可以在服务器端创建，例如在 Express 中：

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

如有必要，请针对特定元素或请求设置更宽松的政策。

为何这样做可以保护用户隐私

默认情况下，浏览器发出的每个 HTTP 请求都会传递一个 Referer 标头，该标头包含发起请求的页面的网址（无论是链接、嵌入图片还是脚本）。这可能会带来隐私问题，因为网址可能包含私密信息，而可供第三方访问的网址会将此类私密信息传递给它们。Web.dev 列出了一些包含私密数据的网址示例，如果获知用户从 https://social.example.com/user/me@example.com 来到您的网站，您就知道该用户是谁，这是绝对的泄露。然而，即使网址本身不会显示私密信息，但也会表明该用户（如果该用户已登录，您可能知道该用户）是从其他网站访问到这里的，因此也就表明该用户访问了这个网站。这本身就是泄露了您可能不应该知道的用户浏览记录的信息。

提供 Referrer-Policy 标头（拼写正确！）可让您对此进行更改，以便传递部分或全部引荐来源网址。 MDN 列出了完整详细信息，但大多数浏览器现在默认采用假设的 strict-origin-when-cross-origin 值，这意味着引荐来源网址现在仅作为来源（https://web.dev 而不是 https://web.dev/learn/privacy）传递给第三方。这是一种实用的隐私保护措施，您无需采取任何措施。不过，您可以通过指定 Referrer-Policy: same-origin 来进一步加强限制，从而避免将任何引荐来源信息传递给第三方（或者指定 Referrer-Policy: no-referrer，避免传递给包括您自己的来源在内的任何人）。（这是一个很好的示例，很好地实现了隐私与实用程序的平衡；新的默认选项比之前在隐私保护方面更强，但它仍然会向您选择的第三方（例如您的分析服务提供商）提供高级信息。）

明确指定此标头也很有用，因为这样您就可以确切地知道政策是什么，而不是依赖于浏览器默认设置。 如果您无法设置标头，则可以使用 <head>:<meta name="referrer" content="same-origin"> 中的元元素为整个 HTML 网页设置引荐来源网址政策；如果您关注的是特定第三方，还可以为 <script>、<a> 或 <iframe> 等单个元素设置 referrerpolicy 属性：<script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

内容安全政策

Content-Security-Policy 标头（通常称为“CSP”）指示可以从何处加载外部资源。它主要用于确保安全，通过防止跨站脚本攻击和脚本注入。但是，如果将其与定期审核结合使用，它还会限制您选择的第三方将数据传递到的位置。

这样的用户体验可能欠佳；如果您的某个第三方脚本开始从不在您列表中的来源加载依赖项，则该请求将被屏蔽，脚本将失败，您的应用可能会因此而失败（或至少降级到其 JavaScript 失败的回退版本）。如果为了安全而实施 CSP，那么实现 CSP 时很有用，这是其正常用途：防止跨站脚本问题（为此，请使用严格的 CSP）。知道网页使用的所有内联脚本后，您可以列出这些脚本，针对每个脚本计算哈希值或添加一个随机值（称为“随机数”），然后将哈希值列表添加到您的内容安全政策中。这样可以阻止加载任何不在列表中的脚本。这需要纳入网站的生产流程中：网页中的脚本需要包含 Nonce，或者要在构建过程中计算哈希值。有关全部详情，请参阅关于 Strict-csp 的文章。

幸运的是，浏览器支持相关标头 Content-Security-Policy-Report-Only。如果提供了此标头，则不会阻止违反所提供政策的请求，但会将 JSON 报告发送到提供的网址。此类标头可能如下所示：Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/，如果浏览器从 3p.example.com 以外的任何位置加载脚本，该请求将会成功，但系统会向所提供的 report-uri 发送报告。通常，这用于在实现政策之前对政策进行实验，但此处的一个实用建议是将其用作“持续审核”的方式。除了前面描述的定期审核之外，您还可以启用 CSP 报告以查看是否出现任何意外网域，这可能意味着您的第三方资源正在加载自己的第三方资源，您需要考虑和评估这些资源。（这也可能是因为某些跨站脚本攻击绕过了您的安全边界，这一点也很重要！）

Content-Security-Policy 是一个复杂而复杂的 API，需要使用。这是众所周知的，并且正在努力构建“新一代”CSP，这种 CSP 能够实现相同的目标，但用起来并不那么复杂。这个方法尚不完善，但如果您想了解其发展方向（或者参与设计并提供帮助！），请访问 https://github.com/WICG/csp-next 了解详情。

正确做法

将此 HTTP 标头添加到提供的网页中：Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control。 当 JSON 发布到该网址时，请存储它。查看已存储的数据，以获取您的网站在被其他人访问时请求的第三方网域的集合。 更新 Content-Security-Policy-Report-Only 标头以列出您需要的网域，以便查看列表何时发生更改：

Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control

原因

这将是持续进行的技术审核的一部分。在进行初步技术审核后，系统会列出您的网站会将用户数据共享给哪些第三方，或将哪些第三方用于传递用户数据。然后，此标头会使网页请求报告正在与哪些第三方联系，然后您就可以跟踪一段时间的变化。这不仅会提醒您现有第三方所做的更改，还会标记未纳入技术审核的新添加第三方。请务必更新标头以停止报告有关您预期的网域，但也请务必不时重复执行手动技术审核（因为 Content-Security-Policy 方法不会标记传递的数据，而只会标记已发出请求）。

请注意，并非每次都向显示的网页或所有网页都添加标记。请减少接收该标头的页面响应数量，以确保您能收到数量不多的代表性报告样本。

权限政策

Permissions-Policy 标头（在名称 Feature-Policy 下引入）在概念上与 Content-Security-Policy 类似，但限制了对强大的浏览器功能的访问。例如，可以限制使用设备硬件（例如加速度计、相机或 USB 设备），也可以限制非硬件功能（例如允许全屏或使用同步 XMLHTTPRequest）。这些限制可应用于顶级网页（以避免加载的脚本尝试使用这些功能）或通过 iframe 加载的子框架网页。这种 API 使用限制实际上与浏览器指纹无关，而是在于禁止第三方执行干扰性操作（例如使用强大的 API、弹出权限窗口等）。目标隐私威胁模型将其定义为“入侵”。

Permissions-Policy 标头被指定为（功能, 允许的来源）对列表，因此：

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

此示例允许此网页（“self”）和来自原始 example.com 的 <iframe> 使用 JavaScript 中的 navigator.geolocation API；它允许此网页和所有子框架使用全屏 API，并禁止任何网页（包括此网页）使用相机读取视频信息。如需了解详情和查看可能的示例，请点击此处。

由 Permissions-Policy 标头处理的功能列表很长，并且可能会不断变化。目前，该列表保存在 https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md。

正确做法

默认情况下，支持 Permissions-Policy 的浏览器不允许在子框架中使用强大的功能，您必须采取相应措施才能启用这些功能！ 默认情况下，此方法为私有方法。如果您发现自己网站上的子框架需要这些权限，可以有选择地添加子框架。 但是，默认情况下，主页面没有应用权限政策，因此主页面加载的脚本（包括第三方脚本）可以不受限制地尝试使用这些功能。因此，最好默认对所有页面应用限制性 Permissions-Policy，然后逐步重新添加页面所需的功能。

受 Permissions-Policy 影响的各种强大功能的示例包括请求用户的位置信息、访问传感器（包括加速度计、陀螺仪和磁力计）、进入全屏模式的权限，以及请求访问用户的相机和麦克风。上面链接了（变动的）功能的完整列表。

遗憾的是，默认情况下阻止所有特征，然后选择性地重新允许它们需要列出在标头中列出所有特征，这可能会让人感觉不太好。不过，此类 Permissions-Policy 标头不失为一个好的起点。permissionspolicy.com/ 有一个方便点击的生成器来创建此类标头：使用它来创建会停用所有功能的标头，结果如下：

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

了解网络浏览器中内置的隐私保护功能

除了“构建时”和“设计时”保护措施之外，还有“运行时”保护功能，即在浏览器中实现的隐私保护功能，以保护用户。这些功能并不是网站开发者可以直接控制或利用的功能，而是产品功能。但是，您应该了解这些功能，因为您的网站可能会受到浏览器中的这些产品决策的影响。这里举例说明这些浏览器保护措施可能会对您的网站有何影响，如果您的客户端 JavaScript 在继续进行网页设置之前会等待第三方依赖项加载，而该第三方依赖项根本不会加载，那么您的网页设置可能永远无法完成，因此用户看到的是半加载的网页。

其中包括 Safari（及底层 WebKit 引擎）中的智能反跟踪，以及 Firefox（及其引擎 Gecko）中的增强型跟踪保护。这些因素都会导致第三方难以构建详细的用户画像。

浏览器与隐私保护功能相关的方法经常变化，因此请务必及时了解最新信息；以下保护措施列表在撰写本文时是正确的。浏览器还可能会实施其他保护措施；这些列表并非详尽无遗。请参阅最佳实践模块，了解在这方面跟上变化的方法。此外，请务必使用即将推出的浏览器版本进行测试，以发现可能会影响您项目的变更。 请注意，无痕模式/无痕浏览模式有时会采用与浏览器默认设置不同的设置（例如，在此类模式下，第三方 Cookie 可能会默认被屏蔽）。因此，如果用户未使用无痕浏览，则在无痕模式下进行的测试可能无法总是反映大多数用户的典型浏览体验。另请注意，在不同情况下屏蔽 Cookie 可能意味着其他存储解决方案（例如 window.localStorage）也会被屏蔽，而不仅仅是 Cookie。

Chrome

  • 我们会在未来屏蔽第三方 Cookie。截止到撰写本文时，它们在默认情况下不会被屏蔽（但用户可以启用此功能）：https://support.google.com/chrome/answer/95647 对此进行了详细说明。
  • 如需了解 Chrome 的隐私保护功能，尤其是 Chrome 中与 Google 和第三方服务通信的功能，请访问 privacysandbox.com/。

Edge

  • 默认情况下，第三方 Cookie 不会被屏蔽（但用户可以启用此功能）。
  • Edge 的防跟踪功能会屏蔽来自未访问过的网站的跟踪器，并且默认会屏蔽已知的有害跟踪器。

Firefox

如要了解可能被屏蔽的内容并帮助调试问题，请点击地址栏中的盾牌图标，或在 Firefox 中访问 about:protections（桌面版）。

Safari

  • 默认情况下，系统会屏蔽第三方 Cookie。
  • 作为其智能反跟踪功能的一部分，Safari 会将传递给其他网页的引荐来源网址减少为顶级网站而不是特定网页：（https://something.example.com，而不是 https://something.example.com/this/specific/page）。
  • 浏览器 localStorage 数据会在七天后删除。

（https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ 对这些功能进行了总结。）

如要深入了解可能被屏蔽的内容并帮助调试问题，请在 Safari 的开发者菜单中（在桌面设备上）启用“智能反跟踪调试模式”。（如需了解详情，请参阅 https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/。）

API 提案

为什么我们需要新的 API？

虽然浏览器产品中新的隐私保护功能和政策有助于保护用户隐私，但同时也带来了一些挑战。 许多网络技术即使设计用于其他用途，也可用于跨网站跟踪。例如，我们日常使用的许多身份联合系统都依赖于第三方 Cookie。如今，发布商赖以赚取收入的许多广告解决方案都建立在第三方 Cookie 之上。许多欺诈检测解决方案都依赖于数字“指纹”收集。当第三方 Cookie 和数字“指纹”收集停用后，这些用例会发生什么情况？

浏览器很难区分各种使用情形，并可靠地区分违反隐私保护法的使用情形与其他使用情形。正因如此，大多数主流浏览器都已阻止第三方 Cookie 和数字“指纹”收集，或打算这样做，以保护用户隐私。

需要一种新方法：随着第三方 Cookie 逐步淘汰并减少数字“指纹”收集的影响，开发者需要专门构建的 API，这些 API 既能满足用例（尚未消失），又能以可保护隐私的方式进行设计。我们的目标是设计和构建无法用于跨网站跟踪的 API。与上一部分中介绍的浏览器功能不同，这些技术渴望成为跨浏览器 API。

API 提案示例

下面的列表并不详尽，我们讨论的只是其中的部分内容。

取代基于第三方 Cookie 的技术的 API 提案示例：

用于取代基于被动跟踪的技术的 API 提案示例：

其他 API 未来可在不使用第三方 Cookie 的情况下据以构建的其他提案示例：

此外，新型 API 方案正在涌现，旨在尝试针对目前的浏览器实施隐蔽跟踪缓解措施。 例如隐私预算。在这些使用场景中，Chrome 最初提出的 API 是按照 Privacy Sandbox 这一统称为“涵盖”的 API 上线的。

Global-Privacy-Control 是一个标头，用于向网站表明用户不希望与其他网站分享收集到的任何个人数据。其意图类似于已停用的“请勿跟踪”功能。

API 提案的状态

其中大多数 API 提案尚未部署，或者仅部署在标志后面或在受限环境中进行实验。

这个公开孵化阶段非常重要：浏览器供应商和开发者会就这些 API 是否实用以及它们是否真正实现其目标，收集相关讨论和经验。开发者、浏览器供应商和其他生态系统参与者通过该阶段迭代 API 的设计。

如需了解最新的 API 提案，最好查看 Privacy Group 在 GitHub 上的提案列表。

您是否需要使用这些 API？

如果您的产品是直接基于第三方 Cookie 或数字“指纹”收集等技术构建的，您应该使用这些新 API 进行实验，并在讨论和 API 设计中贡献您自己的经验。 在所有其他情况下，您不一定需要在撰写本文时了解这些新 API 的所有细节，但提前了解即将推出的功能会是不错的选择。