各大主流浏览器正在逐步禁用三方cookies。在下面的文章中，笔者也分析了完全禁用三方cookies后对我们网站的一些影响：当浏览器完全禁用第三方cookies后，一个公司或组织往往在不同的业务下有多个不同的域名，比如taobao.com,tianmao.com,这么多正常的业务场景可能是借助第三方cookie实现的（比如singlesign-on和Consentmanagement），直接禁用可能对我们的业务影响很大，还有之前一直没有很好的解决办法，这也是为什么Chrome在禁用第三方cookie方面进展非常缓慢的原因。在第一方cookie和第三方cookie被区别对待的情况下，Chrome引入了新的第一方设置政策，允许同一实体拥有的不同域被视为第一方。这意味着我们可以标记打算在同一方上下文中共享cookie的不同域，目的是在防止第三方跨站点跟踪和仍然保持正常业务场景之间取得平衡。目前，First-PartySets策略尚未在稳定版正式上线，仍处于试用阶段。单方cookie和三方cookie的区别很多朋友对于三方cookie的概念可能还比较模糊。我们先回顾一下：Cookies在本质上是不区分第一方或第三方cookies的，它取决于当前包含cookies的上下文。我们还是用之前的老例子：如果你正常浏览天猫，天猫会把你的信息写入一些cookie到.tmall.com这个域名下，但是当你打开控制台的时候，你会看到并不是所有的cookie都是在.tmall.com域名下，其他域名下有很多cookie。当前域下的所有这些cookies都属于第三方cookies。虽然你可能永远不会访问这些域，但它们一直在悄悄地通过这些第三方cookie识别你的信息，然后将你的个人信息发送过来。.tmall.com域名下的cookie都是第一方cookie，为什么还需要第三方cookie？再次打开淘宝网，你会发现不再需要登录了，因为淘宝和天猫都是阿里旗下的产品，阿里为他们提供了统一的登录服务。同时，你的登录信息也会保存在这个统一的登录服务域中，所以这个域中保存的cookie就变成了三方cookie。SameSite问题Chrome在之前的版本中为cookie添加了一个SameSite属性来限制对第三方cookie的访问。Chrome80之后，SameSite的默认值设置为SameSite=Lax。在严格模式下，所有第三方cookies将被阻止携带。这个设置基本上可以防止所有的CSRF攻击。但是它的友好性太差了，连普通的GET请求都不让通过。在Lax模式下，只有使用危险的HTTP方法（例如POST）的请求中携带的第三方cookie才会被阻止。同时，使用JavaScript脚本发起的请求不能携带第三方cookies。但是，如果你尝试以上两种模式，我们上面提到的一些正常的需求场景是无法实现的。对于这种Cookie，我们现在一般手动设置SameSite=None。这意味着这种cookie失去了跨站请求伪造（CSRF）的保护。比如在evil.site上向me.site发送请求也会带上我们的cookie。First-PartySetsstrategy在上面的正常业务场景中，所有不同的域名基本上都来自同一个组织或企业，我们希望同一运营实体下的不同域名的cookies也可以共享。第一方集可以定义跨站点上下文仍然是第一方的情况。Cookie可以包含在第一方集合中，也可以排除在第三方环境中。第一方集提出了一种方法来明确定义同一委托人拥有和运营的多个站点之间的关系。例如，.tmall.com和taobao.com都可以定义为由同一实体运营。该策略源自浏览器的PrivacySands提案，提出了分区身份的概念，以防止跨站点跟踪、在站点之间划定界限并限制对可用于识别用户的任何信息的访问。浏览器的默认行为是对同一站点进行分区。上面的新策略意味着分区可以作为多个站点打开。第一方集策略的一个重要部分是确保跨浏览器策略防止滥用或误用。例如，第一方集策略不得在不相关站点之间或不属于同一实体的组站点之间交换用户信息。所以单点登录的场景可能不是这样解决的，因为这个场景属于用户信息的交换。目前对于如何定义哪些信息是用户信息，官方并没有说明，所以笔者对这个地方不是很清楚。W3C目前正在讨论新的第一方集的配置和验证，正在考虑的一个选项是由独立实体而不是浏览器公司来处理验证。目前第一方集已经建立了以下原则：第一方集中的域必须由同一组织拥有和运营。用户应将所有域识别为一个组。所有域名都应共享共同的隐私政策。如何定义第一方集每个需要使用第一方集策略的域名都应该在/.well-known/first-party-set路由下托管一个JSON配置。例如，conardli.top的配置应该托管在https://conardli.top/.well-known/first-party-set下：{"owner":"conardli.top","version":1,"members":["conardli.com","conardli.cn"]}另外conardli.com和conardli.cn域名都需要添加owner配置：{"owner":"conardli.top"}First-Party集合和一些限制：一个集合可能只有一个所有者。一个成员只能属于一个集合，不能重叠或混合。域名列表不应太大。SameParty属性还好，上面已经介绍了很多，最后回到本文的主题，CookieSameParty属性，这个属性是配合First-PartySets使用的。所有需要在启用First-PartySets的域名下共享的cookie都需要添加SameParty属性。比如我在conardli.top下设置如下cookie：Set-Cookie:name=lishiqi;Secure;SameSite=Lax;SameParty这样当我在conardli.cn下发送conardli.top域名请求时，cookie可以也会带，但是如果我在别的网站下发这个请求，比如eval.site，cookie是不会带的。在SameParty得到广泛支持之前，可以将其与SameSite属性一起定义，以保证cookie的行为被降级，另外还有一些额外的要求：SamePartyCookie必须包含Secure。SamePartyCookie不得包含SameSite=Strict。如何尝试？浏览器禁用第三方cookies后，这个新提议应该会得到广泛应用，大家可以试试看！您可以在以下两个地方参与提案的讨论：First-PartySets政策讨论：https://github.com/privacycg/first-party-setsSameParty属性讨论：https://github.com/cfredric/samepartynow提案还在试用阶段，你可以试试--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参考https://www.chromestatus.com/feature/5280634094223360https://github.com/cfredric/samepartyhttps://github.com/cfredric/samepartyhttps:///开发人员。chrome.com/blog/first-party-sets-sameparty/
