没有可怕的饼干

饼干最好是现烤现吃，那么有哪些最新食谱可以确保您在万圣节期间也能吃到新鲜的饼干？

饼干最好是新鲜的，那么有哪些最新食谱可以确保您在万圣节期间也能吃到新鲜的饼干？

我们正在逐步在网络平台上淘汰第三方 Cookie。这是在解决跨网站跟踪问题方面取得的一个重要里程碑，但这只是一个漫长征程的一部分。我们来看看我们取得了哪些成就，以及未来还有哪些精彩内容…

从表面上看，Cookie 提供了一个简单的键值对存储，在浏览器和服务器之间发送。这可以在网站上提供实用功能，例如保存偏好设置：theme=bats 或存储已登录用户的会话 ID。

携带简单值（例如 theme=bats 或 fav_pumpkins=us-nyc）的第三方 Cookie

如果该 Cookie 在设置它的网站上使用，我们通常将其称为第一方 Cookie。如果 Cookie 是在设置它的网站之外的其他网站中使用，我们称之为第三方 Cookie。例如，如果我访问的是设置了 theme=bats Cookie 的同一网站，则该 Cookie 就是第一方 Cookie；但如果该 Cookie 包含在 iframe 或其他跨网站资源中，并且是其他网站的一部分，则它就是第三方 Cookie。

第三方 Cookie 的问题在于，它们可以启用跨网站跟踪。共享服务可能会在其中存储整个标识符，而不是设置主题之类的内容。然后，当您浏览包含共享服务 Cookie 的不同网站时，系统会发送同一标识符，这意味着一项服务可以观察和关联您在这些网站上的活动。

包含唯一 ID 的第三方 Cookie，可让第三方网站在网络上跟踪用户

默认允许第一方 Cookie

我们已经取得了一些进展！以前，只需设置一个普通 Cookie：theme=pumpkins 就会在所有情境（同一网站或跨网站）中发送！大多数网站只希望在同一网站情境中发送 Cookie。您可以通过 Cookie 上的 SameSite 属性控制此行为。例如：

Set-Cookie: theme=bats; SameSite=Lax

这会告知浏览器仅在资源与顶级网站匹配时发送 Cookie。不过，这意味着网站必须指定何时需要第一方 Cookie。从安全角度来看，这种做法有点过时，因为您应该在需要更多权限时申请，而不是默认获得。

因此，现在默认值为 SameSite=Lax。如果您仅设置 theme=bats，则该 Cookie 只会在同一网站上下文中发送。

默认的 SameSite=Lax 值会阻止在第三方环境中发送 Cookie

如果您想要使用跨网站 Cookie 或第三方 Cookie（可能需要在嵌入的 widget 中显示主题），则需要指定：

Set-Cookie: theme=bats; SameSite=None; Secure
显式 SameSite=None 值会将 Cookie 标记为要在跨网站上下文中发送

这会告知浏览器您希望在任何跨站上下文中发送 Cookie，但我们确实希望仅限于安全连接。

更美味的第一方 Cookie

虽然默认算法确实有所改进，但您仍有机会改进该算法。下面是一个简短的演示：

Set-Cookie:  __Host-theme=bats;
  Secure;
  Path=/;
  HttpOnly;
  Max-Age=7776000;
  SameSite=Lax;

这样，您将获得一个仅限于一个网域的第一方 Cookie，该 Cookie 会使用安全连接，不允许 JavaScript 访问，会在过期之前自动过期，并且（当然！）仅允许在同网站环境中使用。

使用 CHIPS 制作的饼干更美味！

网络的神奇之处之一在于能够将多个网站组合在一起。假设我想创建一个地图微件，让其他网站显示最佳南瓜园之旅或万圣节糖果巡游路线。我的服务使用 Cookie 让用户存储其在路线上的进度。问题在于，同一第三方 Cookie 将在南瓜园网站和万圣节活动网站上发送。我不想跟踪用户在不同网站之间的活动，但浏览器只使用一个 Cookie 存储分区，我无法将其分开使用！

设置为 SameSite=None 的跨网站 Cookie 仍会全部放入共享 Cookie 存储区

这时，具有独立分区状态的 Cookie（即 CHIPS）提案就派上用场了。每个顶级网站都有一个单独的分区 Cookie Jar，而不是一个共享的 Cookie Jar。网站可以通过在其 Cookie 中使用 Partitioned 属性来选择启用该功能。

Set-Cookie: __Host-route=123;
  SameSite=None;
  Secure;
  Path=/;
  Partitioned;
Cookie 上的 Partitioned 属性会为每个顶级网站创建单独的 Cookie Jar

每个人都有自己的 Cookie Jar，无需共用！更简单、更安全、更卫生。

我们刚刚在 Chrome 109 中发送了具有独立分区状态的 Cookie (CHIPS) 的发布 intent，这意味着它们将于 12 月在 Beta 版中提供测试，并于 2023 年 1 月在稳定版中推出。因此，如果您希望在新的一年里做出改进网站 Cookie 食谱的决心，不妨看看能否开始在跨网站 Cookie 中添加 CHIPS！

使用 First-Party Sets 邀请 Cookie 加入派对

在开发者反馈方面，许多开发者也明确指出，在某些情况下，您会在自己控制的网站之间共享服务，并希望能够在这些网站上使用 Cookie，但不希望在真正的第三方环境中发送这些 Cookie。例如，您可能有 pretty-pumpkins.com 和 pretty-pumpkins.co.uk。您可能拥有一个可在这些网站上使用的基于 Cookie 的单点登录系统。CHIPS 不起作用，因为我只需在两个网站上登录即可 - 要求是这些相关网站需要使用相同的 Cookie。

我们正在研究 First-Party Sets 提案，希望能够实现这一点。我们已完成一次源代码试用和大量社区讨论，最终推出了最新版本，旨在：

  • 让组织能够定义一组应属于同一方位的网站。
  • 利用 Storage Access API 请求对该第一方组合内跨网站 Cookie 的访问权限。
第一方组仅允许在相关网站之间共享 Cookie Jar

这些 Cookie 仍在不断完善中，但您可以随时查看第一方 Cookie 组开发者指南，了解有哪些新内容可供测试；如果您想参与讨论，也可以直接查看 WICG/first-party-sets 提案。

不要让 Cookie 过期！

我们的目标是从 2024 年年中开始在 Chrome 中逐步停止支持第三方 Cookie。虽然还有时间做好准备，但您应该立即开始规划。

  1. 使用 SameSite=None 审核您的代码是否包含任何 Cookie。以下是需要更新的 Cookie。
  2. 如果您没有任何第三方 Cookie，请确保您的同网站 Cookie 采用了最佳第一方 Cookie 方案
  3. 如果您在完全封闭的嵌入式环境中使用这些 Cookie，请研究和测试 CHIPS 提案。
  4. 如果您需要将来自多个网站的这些 Cookie 组合成一个紧密的群组，请研究第一方 Cookie 组提案。
  5. 如果这两种方法都不适用于您，则需要研究其他 Privacy Sandbox 提案，我们正在为不依赖于跨网站跟踪的个别用例开发专用 API。

以上只是简要概述，我们会在工作进展过程中继续分享更多相关资讯和指南。如果您有疑问、问题或想分享自己的工作成果，可以通过多种方式与我们联系。

因此，请记住：Cookie 虽然很美味，但一次只能吃几个，绝对不能偷别人的！