没有可怕的饼干

饼干是最新鲜的,那么,为了不让过期饼干,你仍能畅享恐怖的假日时光,最新的食谱是什么呢?

饼干是最新鲜的,那么最新的食谱都有哪些 享受没有过期饼干的恐怖季?

我们正在逐步淘汰整个网络中的第三方 Cookie 平台。这是实施跨网站跟踪的重要里程碑, 这是漫长旅程中不可或缺的一环我们来看看我们已经取得的成果 以后还会上架零食...

从表面上看,Cookie 提供了一个简单的键值对存储,用于在 浏览器和服务器之间的通信。这样就能在网站上提供实用功能,比如 保存偏好设置 theme=bats,或存储已登录账号的会话 ID 用户。

带有简单值(例如 theme=bats 或 fav_pumpkins=us-nyc)的第三方 Cookie

如果设置该 Cookie 的网站也在使用 Cookie,我们倾向于调用 第一方 Cookie如果该广告素材还用于其他网站的一部分 我们称之为第三方 Cookie例如,我的 theme=bats Cookie 是第一方 Cookie, ,但如果作为 则可能是第三方 Cookie。

第三方 Cookie 的问题在于它们可以跨网站 跟踪。共享服务可能不会设置主题之类的内容, 将整个标识符存储在其中。之后,当您请求用户付款时 可以浏览包含共享服务 Cookie(即 意味着一项服务可以观察并关联您在这些网站上的活动。

带有唯一 ID 的第三方 Cookie,该 ID 可让第三方网站跟踪网络上的用户

默认使用第一方 Cookie

我们已经在这里的旅程取得了进展!以前只需要设置 普通 Cookie:theme=pumpkins 会在所有上下文中发送:相同网站或 跨网站!大多数网站只希望在 同一网站的内容。这可以通过SameSite Cookie。例如:

Set-Cookie: theme=bats; SameSite=Lax

这将指示浏览器仅当资源与 顶级网站。不过,这意味着网站必须指定其何时 第一方 Cookie。从安全角度来讲,这有点倒退 都应该询问您是否需要更多权限,而不仅仅是通过 默认值。

现在,SameSite=Lax 是默认值。如果您仅设置theme=bats 在同一网站的上下文中发送。

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

如果您想使用跨网站或第三方 Cookie(也许您需要 显示在嵌入式微件中),则需要指定:

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 安全连接、JavaScript 访问,会在过期前自动过期 会过时,而且(当然!)仅允许在同一网站的上下文中使用。

饼干加 CHIPS 可口味!

Web 神奇的一面是能够构建多个网站 。假设我想创建一个地图微件 最佳南瓜园游览路线或“不给糖就捣蛋”路线。我的服务使用 Cookie 让用户存储其沿途的进度。问题是, 第三方 Cookie 会发送到南瓜园网站, 不给糖就捣蛋的网站。我不想跟踪网站之间的用户, 浏览器只使用一个 Cookie 罐,我无法单独使用以下 Cookie!

采用 SameSite=None 的跨网站 Cookie 仍然会放入共享 Cookie 罐

这时,具有独立分区状态的 Cookie(简称 CHIPS) 都会收到提案我们不再使用一个共享 Cookie 罐 每个顶级网站的每个分区 Cookie jar 数。网站可以使用 Partitioned 属性。

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

再也不需要共享这个饼干罐了,每个人都会获得自己的专属饼干!更简单、 更安全、更卫生。

我们刚刚将 Intent 发送到 配送 适用于具有独立分区状态的 Cookie (CHIPS),这意味着它们将 可于 12 月推出 Beta 版,并于 2023 年 1 月推出稳定版。 如果您正在为提高网站 Cookie 质量而制定新年计划 然后看看食谱,看看是否可以开始 跨网站 Cookie!

使用 First-Party Set 邀请 Cookie 参加派对

关于开发者反馈,很多开发者都明确表示, 也就是您跨自己控制的多个网站共享服务 可以在这些服务之间使用 Cookie - 但不允许通过真正的第三方发送 上下文。例如,假设您有 pretty-pumpkins.compretty-pumpkins.co.uk。您可能有一个基于 Cookie 的单点登录系统 可以跨这些网站运行因为我只能 在这两个网站上登录—但我需要在整个 这些相关网站。

我们正在努力实现 First-Party Set 提案。 我们经历了一次源试用和大量的社区讨论, 推出了最新版本,该版本旨在:

  • 让组织可以定义一组应符合以下要求的网站: 相互访问。
  • 利用 Storage Access API 请求对跨网站 Cookie 的访问权限 所有广告资源
First-Party Set 仅允许在相关网站之间使用共享的 Cookie 罐

这些饼干还在烤箱里烘烤 First-Party Set 开发者指南 还有很多内容有待测试 WICG/first-party-sets 提案: 您愿意参与讨论。

别让您的 Cookie 失效!

我们的目标是开始逐步取消 Chrome 对第三方 Cookie 的支持,即从 2024 年年中。您已经有时间做好准备,但现在就应该开始规划了。

  1. 使用 SameSite=None 审核您的代码是否存在任何 Cookie。这些是 需要更新的应用
  2. 如果您没有任何第三方 Cookie,请确保您的同网站 Cookie 使用最佳第一方 Cookie 食谱
  3. 如果你在完全全面的嵌入式环境中使用这些 Cookie, 调查和测试 CHIPS 提案
  4. 如果您需要在多个网站中使用这些 Cookie,形成一个紧密的群组, 然后研究First-Party Set 提案
  5. 如果这两种方法都无法解决,您需要 调查其他 Privacy Sandbox 提案,其中 我们正在为不依赖于 到此结束

这只是一个简短的概述,我们将继续分享更多 提供指导。如果您有任何疑问、问题或想要 分享自己工作的结果,那么我们有很多路线供您选择, 联系

所以请谨记:饼干可能很美味,但一次只有几个,而且绝对是 不要试图窃取别人的东西!