许多组织都有具有不同域名的相关网站（例如 brandx.site 和 fly-brandx.site），或具有不同国家/地区的网域（例如 example.com、example.rs、example.co.uk 等）。
浏览器正逐渐淘汰第三方 Cookie 以加强网络隐私保护，但这类网站通常需要依赖 Cookie 才能实现需要跨网域维护和访问状态的功能（例如单点登录和意见征求管理）。
在第一方和第三方受到不同方式的情况下，First-Party Set 可让同一实体拥有并运营的相关域名被视为第一方域名。第一方集合中的域名被视为“同一方”，并可标记哪些 Cookie 打算在同一方环境中设置或发送。目的是在阻止第三方跨网站跟踪与维护不会破坏有效用例的路径之间取得平衡。
First-Party Set 提案目前处于测试阶段，请继续阅读下文，了解其工作原理以及如何试用。
第一方 Cookie 与第三方 Cookie 有何区别？
Cookie 本质上不是第一方或第三方，具体取决于包含 Cookie 的当前上下文。这可以通过 cookie 标头中的请求实现，也可以通过 JavaScript 中的 document.cookie 实现。
例如，如果 video.site 具有 theme=dark Cookie，那么当您浏览 video.site 并且向 video.site 发出请求时，这就是同网站上下文，包含的 Cookie 是第一方 Cookie。
但是，如果您使用的是 my-blog.site，其中嵌入了 video.site 的 iframe 播放器，那么当从 my-blog.site 到 video.site 的请求是跨网站上下文且 theme Cookie 是第三方 Cookie 时。
Cookie 是否包含由 Cookie 的 SameSite 属性决定：
- 同网站上下文与
SameSite=Lax、Strict或None会使 Cookie 成为第一方 Cookie。 - 使用
SameSite=None的跨网站上下文会使相应 Cookie 成为第三方 Cookie。
不过，情况并非总是那么清晰。假设 brandx.site 是一个旅行预订网站，他们也使用 fly-brandx.site 和 drive-brandx.site 来拆分航班和租车服务。在预订一个历程的过程中，访问者会在这些网站之间进行选择，以选择不同的选项；他们希望自己选择的“购物车”商品可以继续存在于这些网站上。brandx.site 使用 SameSite=None Cookie 管理用户的会话，以允许其跨网站上下文。但其缺点是，Cookie 现在无法提供跨网站请求伪造 (CSRF) 保护。如果 evil.site 包含对 brandx.site 的请求，则该请求也会包含该 Cookie！
该 Cookie 是跨网站 Cookie，但所有这些网站都归同一组织所有并经营。访问者还了解它属于同一组织，并且希望在他们之间共享相同的身份，也就是拥有相同的身份。
First-Party Set 政策
First-Party Set 提出了一种方法，可在同一方拥有并运营的多个网站上明确定义这种关系。这样，brandx.site 便可以定义其与 fly-brandx.site、drive-brandx.site 等的第一方关系。
各种 Privacy Sandbox 提案的隐私模型基于对身份进行分区以防止跨网站跟踪的概念，即在网站之间划定边界，限制对任何可用于识别用户身份的信息的访问。
虽然默认选项是按网站进行分区，这可以解决许多第一方用例，但 brandx.site 示例表明，第一方可以比一个网站大。
First-Party Set 提案的一个重要部分是确保跨浏览器的政策防止滥用或误用。例如，First-Party Set 不得支持跨不相关的网站交换用户信息，也不得支持不归同一实体所有的网站分组。其理念是确保 First-Party Set 映射到用户可理解的第一方集合，而不是用作不同方共享身份的方式。
网站注册第一方集的一种可行方式是，让网站将其提议的网域组（例如专用的 GitHub 代码库）以及满足浏览器政策所需的信息提交给某个公开跟踪器。
根据政策验证第一方集断言后，浏览器便可通过更新流程提取集列表。
源试用具有既定的政策（并非最终），但原则可能会保持不变：
- 第一方集中的网域必须由同一组织拥有和运营。
- 这些网域应作为一个群组，以便用户能够识别。
- 网域应采用相同的隐私权政策。
如何定义第一方集合
确定组织第一方资源集的成员和所有者后，一个关键步骤就是提交您提议的第一方资源集以供审批。具体流程仍在讨论中。
如需声明第一方资源集，列出成员和所有者的静态 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"]
}
该集的每个成员还托管了一个指向该集的所有者的静态 JSON 资源。
在 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？
饼干的匹配要素是提议的 SameParty 属性。指定 SameParty 会指示浏览器在其上下文和顶级上下文属于同一第一方集合时包含该 Cookie。
这意味着，如果 brandx.site 设置了此 Cookie：
Set-Cookie: session=123; Secure; SameSite=Lax; SameParty
然后，当访问者使用 fly-brandx.site 且请求发送到 brandx.site 时，该请求中将包含 session Cookie。如果不属于第一方集合的某个其他网站（例如 hotel.xyz）向 brandx.site 发送请求，则 Cookie 不会被包含在内。
在 SameParty 得到广泛支持之前，请结合使用 SameSite 属性和它来定义 Cookie 的回退行为。您可以将 SameParty 属性视为为您提供一个介于 SameSite=Lax 和 SameSite=None 之间的设置。
SameSite=Lax; SameParty将扩展Lax功能，在支持的情况下包含同方上下文，但如果不支持，则回退到Lax限制。SameSite=None; SameParty会限制None功能仅在受支持的同方上下文中使用，但如果不支持，则回退到使用更广泛的None权限。
此外，您还需要满足一些其他要求：
SamePartyCookie 必须包含Secure。SamePartyCookie 不得包含SameSite=Strict。
Secure 是强制性的，因为这仍然是跨站点的，您应该通过确保安全的 (HTTPS) 连接来降低这些风险。同样，由于这是一种跨网站关系，因此 SameSite=Strict 无效，因为它仍允许在集中实现基于网站的 CSRF 严格保护。
First-Party Set 适合哪些使用情形？
当一个组织需要一种跨不同顶级网站的共享身份时，First-Party Set 非常合适。在这种情况下，共享身份是指从完整的单点登录解决方案到只需跨网站共享偏好设置的任何对象。
您的组织可能会为以下账号使用不同的顶级域名：
- 应用网域：
office.com、live.com、microsoft.com - 品牌网域：
amazon.com、audible.com/disney.com、pixar.com - 用于启用本地化的国家/地区特定网域：
google.co.in、google.co.uk - 用户从不直接交互但在同一组织的网站上提供服务的服务网域：
gstatic.com、githubassets.com、fbcdn.net - 用户从不直接交互但出于安全考虑而存在的沙盒网域：
googleusercontent.com、githubusercontent.com
您如何参与其中？
如果您有一组符合上述条件的网站，则有多个选项可以参与。最简单的方法就是阅读并加入有关这两个提案的讨论：
在测试阶段，您可以使用 --use-first-party-set 命令行标志并提供以英文逗号分隔的网站列表来试用该功能。
使用以下标志启动 Chrome 后，您可以在演示网站 (https://fps-member1.glitch.me/) 上尝试此操作：
--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
如果您要加入源试用并在 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）一起提议的路由，CHIPS 可以通过 Partitioned 属性为网站提供选择启用路由，以保留那些重要的跨网站嵌入、资源、API 和服务，同时防止泄露跨网站标识信息。
您还需要考虑其他一些因素，以表明您的网站或许没有问题，不需要一组设置：
- 托管在不同源（而非不同网站）上。在上面的示例中，如果
brandx.site包含fly.brandx.site和drive.brandx.site，则它们是同一网站内的不同子网域。这些 Cookie 可以使用SameSite=Lax，无需设置。 - 您向其他网站提供了第三方嵌入代码。在片头中，
video.site上嵌入在my-blog.site中的视频的示例是明显的第三方划分。这些网站由不同的组织运营，用户将其视为单独的实体。这两个网站不应位于同一个集合中。 - 您提供第三方社交登录服务。使用 OAuth 或 OpenId Connect 等服务的身份提供方通常依赖第三方 Cookie 来为用户提供更顺畅的登录体验。这是一个有效的用例，但不适用于 First-Party Set，因为组织之间存在明显差异。WebID 等早期提案正在探索实现这些用例的方法。