许多组织都有使用不同域名的相关网站,例如
brandx.site
和 fly-brandx.site
,或不同国家/地区的域名,例如
example.com
、example.rs
、example.co.uk
等。
浏览器越来越倾向于创建第三方 Cookie 已过时 来加强网络隐私保护,但是像这样的网站常常依赖于 Cookie 需要跨域维护和访问状态的功能 (例如单点登录和意见征求管理)。

First-Party Set 可允许由 在第一方和第三方标识符中 系统会以其他方式处理第三方同一个 Pod 中的 第一方组则被视为同一方,它们可以标记哪些 Cookie 在同一方环境中设置或发送。目的是找到 在阻止第三方跨网站跟踪和 维护一个不会破坏有效用例的路径。
First-Party Set 提案目前正在测试中 阶段,请继续阅读下文,了解其运作方式 以及如何试用
第一方 Cookie 和第三方 Cookie 有何区别?
Cookie 本质上不是第一方或第三方,这取决于当前的
包含该 Cookie 的上下文。可以通过
cookie
标头或在 JavaScript 中通过 document.cookie
进行设置。
例如,当您浏览网页时 video.site
有 theme=dark
Cookie
video.site
,并且向 video.site
(同网站)发出请求
上下文和
包含的 Cookie 是第一方。
不过,如果您使用的是my-blog.site
,它嵌入了 iframe 播放器,
video.site
(当请求从 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 代码库)以及满足浏览器要求所需的信息 政策。
根据政策验证了第一方 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 不会包含在内。

在 SameParty
获得广泛支持之前,请将 SameSite
属性与其搭配使用,
定义 Cookie 的后备行为您可以将 SameParty
属性提供介于 SameSite=Lax
和
SameSite=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.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
如果您有充足的精力进行实验和提供反馈,也可以报名 适用于针对 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.site
有fly.brandx.site
和drive.brandx.site
,则这些 是同一网站内的不同子网域。Cookie 可以使用SameSite=Lax
,无需进行任何设置。 - 您向其他网站提供第三方嵌入内容。在片头中,
my-blog.site
上嵌入的video.site
的视频明显属于第三方 除法运算。这些网站由不同的组织运营,用户会看到它们 视为单独的实体这两个网站不应放在同一个集合中。 - 您提供第三方社交登录服务。使用 例如 OAuth 或 OpenId Connect,它们通常依赖第三方 Cookie 来 为用户提供更顺畅的登录体验这是一个有效用例,但并非 适合 First-Party Set,因为组织之间存在明显差异。 WebID 等早期提案 探索实现这些用例的方法。