在设计 AMP HTML JavaScript 库时的早期选择使其在发布者实施有效的用户隐私控制方面独具优势。在网页中，可能对隐私产生影响的资源请求和浏览器存储访问可以通过多种机制启动，其中许多机制通常由第三方控制。这可能使发布者难以确保在获得适当的用户同意之前不会执行任何意外操作。这篇文章探讨了 AMP 中的软件架构，该架构可以帮助发布者有效地实施此类用户选择选项。有关在 AMP 文档中实施用户选择流程的具体步骤，请查看此 博客文章。
保护隐私的预渲染
AMP 与通用 HTML 文档区别开来的关键方式之一是，它内置了保护隐私的预渲染功能。这是实施文档即时加载的用户隐私要求。
即时加载自然需要加载用户可能看到 之前 用户导航到该文档的文档。通过在用户表达意图之前加载它，网络操作可以在用户最终表达意图（例如，通过点击链接）时执行，从而使加载时间更快。
即时加载显然是一种很棒的用户体验，但它确实带来了隐私挑战。如果用户最终没有查看预渲染的文档，那么发布者仍然可能会通过文档的预渲染接收有关用户的信号和信息。这与网络通常的工作方式有所不同，可能不是用户所期望的。出于这个原因，我们设计了 AMP，使其 不会 允许文档发布者知道网页的预渲染正在发生，直到用户表达了实际访问网页的意图。这就是我们所说的保护隐私的预渲染。
保护隐私的预渲染在 AMP 中通过两种协同工作的主要机制实现
- 平台控制的 AMP 缓存，不会向内容发布者公开用户请求数据。
- 一个集中式请求管理器，它控制 AMP 页面上 Web 组件的资源请求的时机和可用性。
让我们更详细地了解第二种机制：每当 AMP 页面加载任何资源（例如图像、视频、广告、分析请求、推文或其他数十种类型的资源）时，相关的网络请求都会由中央资源管理机制控制。除了执行许多其他功能外，此资源管理器还确保在文档生命周期的预渲染阶段不允许的请求会被保留，直到文档了解到用户表达了查看页面的意图。
AMP JS 库中加载资源的过程图。
这是 AMP 的关键架构特性，使其在实施更复杂的隐私控制方面独具优势，这些控制建立在此基本机制之上。
支持用户选择的架构
上一段介绍了 AMP 如何控制资源请求时机以确保在预渲染阶段发出的某些请求仅在用户表达了访问页面的意图后才会真正发出。从软件架构的角度来看，这引入了一种控制请求时机的中央机制，从而可以相对轻松地引入其他规则，包括页面发布者指定的规则，以延迟预渲染特定规则之上的请求。
例如，一个这样的发布者指定的规则可能是延迟 AMP 页面上的任何广告请求，直到发布者获得了足够的同意才能发出此类广告请求或与广告供应商共享与广告相关的数据。
对于每个 AMP Web 组件（例如 amp-ad 和 amp-img 元素），发布者可以指定相关资源应仅在用户提供发布者认为需要加载和显示相应资源的同意时才加载。
确定 AMP JS 库中请求资源流程的过程图。
虽然发布者可能仍然需要对他们在页面上加载的 AMP Web 组件类型进行审核，并确定是否需要任何形式的用户同意才能显示它们，但拥有一个统一的机制来控制可能包含在页面中的所有资源类型的行为——从图像到广告，再到分析——应该使发布者更容易相信他们已将同意处理应用于需要它的所有资源和行为。
这篇文章从软件架构的角度探讨了增强隐私的功能。有关在 AMP 文档中实施用户选择流程的具体步骤，请查看此 博客文章。
作者：Malte Ubl，AMP 项目的技术主管。