Google 的 AMP 项目全球产品负责人 Katharina Familia Almonte 发布
去年，Chrome 宣布其计划引入 Cookie 分类方案，作为其持续改善网络隐私和安全性的努力的一部分，该计划预计将于 2020 年 2 月随 Chrome 80 生效。Mozilla 已确认他们支持新的 Cookie 分类模型，并 打算实施 Firefox 中跨站点 Cookie 的 SameSite=None；安全要求。Microsoft 已 宣布计划开始实施该模型，并最早在 Microsoft Edge 80 中作为一项实验进行。
AMP 团队致力于保护用户隐私，这篇博文将解释在即将进行的浏览器更改中，您如何支持更高的透明度和用户选择，同时还保持 AMP 的良好用户体验。由于 Chrome 80 预计将于 2 月发布，这篇博文将重点关注 Chrome 的具体更改。
Chrome 的新 Cookie 设置说明
Chrome 的新的默认安全模型假设所有 Cookie 都应受到外部访问的保护，除非另有说明。开发人员必须使用新的 Cookie 设置 SameSite=None 来指定跨站点访问的 Cookie，以及一个附加的安全属性，以便跨站点 Cookie 只能通过 HTTPS 连接访问。Chrome 将把没有声明的 SameSite 值的 Cookie 视为 SameSite=Lax Cookie。只有带有 SameSite=None；安全设置的 Cookie 可供外部访问，前提是它们是从安全连接访问的。有关新模型的更多详细信息，请阅读 这篇开发者博文。
谁会受到影响
如果您的网站需要访问在 AMP 缓存中呈现的 AMP 页面上的自己的第一方 Cookie，我们建议仔细评估即将进行的浏览器更改是否会影响您的用户体验。例如，当用户从 AMP 缓存转到原始域，而付费墙、登录状态、衡量或购物车功能依赖于第一方 Cookie 访问时，可能会出现这种情况。您可以采用两种不同的解决方案，但哪种解决方案最适合您的网站将取决于您的特定用例，并且可能会随着时间的推移而改变。
指定 Cookie 以实现跨网站访问
受 Chrome 的 Cookie 分类更改影响的 AMP 发布商的一种解决方案是将 AMP 页面上的第一方 Cookie 设置为 SameSite=None；Secure。这将指定第一方 Cookie 用于跨网站访问，并避免用户体验中断
Set-Cookie: widget_session=abc123; SameSite=None; Secure
此方法的优点是它更容易实现，但如果浏览器继续向用户提供细粒度控件，以便分别管理单个网站访问的 Cookie 和跨多个网站访问的 Cookie，那么用户清除缓存的 AMP 页面上的第一方 Cookie 的风险更高，因为它们将被标记为跨网站访问。
Signed Exchange 提供帮助
或者，发布商可以使用 Signed Exchange 来实现一种状态，其中第一方 Cookie 在 AMP 缓存中呈现的 AMP 页面上被视为第一方 Cookie。Signed Exchange 是一种新兴技术，可用于将页面的 URL 归因于原始发布商域，即使该页面是通过 AMP 缓存提供的，并具有其提供的所有加载速度优势（请参阅博客文章和指南）。Signed Exchange 在此处的优点是，当浏览器开始阻止 Cookie 从外部访问（除非另有说明）时，Signed Exchange 将确保您的第一方 Cookie 不需要在 AMP 缓存中呈现的页面上指定。但 Signed Exchange 目前无法解决所有用例，因为在撰写本文时，它不受精选快讯轮播支持。
摘要
总之，Chrome 计划在 2 月份推出其新的 SameSite=None；安全 Cookie 设置。为确保用户在需要访问第一方 Cookie 的 AMP 缓存中的页面上获得最佳用户体验，我们建议发布商通过这些新设置指定 Cookie 以进行跨网站访问，或实施 Signed Exchange。我们希望这篇博文能帮助您在保持良好用户体验的同时，还支持用户获得更出色的隐私控制，因为浏览器已开始采用新的 Cookie 分类模型。有关如何使用和测试 Chrome 的 SameSite Cookie 的更多详细信息，请查看 web.dev 上的指南 和 Chromium SameSite 更新 中的提示。