没有可怕的饼干

饼干最好是新鲜的，那么，怎样才能不吃过时的饼干，也能继续享受恐怖的恐怖季节呢？那么，有哪些最新的食谱呢？

饼干最好是新鲜的，那么，怎样才能不吃过时的饼干也能享受恐怖的恐怖季节呢？那么，有哪些最新的食谱呢？

我们正在逐步淘汰整个网络平台上的第三方 Cookie。这是解决跨网站跟踪问题的一个主要里程碑，但只是很长一段时间的一部分。让我们来了解一下我们的成果 以及未来将推出哪些美食...

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

如果该 Cookie 是在设置它的同一网站上使用，我们倾向于将其称为第一方 Cookie。如果 Cookie 是作为一个网站的一部分（而非设置它的网站）的一部分，我们称之为第三方 Cookie。例如，如果我访问设置该 Cookie 的同一网站，我的 theme=bats Cookie 将是第一方 Cookie，但如果作为其他网站的一部分包含在 iframe 或其他跨网站资源中，则该 Cookie 是第三方 Cookie。

注意：注意：第一方或第三方都与同网站或跨网站情境相关！

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

默认使用第一方 Cookie

我们在这方面已经取得了进展！过去只需设置一个普通的 Cookie：theme=pumpkins 会在所有上下文（同网站或跨网站）中发送！大多数网站都只希望在同网站环境中发送其 Cookie。这可通过 Cookie 上的 SameSite 属性进行控制。例如：

Set-Cookie: theme=bats; SameSite=Lax

这会告知浏览器仅在资源与顶级网站匹配时才发送 Cookie。不过，这意味着网站必须指定第一方 Cookie 的时间。这在安全术语方面有点倒退，因为在需要更多权限时，实际上是应该询问更多权限，而不只是默认获取权限。

因此，现在 SameSite=Lax 是默认值。如果仅设置 theme=bats，系统只会在同一网站环境中发送它。

如果您希望使用跨网站或第三方 Cookie（或许您需要让主题显示在嵌入式 widget 中），则需要指定：

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

这会告知浏览器您希望在任何跨网站环境中发送 Cookie，但确实希望仅限于安全连接。

更美味的第一方饼干

虽然默认的设置确实得到了改进，但该食谱仍有改进的空间。不妨先简单了解一下：

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

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

注意：了解详情：您可以按照自己的喜好进行很多调整，详情请参阅我们的第一方饼干食谱。

饼干用条状标签制作更美味！

网络有一个神奇的方面之一，就是能够整合多个网站。假设我想创建一个地图 widget，以便其他网站显示最佳南瓜园游览或“不给糖就捣蛋”路线。我的服务使用 Cookie 来允许用户在路线上存储他们的进度。问题在于，南瓜补丁网站上会像在“不给糖就捣蛋”网站上发送相同的第三方 Cookie。我不想在网站之间跟踪用户，但浏览器只使用了一个 Cookie jar，我无法区分使用情况！

这正是具有独立分区状态 (CHIPS) 的 Cookie 提案的用武之地。每个顶级网站都有一个单独的分区 Cookie JAR，而不是一个共享 Cookie jar。网站可通过其 Cookie 中的 Partitioned 属性来选择启用该设置。

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

不必分享 Cookie 罐，每个人都可以拥有自己的！更简单、更安全、更健康。

我们刚刚在 Chrome 109 中针对具有独立分区状态 (CHIPS) 的 Cookie 发送了发送意向，这意味着这些 Cookie 将于 12 月进入 Beta 版测试阶段，并于 2023 年 1 月准备好进入稳定版。因此，如果您想要制定新年计划来改进网站的饼干配方，不妨看看能否开始在这些跨网站 Cookie 中撒点 CHIPS！

使用 First-Party Set 邀请 Cookie 加入相关方

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

我们正在制定 First-Party Set 提案，力求实现这一目标。 我们经历了一次源试用和大量的社区讨论，这使我们能够进行以下更新的最新版本：

• 让组织能够定义一组彼此应属于同一方的网站。
• 利用 Storage Access API 请求访问该第一方集合内的跨网站 Cookie。

这些 Cookie 仍在烤箱中烘焙，但如需测试更多内容，请查看 First-Party Set 开发者指南；如果您想参与讨论，也可以直接参与 WICG/first-party-sets 提案。

不要让饼干过时！

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

1. 使用 SameSite=None 审核您的代码中是否有任何 Cookie。这些是需要更新的 Cookie。
2. 如果您没有第三方 Cookie，请确保您的同网站 Cookie 使用的是最佳第一方 Cookie 配方。
3. 如果您在完全封闭的嵌入式上下文中使用这些 Cookie，请调查并测试 CHIPS 方案。
4. 如果您需要让这些 Cookie 跨越多个网站，形成一个统一的群组，请研究 First-Party Set 提案。
5. 如果上述任一方案都不涵盖您，您将需要研究其他 Privacy Sandbox 提案，我们在这些提案中正在为不依赖跨网站跟踪的个别用例开发专用 API。

这只是一个简短的概述，随着工作的推进，我们会继续分享更多资讯和指导。如果您有任何疑问、问题或想要分享自己的工作成果，我们提供多种途径供您与我们联系。

因此，请记住：饼干很美味，但一次只能几个，绝对不会试图窃取别人的！