[OUTDATED] First-Party Set 和 SameParty 属性

许多组织都有使用不同域名的相关网站,例如 brandx.sitefly-brandx.site,或不同国家/地区的域名,例如 example.comexample.rsexample.co.uk 等。

浏览器越来越倾向于创建第三方 Cookie 已过时 来加强网络隐私保护,但是像这样的网站常常依赖于 Cookie 需要跨域维护和访问状态的功能 (例如单点登录和意见征求管理)。

First-Party Set 可允许由 在第一方和第三方标识符中 系统会以其他方式处理第三方同一个 Pod 中的 第一方组则被视为同一方,它们可以标记哪些 Cookie 在同一方环境中设置或发送。目的是找到 在阻止第三方跨网站跟踪和 维护一个不会破坏有效用例的路径。

First-Party Set 提案目前正在测试中 阶段,请继续阅读下文,了解其运作方式 以及如何试用

第一方 Cookie 和第三方 Cookie 有何区别?

Cookie 本质上不是第一方或第三方,这取决于当前的 包含该 Cookie 的上下文。可以通过 cookie 标头或在 JavaScript 中通过 document.cookie 进行设置。

例如,当您浏览网页时 video.sitetheme=dark Cookie video.site,并且向 video.site同网站)发出请求 上下文和 包含的 Cookie 是第一方

不过,如果您使用的是my-blog.site,它嵌入了 iframe 播放器, video.site(当请求从 my-blog.site 发送到 video.site 时) 即跨网站上下文,而 theme Cookie 则是第三方的 Cookie。

示意图:在两种上下文中显示了来自 video.site 的 Cookie。当顶级上下文也是 video.site 时,此 Cookie 为同一网站。如果顶级上下文是 my-blog.site 并且 iframe 中有 video.site,则该 Cookie 是跨网站 Cookie。

是否包含 Cookie 取决于 Cookie 的 SameSite 属性:

  • 同一网站 有数据来源 SameSite=LaxStrictNone 使 Cookie 成为第一方 Cookie。
  • 使用 SameSite=None跨网站上下文会使 Cookie 成为第三方 Cookie。

然而,这两者之间并非总是一清二楚。假设brandx.site是一个旅游目的地 预订网站,同时还使用fly-brandx.sitedrive-brandx.site 提供独立航班和租车服务在预订一个行程的过程中,访问者 会在这些网站之间自由选择不同的选项 - 他们希望 “购物车”可以将它们应用到这些网站。brandx.site 使用 SameSite=None Cookie 管理用户的会话,以允许 跨网站上下文。但其缺点是,Cookie 现在无法跨网站 请求伪造 (CSRF) 保护。如果 evil.site 包含对 brandx.site,那么它就会包含该 Cookie!

Cookie 是跨网站 Cookie,但所有这些网站 组织。访问者也知道这是同一个组织,并希望 也就是说,他们有着相同的身份

此图显示了在网站属于同一个 First-Party Set 的情况下,Cookie 可能仍会包含在跨网站情境中,但对于该组之外的跨网站情境而言,Cookie 会被拒绝。

First-Party Set 政策

First-Party Set 方法: 方法在多个网站上明确定义这种关系, 均归同一方所有和运营。这会让 brandx.site 能够 定义其与fly-brandx.site的第一方关系, drive-brandx.site 等。

隐私保护模型推动 各种 Privacy Sandbox 提案基于分区的概念, 来阻止跨网站跟踪 - 在网站之间绘制边界 限制对可用于识别用户身份的任何信息的访问权限。

示意图:同一第三方 Cookie 可在多个跨网站环境中访问的未分区状态,这与分区模型(其中每个顶级上下文都有单独的跨网站 Cookie 实例)不同,此状态可防止跨网站进行链接活动。

虽然默认选项是按网站划分,这解决了许多第一方方面的问题 brandx.site 示例显示,第一方受众群体可以 不只是一个网站

显示当所有这些网站都属于同一集合时,如何将一个集合的相同 Cookie 实例包含在跨网站上下文中。

First-Party Set 提案的一个重要部分是确保政策 来防止滥用或误用例如,First-Party Set 不得 允许在不相关网站之间交换用户信息, 不归同一实体所有的网站。这样做是为了确保 First-Party Set 可映射到用户理解为第一方的 不得用作在不同方之间共享身份的方式。

网站注册第一方集合的一种可行方法是 向公开跟踪工具提交他们提议的一组网域(例如 专用的 GitHub 代码库)以及满足浏览器要求所需的信息 政策。

根据政策验证了第一方 set 断言后,浏览器可以 然后通过更新流程提取集合列表。

源试用具有既定的政策(并非最终版本),但原则 可能会保持不变:

  • 第一方集中的网域必须归属于同一个 组织。
  • 这些网域应可作为一个群组供用户识别。
  • 这些域名应采用相同的隐私权政策。

如何定义第一方组合

确定贵组织第一方的成员和所有者后 ,那么关键的一步是提交您提议的训练组以供审批。确切的 过程仍处于讨论阶段。

若要声明第一方集、列出成员和所有者的静态 JSON 资源 应托管在 /.well-known/first-party-set(每个映像的顶层) 包含的网域。

brandx 第一方集的示例中,所有者网域托管了 正在关注 https://brandx.site/.well-known/first-party-set

{
 
"owner": "brandx.site",
 
"version": 1,
 
"members": ["fly-brandx.site", "drive-brandx.site"]
}

该集的每个成员还托管一个指向 该资源集的所有者。 在 https://fly-brandx.site/.well-known/first-party-set,我们有:

{ "owner": "brandx.site" }

https://drive-brandx.site/.well-known/first-party-set 中:

{ "owner": "brandx.site" }

第一方集存在一些限制:

  • 一个资源集只能有一个所有者。
  • 一个成员只能属于一组成员,不能互相重叠或混合。
  • 成员列表旨在保持相对人类的可读性, 过大。

First-Party Set 如何影响 Cookie?

建议 Cookie 的匹配组成部分SameParty 属性。指定 SameParty 当 Cookie 的上下文属于同一上下文时,告知浏览器包含该 Cookie 设置为顶级上下文。

这意味着,如果 brandx.site 设置了此 Cookie,那么:

Set-Cookie: session=123; Secure; SameSite=Lax; SameParty

然后,当访问者访问 fly-brandx.site 时,请求转到 brandx.site,则 session Cookie 将包含在该请求中。 如果某个不属于第一方集合的其他网站 hotel.xyz,则向 brandx.site 发送请求,则 Cookie 不会包含在内。

示意图:说明在跨网站上下文中允许或屏蔽 brandx.site Cookie。

SameParty 获得广泛支持之前,请将 SameSite 属性与其搭配使用, 定义 Cookie 的后备行为您可以将 SameParty 属性提供介于 SameSite=LaxSameSite=None

  • SameSite=Lax; SameParty扩展 Lax 功能, 在受支持的情况下包含同方上下文,但会回退到 Lax 否则就会受到一些限制
  • SameSite=None; SameParty限制 None 功能: 在受支持的情况下,只关注同方环境,但会回退到更广泛的环境 None 权限。

还有一些其他要求:

  • SameParty Cookie 必须包含 Secure
  • SameParty Cookie 不得包含 SameSite=Strict

Secure 是强制性的,因为这仍然是跨网站问题,您应该减少此类问题 确保安全 (HTTPS) 连接,从而降低风险。同样,由于这是 跨网站关系,SameSite=Strict 无效,因为它仍然允许 一组基于网站的 CSRF 保护。

哪些用例适合 First-Party Set?

如果组织需要 在不同顶级网站之间共享的身份。在这种情况下的共享身份 从完整的单点登录解决方案到只需要一个共享的 偏好设置。

贵组织可能针对以下情况具有不同的顶级域名:

  • 应用网域office.comlive.commicrosoft.com
  • 品牌网域amazon.comaudible.com / disney.compixar.com
  • 需要启用本地化功能的特定国家/地区网域google.co.ingoogle.co.uk
  • 用户从不直接与它们互动,但提供的服务网域 同一组织的各个站点上的服务:gstatic.comgithubassets.comfbcdn.net
  • 沙盒网域:用户从不直接与此类网域互动,但 安全原因:googleusercontent.comgithubusercontent.com

你是如何参与的?

如果您有一组符合上述条件的网站 有很多选项需要参与。阅读和加入是最轻松的投资 关于这两项提案的讨论:

在测试阶段,您可以使用 --use-first-party-set 命令行标志并提供以英文逗号分隔的列表 。

您可以在演示版网站上尝试此操作,网址为 启动后访问 https://fps-member1.glitch.me/ 带有以下标志的 Chrome:

--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me

如果您想在开发环境中进行测试,或者想要 请尝试在实际环境中添加 SameParty 属性,看看 第一方设置会影响 Cookie

如果您有充足的精力进行实验和提供反馈,也可以报名 适用于针对 First-Party Set 和 SameParty (在 Chrome 89 至 93 版本中提供)。

如何为源试用更新 Cookie

如果您要加入源试用并测试以下设备上的 SameParty 属性: 则可以考虑以下两种模式

选项 1

首先,您有标记为 SameSite=None 的 Cookie,但 想要限制在第一方环境中,您可以添加 SameParty 属性。在源试用有效的浏览器中,Cookie 将 不会发送到组之外的跨网站上下文中。

不过,对于大部分的 非源试用阶段的浏览器将继续发送 Cookie 会像平常一样跨网站访问可将其视为一种渐进式增强方法。

之前set-cookie: cname=cval; SameSite=None; Secure

之后set-cookie: cname=cval; SameSite=None; Secure; SameParty

选项 2

第二个选项工作量较大,但可让您将源 并且专门用于测试 SameSite=Lax; SameParty 组合。

之前set-cookie: cname=cval; SameSite=None; Secure

之后:

set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty

在传入请求中检查 Cookie 时,应该只会看到 跨网站请求中的 cname-fps Cookie(如果所涉及的网站位于 且浏览器处于源试用阶段。将这种方法视为 同时发布更新版功能,然后再关闭之前的 版本。

为什么您可能不需要第一方组合?

对于大多数网站,可以用其网站边界来绘制 是分区或隐私边界。这是建议采用的路线 CHIPS(具有独立分区的 Cookie) State),以便网站可以选择是否启用此功能 通过 Partitioned 属性添加路由,使其仍然具有那些重要的跨网站 嵌入、资源、API 和服务,同时防止识别 提供跨网站信息

此外,还需要考虑一些其他注意事项 集:

  • 您托管在不同的源站,而不是不同的网站。在上面的示例中, 如果 brandx.sitefly.brandx.sitedrive.brandx.site,则这些 是同一网站内的不同子网域。Cookie 可以使用 SameSite=Lax,无需进行任何设置。
  • 您向其他网站提供第三方嵌入内容。在片头中, my-blog.site上嵌入的video.site的视频明显属于第三方 除法运算。这些网站由不同的组织运营,用户会看到它们 视为单独的实体这两个网站不应放在同一个集合中。
  • 您提供第三方社交登录服务。使用 例如 OAuth 或 OpenId Connect,它们通常依赖第三方 Cookie 来 为用户提供更顺畅的登录体验这是一个有效用例,但并非 适合 First-Party Set,因为组织之间存在明显差异。 WebID 等早期提案 探索实现这些用例的方法。