感谢您关注 Google I/O 大会！观看点播内容。

此页面由 Cloud Translation API 翻译。

第三方

什么是第三方？

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

《年鉴》将第三方内容定义为托管在共享和公共来源上的内容，广泛应用于不受单个网站所有者的影响。可以是图片或其他媒体，例如视频、字体或脚本。图片和脚本的作用是相辅相成的。第三方内容对于网站开发而言并不是必需的也可能是这样您几乎肯定会使用从公共共享服务器加载的内容，视频、广告或 JavaScript 库的嵌入式 iframe。例如，您可能使用的是 Google Fonts 提供的网络字体、或使用 Google Analytics 衡量分析效果；您可能在社交网络上添加了“顶”按钮或“登录方式”按钮；您可能嵌入了地图或视频，或者通过第三方服务处理购物购买交易；您可能会跟踪错误通过第三方监控工具为您自己的开发团队进行日志记录。

出于隐私保护目的，考虑采用稍微不同且不太宽泛的定义非常有用：第三方资源，尤其是第三方脚本，由共享的公共源提供，广泛用于插图，但同时也是编写的由网站所有者以外的其他人提交在考虑如何保护您的个人版权归属时，第三方作者身份 用户的不侵犯他人隐私。您需要考虑存在哪些风险，然后决定如何或是否使用保护第三方资源。如前所述，这些信息将帮助您了解因此，了解您需要做出哪些取舍以及取舍意味着什么。

讨论“第三方资源”时，这并不是什么意思但总体而言，第一方和而第三方实际上是一种使用环境从其他网站加载的脚本是第三方而用于加载脚本的 HTTP 请求可能包含 Cookie，但这些 Cookie 实际上并不是“第三方 Cookie”；它们只是 Cookie，以及它们是否是“第三方”或“第一方”取决于脚本是否正在或脚本所有者网站上的某个网页。

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

第三方是向您的网站添加功能的好方法。这可能是向用户显示的功能，也可能是不可见的功能开发功能（例如错误跟踪），但这些功能会降低开发工作量，而且脚本本身可以得到维护包括您要包含的服务的开发团队。这一切都得益于 Web 的可组合性：能够将多个部分组合在一起，形成一个整体，整体大于它们的总和。

HTTP Archive 的网络年历给出很好的描述：

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

第三方资源可以做什么？

访问某些信息

当您在网站上使用第三方资源（无论其是什么）时，一些信息会传递给该第三方。例如，如果您添加了来自其他网站的图片，用户浏览器发出的 HTTP 请求将传递引荐来源网址。标头替换为网页网址以及用户的 IP 地址。

跨网站跟踪

继续前面的例子。当图片从第三方网站加载时，其中可能会包含 Cookie，而该 Cookie 会在用户下一次请求该图片时发送回第三方。也就是说，第三方可以知道服务会传回一个 Cookie，其中可能包含该用户的唯一 ID。这意味着当用户下次访问您的网站或包含来自该第三方资源的任何其他网站时，系统就会记录一次 ID Cookie 会再次发送。这样，第三方就可以创建关于用户访问的位置的日志：您的网站、在整个网络上使用相同的第三方资源。

这是跨网站跟踪：允许第三方收集用户在许多网站上的活动日志，只要这些网站所有网站均使用来自同一第三方的资源。这可能是字体、图片或样式表，它们都是静态资源。它也可能是动态资源：一段脚本、一个社交媒体按钮和广告。包含的脚本可以收集更多数据，信息，因为它是动态的：它可以检查用户的浏览器和环境，并将该数据传回其创建者。任何脚本都能在某种程度上实现此目标，并非以脚本形式呈现的动态资源（例如社交媒体嵌入）或广告或分享按钮。如果您仔细观察热门网站上的 Cookie 横幅，就能看到一系列组织。那里可能数以百计如果第三方免费提供某项服务，有一种经济可行的方式是因为他们收集这些数据，然后利用这些数据进行创收。

目标隐私威胁模型是一个有用的指南，可帮助您了解浏览器应保护用户免受哪些类型的隐私问题。在撰写本文时，该文档仍在讨论中，但它对各类存在的隐私威胁。来自第三方资源的风险主要是“不必要的跨网站识别”，网站可以在多个网站上识别同一用户，还可以利用“敏感信息披露”政策，用户认为敏感的信息。

这是一个关键的区别：多余的跨网站识别也是坏事，即使第三方没有收集到额外的敏感数据，因为这会取消用户对自己身份的控制权。获取用户的引荐来源网址和 IP 地址的访问权限而 Cookie 本身是一种不必要的披露。使用第三方资源的同时，还需要规划资源使用方式保护隐私。其中一部分工作由您作为网站开发者完成，另一些则是由浏览器完成它充当用户代理也就是说，代理代表用户执行操作来避免敏感信息泄露和尽可能避免不必要的跨网站识别下面，我们将详细介绍浏览器上的缓解措施和方法和网站开发级别。

服务器端第三方代码

我们先前对第三方的定义故意改变了 HTTP 年历的客户端方法（视情况而定）包括第三方作者信息，因为从隐私角度来看，第三方是指任何知道相关信息的人，关于您的用户（即非您用户）的信息。

包括提供您在该服务器上所使用服务的第三方，以及客户端。在隐私设置中立场，理解第三方库（例如 NPM、Composer 或 NuGet 中的库）也很重要。您的依赖项是否会在边界外传递数据？如果将数据传递到日志记录服务或远程托管数据库，如果库还包含“phone home”作者，那么这些内容就可能违反您用户的隐私权因此需要进行审核基于服务器的第三方通常必须由您提供用户数据，向其公开的数据有更多的控制权。相比之下，基于客户端的第三方（脚本或 HTTP 资源）包含在您的网站上并由用户的浏览器提取 - 可以直接从用户那里收集一些数据，而无需通过该流程您参与中介的集合本单元的大部分内容将关注如何识别这些客户端第三方您选择包含并向您的用户展示，完全是因为您可以使用的中介较少。但值得考虑保护服务器端代码，以便了解来自它的出站通信，并记录或阻止任何不符合预期。关于如何执行此操作的详细信息不在本文的讨论范围之内（并且非常取决于您的服务器设置），但这也是您在安全和隐私方面的另一个立场。

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

第三方脚本和功能确实非常重要，作为 Web 开发者，我们的目标是将这些功能集成在一起，不要回避他们！但其中存在潜在问题。第三方内容可能会导致性能问题，也会导致安全问题，因为您会在信任边界内引入外部服务。但第三方内容也会造成隐私问题！

当我们谈论网络上的第三方资源时，最好将安全问题（以及其他一些）第三方可从贵公司窃取数据的行为您添加的第三方窃取或访问您用户的数据。

“网络浏览器”就属于安全问题窃取信用卡信息（第三方资源中包含用户输入信用卡详细信息的网页上就有可能窃取这些信用卡详细信息并将其发送给恶意第三方。这些浏览者脚本的创作者在找出隐藏它们的地方非常有创意。一份摘要描述了重点浏览者脚本已隐藏在第三方内容中，例如用于网站徽标、网站图标和社交媒体网络的图片， jQuery、Modernizr 和 Google 跟踪代码管理器等热门库、实时聊天窗口等网站微件，以及 CSS 文件。

隐私权问题稍有不同。这些第三方是您提供的解决方案的一部分；保持用户的您需要确信用户可以信任他们。如果您使用的第三方收集您的用户会滥用这些数据，或者使这些数据难以删除或发现，或遭受数据泄露，或违反用户的预期，那么用户很可能会认为这是他们对您的服务的信任程度，而不是仅仅是对服务质量的信任感第三方。而是您在线上的声誉和关系。因此，务必要问问自己：您是否信任与您的网站一起使用的第三方？

第三方的例子有哪些？

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

请求跨网站资源

跨网站资源是指您网站上从其他网站加载的任何内容，既不是 <iframe> 也不是 <script>。示例包括 <img>、<audio>、<video>、通过 CSS 加载的网页字体以及 WebGL 纹理。这些内容均通过 HTTP 请求进行加载，这些 HTTP 请求将包含其他网站之前设置的所有 Cookie、发出请求的用户的 IP 地址、并将当前网页的网址设为引荐来源网址。尽管以往，所有第三方请求都默认包含此数据， Google 会努力减少或隔离通过各种浏览器传递给第三方的数据，如“了解 “第三方浏览器保护措施”。

嵌入跨网站 iframe

除了 trifecta 之外，通过 <iframe> 嵌入到网页中的完整文档还可以请求访问浏览器 API 的其他访问权限包括 Cookie、IP 地址和引荐来源网址。具体有哪些 API 可用于 <iframe> 的网页，以及它们请求访问权限的方式因浏览器而异。目前正在进行更改：请参阅“权限政策”了解当前为限制或监控文档。

执行跨网站 JavaScript

添加 <script> 元素会在网页的顶级上下文中加载并运行跨网站 JavaScript。这意味着可以完全访问您自己的第一方脚本执行的任何操作。但这些数据仍由浏览器权限管理。因此请求用户位置（举例而言）仍然需要用户同意。但网页或网页中显示的任何信息可被此类脚本读取的 JavaScript 变量，而这不仅包括传递给第三方的 Cookie 作为请求的一部分，还要指定仅用于您的网站的 Cookie。同样，第三方脚本会加载到您的页面可以发出与您自己的代码完全相同的 HTTP 请求，这意味着它可能会向您的后端 API 发出 fetch() 请求以获取数据。

在依赖项中包含第三方库

如前所述，您的服务器端代码还可能包含第三方依赖项，这些依赖项与您自己的依赖项没有区别代码生成功能；从 GitHub 代码库或编程语言库（npm、PyPI、Composer 等）添加的可以读取您的其他代码可以读取的所有数据。

了解您的第三方

那么，您需要对第三方供应商列表有一定了解，以及他们的隐私权、数据收集和用户对用户体验的态度和政策至关重要。然后，你需要权衡这些权衡：了解应用的实用性和重要性是服务，权衡了用户需求对用户的干扰、不便或令人不安。第三方内容能够为您带来价值，因为网站所有者可代您完成许多繁杂的工作，并且让您能专注于自己的核心能力；因此，我们可以做出这种权衡取舍，牺牲一些用户舒适度和隐私性来提升用户体验。但务必不要将用户体验与开发者体验混淆：“对于我们的开发团队而言，构建服务”对用户来说不够有吸引力的故事。

如何实现这一目标，就属于审计流程。

审核您的第三方

审核过程就是了解第三方的行为。无论是在技术上还是在非技术上，你都可以完成这项工作。

进行非技术审核

第一步是非技术步骤：阅读供应商的隐私权政策。如果你添加了任何第三方资源查看隐私权政策。这类内容比较长且包含大量法律文本，有些文档可能会采用在早期模块中明确发出警告，例如过于笼统的语句，且没有任何指示会如何或何时移除收集的数据。需要注意的是，从用户的角度来看，在您的网站上收集（包括由第三方收集），则受这些隐私政策约束。即使您一切都正确无误，前提是您开诚布公地说明了自己的目标，并且超越了用户对数据隐私的期望和敏感性，用户可能也要求您对您选择的第三方所做的一切负责。如果其中有任何您不想在自己的政策中列明的隐私权政策，因为这会减少用户的信任，那么考虑是否有替代供应商。

这些信息与后续讨论的技术审核必不可少，因为其中有另一个。您应该知道出于业务原因整合的第三方资源（例如广告联盟）或嵌入式内容），因为其中会存在业务关系。这是开始进行非技术性工作的好时机审核。技术审核也有可能确定第三方，尤其是那些业务原因（外部组件、分析、实用程序库），并且该列表可与专注于业务的第三方。我们的目标是让网站所有者让您了解以及作为企业的有责任以确保您履行了所要求的所有义务。

运行技术审核

在进行技术审核时，请务必在网站中原位使用相关资源；也就是说，不要加载依赖项并以此方式进行检查。确保您可以看到依赖项作为实际网站一部分的作用，部署在公共互联网上，而不是在测试或开发模式下部署。将自己的网站视为新用户。使用全新配置文件打开浏览器，确保您处于未登录状态且未存储协议，然后尝试访问您的网站。

如果您提供用户账号，请在您自己的网站上注册一个新账号。您的设计团队将安排这个新用户但从隐私保护的角度来看，这是说明性做法。不要只是点击 “接受”或 Cookie 警告或隐私权政策；为自己设置使用自己的服务的任务不披露任何个人信息或设置任何跟踪 Cookie，看看您能否做到，以及这方面的难易程度。另外，您也可以在浏览器开发者工具中查看访问的对象，了解网站正在访问哪些网站，以及传递到这些网站。开发者工具会提供一系列单独的 HTTP 请求（通常位于“网络”部分），您可以看到按类型（HTML、CSS、图片、字体、JavaScript、由 JavaScript 发起的请求）分组的请求。您还有可能添加一个新列来显示每个请求的域，从而显示所联系的不同地点的数量并且可能存在“第三方请求”复选框，仅显示第三方。（使用 Content-Security-Policy 以执行持续的审核，详情请见下文。）

Simon Hearne 的“请求地图生成器”工具也有助于您了解可公开访问的网页发出的子请求。

此时，您可以在非技术审核中包含被认定为以业务为中心的第三方（即，您为使用其资源而与贵公司有财务关系的公司的列表）。这里的目标是将您认为自己使用的第三方列表（来自财务和法律记录）与您实际使用的第三方列表（通过查看您的网站发出的第三方 HTTP 请求）。您应该能够明确是提出技术性出站请求的一方。如果您在针对第三方的技术审核中未发现相应要求业务关系所确定的，则务必要找出原因，并依据该因素进行测试：或许是该第三方资源仅在特定国家/地区、特定设备类型或为已登录用户加载。这会放大您的要审核的网站区域列表，并确保您看到了所有出站访问。（也可能识别第三方这总能让财务部门振奋不已。）

对您希望参与审核的第三方请求列表缩小范围后，点击则会显示该请求的所有详情，特别是系统向相应请求传递了哪些数据。此外，您的代码发出的第三方请求随后会发起许多其他第三方请求。这些其他第三方也会被“导入”嵌入您自己的隐私权政策中。这项任务虽然费力但很有价值通常可以引入到现有的分析中；您的前端开发团队应该已经在审核性能原因（可能借助 WebPageTest 或 Lighthouse 等现有工具），并将数据和隐私权审核，可以简化流程。

web.dev 请求映射。 — 一个（大幅简化的）web.dev 请求映射，显示请求其他第三方网站的第三方网站，等等。

正确做法

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

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

在执行以上每项任务时，请在“网络”面板上记录从他人网域请求的资源如此处所述。这些是部分第三方。要实现这一目的，一个较好方法是使用浏览器的网络工具来捕获请求日志存储到 HAR 文件中

HAR 文件和捕获

HAR 文件是由网页发出的所有网络请求的标准化 JSON 格式。如需获取特定网页的 HAR 文件，请使用以下代码：

Chrome

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

Firefox

打开浏览器开发者工具（菜单 > 更多工具 > Web 开发者工具），转到“网络”面板，加载（或刷新）相应页面，然后选择右上角“限制”下拉菜单旁边的齿轮图标。在菜单中，选择 Save All As HAR**。

Safari

打开浏览器开发者工具（依次选择菜单 > 开发 > 显示 Web 检查器；如果您没有看到“开发”菜单，请从以下位置启用该菜单： 菜单 >Safari >偏好设置 >高级 >在菜单栏中显示“开发”菜单），前往“网络”面板，加载（或刷新）页面，然后选择右上角的导出（位于“保留日志”右侧；您可能需要放大该窗口）。

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

集成第三方时的最佳做法

您可以自行设置有关您网站使用哪些第三方的政策：根据相关做法更改您使用的广告提供商；或 Cookie 意见征求弹出式窗口的烦人或侵扰性，或者您是想在自己的网站上使用社交媒体按钮，还是跟踪链接，或者在 Google Analytics 中跟踪的 utm_campaign 链接。何时需要考虑一个方面是分析服务的隐私和安全状况。某些分析服务明确支持能够保护隐私通常，还有一些方法使用第三方脚本，它本身就具有隐私保护功能：您并不是第一个寻求改善用户使用体验的团队，保护其免受第三方数据收集的侵扰，可能已经是解决方案。最后，与过去相比，许多第三方提供商对数据收集问题更为敏感，通常您还可以添加一些功能或参数，启用对用户保护力度更高的模式。以下是一些示例。

添加社交媒体分享按钮时

考虑直接嵌入 HTML 按钮：网站 https://sharingbuttons.io/ 提供了一些精心设计的示例。或者，您可以添加纯 HTML 链接。需要权衡的是，您失去了“分享次数”以及您对客户进行分类的能力添加到 Facebook Analytics 中此示例展示了使用第三方提供商与接收较少分析数据之间的权衡取舍。

更笼统地说，当您嵌入来自第三方的某种交互式微件时，通常可以改为提供提供指向该第三方的链接这确实意味着您的网站没有内嵌体验，但这会改变关于共享内容的决定数据。

例如，您可以添加用于 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 就没有办法在不跟踪的情况下嵌入视频。您可以自行托管视频（这种方法使用替代方法），但可以是工作量要大很多，尤其是要支持许多设备。

与前面讨论的交互式微件一样，您通常可以用指向提供网站的链接替换嵌入的视频。这样做的交互性较差，因为视频不会内嵌播放，而是让用户选择是否观看。可以是用作“立面模式”的示例，此名称用于将交互式内容动态替换为需要用户操作来触发它。您可以将嵌入的 TikTok 视频替换为指向 TikTok 视频页面的普通链接，但可以检索并显示视频的缩略图，并将其设为链接。即使所选视频提供商支持在不跟踪的情况下轻松嵌入视频，但许多视频托管商都支持 oEmbed，该 API 在给定指向视频或嵌入式内容的链接，系统会返回其程序化详情，包括缩略图和标题。TikTok 支持 oEmbed （如需了解详情，请参阅 https://developers.tiktok.com/doc/embed-videos），这意味着你可以（手动或以编程方式）使用https://www.tiktok.com/@scout2015/video/6718335390845095173 https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173，从而检索缩略图要显示的内容。WordPress 经常使用它来请求 oEmbed”。嵌入内容的信息。您可以通过编程方式使用此 ID 用于显示“ Facade”此类广告会在用户选择点击时切换为嵌入或链接到互动视频。

嵌入分析脚本时

Google Analytics 用于收集有关您用户的信息，以便进行分析，这就是它的用途。从本质上讲，Google Analytics 服务来收集和显示有关访问和用户的数据，为方便起见，可在 Google Analytics 等第三方服务器上完成实施过程。还有一些自托管的分析系统，例如 https://matomo.org/，不过这比使用第三方解决方案不过，在您自己的基础架构上运行此类系统确实有助于减少数据收集。因为它并没有离开你自己的生态系统另一方面，管理、移除这些数据以及为这些数据设置政策也应自行承担责任有关跨网站跟踪的主要问题在于，或者作为使用完全不需要收集数据的服务所带来的副作用。分析软件公开旨在收集数据，以将相关信息告知网站所有者。

从历史上讲，有一种方法可以尽可能多地收集与所有一切有关的数据，比如巨大的渔网，然后再进行分析，看看有没有有趣的模式。这种心态在很大程度上导致了不安和不安感讨论的数据收集行为。现在，许多网站会先确定要询问哪些问题然后收集具体且有限的数据来回答这些问题。

如果您的网站和其他网站都在使用某些第三方服务，而您只要将相关第三方的 JavaScript 代码添加到网站中，就可以使用该服务，并为每个用户设置 Cookie，那么请务必考虑到他们可能会进行不必要的跨网站识别；即跨网站跟踪用户有的不一定，但保护隐私的立场是，此类第三方服务实际上在进行跨网站跟踪，除非您有充分的理由考虑或知道其他情况。这本身并不是避免使用此类服务的理由，但您在评估权衡时需要考虑这一点使用起来非常困难

分析中的权衡曾经仅用来选择是否使用它：收集所有数据和侵犯隐私作为交换。获取数据洞见并进行规划，或者完全放弃数据洞见。不过，现在的情况不再是这样在这两个极端之间找到平衡点。请查看您的分析提供程序，了解要限制的配置选项并缩短其存储量和存储时长。由于您有技术审计记录您可以重新运行该审核的相关部分，确认更改这些配置是否会减少收集的数据量如果您正在现有网站上进行这种转换并编写一些可量化的衡量指标例如，Google Analytics 有许多选择启用选项（因此默认处于停用状态）隐私保护功能，其中许多功能可能有助于遵守当地的数据保护法律。设置 Google 时可以考虑的一些选项 Google Analytics 包括将已收集数据的保留期限（管理 > 跟踪信息 > 数据保留）设置低于 26 个月的默认值；以及启用一些技术性更强的解决方案，例如部分 IP 匿名化（请参阅 https://support.google.com/analytics/answer/9019185 了解详情）。

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

到目前为止，我们已经讨论了如何在应用程序设计阶段保护您的用户免受第三方的侵害，同时您需要规划该应用的用途。决定不使用任何第三方是此次规划的一部分和审核使用情况也属于这一类别：关键是做出有关您的隐私保护立场的决策。不过，这些决策从本质上就不是很精细；是选择使用某个特定第三方，还是不选择，这都不是一个微妙的决定。您更有可能希望介于两者之间：需要或计划使用特定的第三方产品，减少任何侵犯隐私权的倾向（无论是有意还是无意）。以下是在“构建时”保护用户的任务：采取保护措施来减少意料之外的伤害。这些都是新的 HTTP 标头，您可以在传送消息时网页，并且会提示或命令用户代理采取某些隐私保护或安全措施。

引荐来源网址政策

正确做法

设置 strict-origin-when-cross-origin 或 noreferrer 政策，以防止其他网站收到 Referer 标头或者当它们作为子资源加载时：

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> 中的元元素为整个 HTML 网页设置引荐来源网址政策： <meta name="referrer" content="same-origin">；如果关注特定的第三方，则还可以设置 referrerpolicy 属性（如 <script>、<a> 或 <iframe>）：<script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

Content-Security-Policy

Content-Security-Policy 标头（通常称为“CSP”）指示可从何处加载外部资源。它主要用于安全目的，用于防范跨站脚本攻击和脚本注入，它还可以限制您选择的第三方可向何处传递数据。

用户体验可能并不理想；如果您的某个第三方脚本开始从则相应请求将被屏蔽，脚本也会失败，而应用也可能会因此失败（或者至少会缩减到其不支持 JavaScript 的回退版本）。当实施 CSP 以确保安全时，这非常有用这是它的常规用途：防范跨站脚本问题（为此，请使用严格的 CSP）。知道网页使用的所有内嵌脚本后，您可以列出这些脚本、计算哈希值或添加随机值（称为“Nonce”），然后将哈希列表添加到内容安全政策中。这会阻止任何不在列表中这需要纳入网站的生产流程中：您网页上的脚本需要添加 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 这两种模型都可以实现相同的目标，但使用起来不会那么复杂目前尚未就绪（或参与其设计并获取帮助！），请访问 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、权限窗口等）。这种情况在目标隐私威胁模型中被定义为“intrusion”。

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

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

此示例允许此页面（“self”）和来自源 example.com 的 <iframe> 使用 navigator.geolocation API 从 JavaScript；它允许此网页及所有子框架使用全屏 API，但禁止任何网页（包括此网页）使用相机读取视频信息的过程如需了解更多详细信息和潜在示例列表。

由 Permissions-Policy 标头处理的功能列表很大，可能会有变动。目前，该列表为请访问 https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md 进行维护。

提示：请注意，Content-Security-Policy 值用英文分号分隔，但 Permissions-Policy 值用英文逗号分隔，并且 Permissions-Policy 值用括号括起来。如需了解详情，请参阅权限政策说明文档。

正确做法

默认情况下，如果浏览器支持 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=()

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

除了“构建时间”和“设计时间”保护措施，还有在“运行”阶段实施的隐私保护，即浏览器中实施的功能来保护用户。这些功能并非您可以直接控制或作为网站使用的功能开发者，它们是产品功能，但是您应该了解，因为您的网站可能会受到这些产品决策的影响。下面举例说明这些浏览器保护机制可能会对您的网站产生哪些影响在继续执行页面设置之前加载某个第三方依赖项，而该第三方依赖项根本不加载，则您的页面设置可能永远不会完成，因此系统会向用户展示半加载的网页。

包括 Safari 中的智能反跟踪功能（以及底层 WebKit 引擎）和增强型跟踪保护。这些都会导致第三方难以建立用户的详细资料。

浏览器对隐私保护功能的处理方法会经常变化，因此请务必保持最新状态；保护级别在撰写时是否正确无误。浏览器可能还会实施其他保护措施；这些列表并未列出所有情况。请参阅“最佳实践”单元了解及时掌握最新变化的方法，请务必使用即将推出的浏览器版本进行测试，找出可能影响您项目的更改。请注意，无痕模式/无痕浏览模式有时会采用与浏览器默认设置不同的设置（第三方 Cookie 可能会被阻止）即默认在此类模式下使用）。因此，在无痕模式下进行测试可能并不总能反映大多数用户的典型浏览体验使用的不是无痕浏览模式另请注意，在不同情况下阻止 Cookie 可能意味着其他存储解决方案（例如 window.localStorage）不仅会屏蔽 Cookie

Chrome

我们计划在将来阻止第三方 Cookie。截至撰写本文时，默认情况下，它们不会被屏蔽（但用户可以启用）：https://support.google.com/chrome/answer/95647 解释了详细信息。
Chrome 的隐私保护功能，尤其是 Chrome 中与 Google 和第三方服务进行通信的功能； privacysandbox.com/ 上提供了详细的应用说明。

Edge

默认情况下，系统不会屏蔽第三方 Cookie（但用户可以启用这些 Cookie）。
Edge 的阻止跟踪功能块系统会默认阻止来自未访问过的网站的跟踪器和已知有害跟踪器。

Firefox

默认情况下，系统不会屏蔽第三方 Cookie（但用户可以启用这些 Cookie）。
默认情况下，Firefox 的增强型跟踪保护会屏蔽 Cookie 数字“指纹”收集脚本、Cryptominer 脚本和已知跟踪器。(https://support.mozilla.org/kb/trackers-and-scripts-firefox-blocks-enhanced-track 提供更多详细信息）。
第三方 Cookie 是受网站限制的，因此每个网站实质上都有一个单独的 Cookie 罐，并且无法相互关联网站（Mozilla 将这种机制称为“全面 Cookie 保护”）。

若要了解具体内容可能遭到阻止并帮助调试问题，请点击地址栏中的盾牌图标，或在桌面版 Firefox 中访问 about:protections。

Safari

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

（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 逐步淘汰和数字“指纹”收集减少，开发者需要专门构建的 API 符合相关用例（尚未停用）但设计时注重隐私保护的方式。我们的目标是不能用于跨网站跟踪的 API。与上一部分介绍的浏览器功能不同，这些技术成为跨浏览器 API。

API 提案示例

以下列表并不详尽，仅列出了所讨论的一些内容。

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

身份用例：FedCM
广告用例：私下竞价衡量、可互操作的私有归因 Attribution Reporting、Topics、 FLEDGE、PARAKEET。

旨在取代被动跟踪技术的 API 提案示例：

欺诈检测用例：信任令牌。

下面列举了其他 API 将来不使用第三方 Cookie 时也可用作基础的其他提案：

Storage Access API

此外，另一种类型的 API 方案正在兴起，旨在尝试实现迄今为止特定于浏览器的隐蔽跟踪缓解措施。例如隐私预算。通过这些用例，而 Chrome 最初提出的 API 则归在 Privacy Sandbox 的总称下。

Global-Privacy-Control 是一个标头，旨在向用户表明希望不与其他网站分享收集的所有个人数据。其用途与已停用的“Do Not Track”类似。

API 提案的状态

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

这个公开孵化阶段非常重要：浏览器供应商和开发者会就这些 API 是否是否切实有用，以及是否确实实现了预期的目标。开发者、浏览器供应商和其他生态系统参与者使用此阶段对 API 的设计进行反复改进

如果您想及时了解新提议的 API，最好查看目前 GitHub 上的 Privacy Group 提案列表。

您是否需要使用这些 API？

如果您的产品是直接基于第三方 Cookie 或数字“指纹”收集等技术构建的，那么您应该参与这些新 API 的实验，并在相关讨论和 API 设计中贡献您自己的经验。在所有其他情况下，您不一定需要在撰写本文时了解这些新 API 的所有细节，但最好了解一下即将发生的变化。