许多组织都有使用不同域名（例如 brandx.site 和 fly-brandx.site）或不同国家/地区域名（例如 example.com、example.rs、example.co.uk 等）的相关网站。
浏览器正朝着废弃第三方 Cookie 的方向发展，以改善网络上的隐私保护，但此类网站通常依赖 Cookie 来实现需要跨网域维护和访问状态的功能（例如单点登录和意见征求管理）。
在第一方和第三方获得不同的处理方式的情况下，First-Party Sets 可允许将由同一实体拥有和运营的相关域名视为第一方。第一方集合中的域名被视为第一方，它们可以标记要在第一方环境中设置或发送的 Cookie。我们的目标是在防止第三方跨网站跟踪的同时，保持不会破坏有效用例的路径。
第一方组提案目前处于测试阶段，请继续阅读，了解其运作方式以及如何试用。
第一方 Cookie 与第三方 Cookie 有何区别？
Cookie 本身并非第一方或第三方，具体取决于 Cookie 所在的当前情境。您可以在请求的 cookie 标头中添加该令牌，也可以通过 JavaScript 中的 document.cookie 添加该令牌。
例如，如果 video.site 包含 theme=dark Cookie，那么当您浏览 video.site 并向 video.site 发出请求时，便属于同一网站环境，并且包含的 Cookie 是第一方 Cookie。
但是，如果您位于 my-blog.site 上，并且 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 Sets 政策
First-Party Set 提出了一种方法，用于在同一实体拥有和运营的多个网站中明确定义此关系。这样，brandx.site 就可以定义其与 fly-brandx.site、drive-brandx.site 等的第一方关系。
推动各种 Privacy Sandbox 提案的隐私保护模型基于身份分区概念，以防止跨网站跟踪，即在网站之间划定边界，限制对可用于识别用户的任何信息的访问。
虽然默认选项是按网站进行分区，这可以解决许多第一方用例，但 brandx.site 示例表明，第一方可以不仅仅局限于一个网站。
First-Party Set 提案的一项重要内容是确保跨浏览器的政策可防止滥用或误用。例如，第一方组合不得允许在无关的网站之间交换用户信息，也不得对不归同一实体所有的网站进行分组。其目的是确保 First-Party Set 映射到用户认为是第一方的对象，而不是用于在不同方之间共享身份。
网站注册第一方集的一个可能方法是，将其提议的一组网域以及满足浏览器政策所需的信息提交给公共跟踪器（例如专用 GitHub 代码库）。
按照政策验证 First-Party Set 断言后，浏览器便可以通过更新流程提取集合列表。
来源测试有已定义的政策，但该政策尚未最终确定，但原则可能会保持不变：
- First-Party 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"]
}
该集合的每个成员还托管一个指向该集合的所有者的静态 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 Sets 对 Cookie 有何影响？
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 命令行标志并提供网站的逗号分隔列表来试用此功能。
您可以在演示网站 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 集对 Cookie 有何影响，这会很有帮助。
如果您有时间进行实验和反馈，还可以注册参与针对第一方集和 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） 就提出了这种方案，它会为网站提供一种通过 Partitioned 属性选择启用的方式，让网站仍然可以使用这些重要的跨网站嵌入、资源、API 和服务，同时防止跨网站身份信息泄露。
请考虑以下几点，它们可能意味着您的网站不需要设置：
- 您托管在不同的来源（而非不同的网站）上。在上面的示例中，如果
brandx.site包含fly.brandx.site和drive.brandx.site，则这两个子网域都位于同一网站中。Cookie 可以使用SameSite=Lax，无需进行设置。 - 您向其他网站提供第三方嵌入内容。在简介中，
video.site中嵌入的my-blog.site视频示例是一个明显的第三方分界。这两个网站由不同的组织运营，用户将其视为不同的实体。这两个网站不应同时出现在同一组中。 - 您提供第三方社交登录服务。使用 OAuth 或 OpenId Connect 等身份提供方通常依赖于第三方 Cookie，以便为用户提供更顺畅的登录体验。这是一个有效的用例，但不适用于 First-Party Sets，因为组织存在明显差异。WebID 等早期提案正在探索实现这些用例的方法。