【Web技术】没有诡异的cookies

饼干最好是新鲜的，那么有什么最新的食谱可以确保你仍然可以在没有任何变质饼干的情况下享受诡异的季节呢？

我们正在逐步淘汰网络平台上的第三方cookie。这是解决跨站点跟踪问题的一个重要里程碑，但这是相当漫长的旅程的一部分。让我们来看看我们已经走了多远，未来会有什么美食…

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

带有简单值的第三方cookie，如theme=bats或fav_pumpkins=us nyc

如果该cookie在设置它的同一个网站上使用，那么我们倾向于将其称为第一方cookie。如果它被用作不同于设置它的网站的一部分，我们称之为第三方cookie。例如，如果我访问设置它的同一个网站，我的theme=bats将是第一方，但如果它作为不同网站的一部分包含在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，它将只在同一个站点上下文中发送。

默认的SameSite=Lax值停止在第三方上下文中发送cookie
如果你想要一个跨站点或第三方cookie（也许你需要在嵌入式小部件中显示主题），那么你需要指定：

Set-Cookie: theme=bats; SameSite=None; Secure

显式SameSite=None值标记要在跨站点上下文中发送的cookie
这告诉浏览器您希望在任何跨站点上下文中发送cookie，但我们确实希望仅限于安全连接。

更美味的第一方cookies

虽然默认设置确实有所改善，但仍有改进的空间。以下是快速品尝：

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

这将为您提供一个第一方cookie，该cookie仅限于一个域，安全连接，不受JavaScript访问，在过期前自动过期，并且（当然！）只允许在相同的网站上下文中使用。

注意：阅读更多：你可以做很多调整来适应你的口味，我们在第一方饼干食谱中提供了所有细节。

饼干(cookie)加薯片(CHIPS)味道更好！

网络的神奇之处之一是能够将多个网站组合在一起。比方说，我想创建一个地图小部件，让其他网站显示最好的南瓜地之旅或不给糖就捣蛋的路线。我的服务使用cookie让用户存储他们在路线上的进度。问题是，同样的第三方cookie将在南瓜补丁网站上发送，就像在“不给糖就捣蛋”网站上发送一样。我不想在网站之间跟踪用户，但浏览器只使用一个cookie罐——我无法将其使用情况分开！

SameSite的跨站点cookie=none ,一个仍然全部进入共享cookie罐
这就是Cookies Having Independent Partitioned State，简称CHIPS提案的用武之地。每个顶级网站都有一个单独的分区cookie罐，而不是一个共享的cookie罐。网站会通过在其cookie上使用Partitioned属性来选择加入。

Set-Cookie: __Host-route=123;
  SameSite=None;
  Secure;
  Path=/;
  Partitioned;

cookie上的Partitioned属性为每个顶级站点创建单独的cookie jar
每个人都有自己的饼干罐，而不是共享饼干罐！更简单、更安全、更卫生。

我们刚刚发送了Chrome 109中具有独立分区状态（CHIPS）的Cookie的发货意向，这意味着它们将在12月进行测试，然后在2023年1月进行稳定测试。所以，如果你正在寻找一个新的新年决心来改进你的网站的饼干配方，那么看看你是否可以开始在这些跨网站的饼干中撒芯片！

用第一方套装邀请cookie参加派对

关于开发人员的反馈，你们中的许多人还明确表示，在某些情况下，您可以在您控制的网站之间共享服务，并希望能够在这些网站之间使用cookie，但不允许在真正的第三方环境中发送。例如，也许你有pretty-pumpkins.com和pretty-umpkins.co.uk。你可能有一个基于cookie的单点登录系统，可以在这些网站上运行。CHIPS不起作用，因为我只需要在两个网站上登录——要求是我需要在这些相关网站上使用相同的cookie。

我们正在制定第一方方案，试图使之成为可能。我们已经进行了一次起源试验和大量的社区讨论，这使我们得出了最新版本，旨在：

• 为组织提供一种定义一组站点的方法，这些站点应该是彼此相同的一方。
• 利用Storage Access API请求访问该第一方集中的跨站点cookie。

第一方集只允许在相关网站之间共享cookie罐

这些饼干仍在烤箱中烘烤，但当有更多内容需要测试时，您可以查看《第一方集合开发者指南》，如果您想参与讨论，也可以加入WICG/第一方套装提案。

不要让你的饼干变质！

我们的目标是从2024年中期开始逐步取消对Chrome中第三方cookie的支持。有时间准备，但你现在应该开始计划。

1. 使用SameSite=None审核代码中的任何cookie。这些是需要更新的cookie。
2. 如果您没有任何第三方cookie，请确保您的同一网站cookie使用最佳的第一方cookie配方
3. 如果您在完全包含的嵌入式上下文中使用这些cookie，则调查并测试CHIPS提案。
4. 如果你需要在多个网站上使用这些cookie，形成一个有凝聚力的小组，那么请调查第一方集合方案。
5. 如果您不在这两个选项中，您将需要调查其他隐私沙盒提案，我们正在为不依赖跨站点跟踪的个别用例开发专门构建的API。

这只是一个简短的概述，随着工作的进展，我们将继续分享更多的新闻和指导。如果您有问题、问题或想分享自己的工作成果，我们有很多途径供您联系。

所以，请记住：饼干可能很美味，但一次只能吃几块，绝对不要试图偷别人的！