第三方Cookie已终结，该怎么应对？

Chrome开发人员2023年10月11日在Chrome的官方博客上宣布将于2024开始禁用第三方Cookie，并且提供了各种替代方案。

第三方Cookie的禁用可能会对我们的业务有不小的影响，开发社区针对这一变动想出了很多新的提议，Chrome为了弥补这个改动给互联网世界所带来的不便，开发了各种API来作为替代方案，谷歌把整个方案起了一个名字叫：Privacy Sandbox，中文可以叫隐私沙箱。

其实像Safari这样的浏览器早就禁用掉了第三方Cookie，因为苹果在这方面也没有利益存在，而谷歌不太一样，谷歌的相当一部分收入来自于基于第三方Cookie的广告服务，他必须要想出一套替代方案，平稳的过渡。

目标

整个事情的目标是为了减少跨站追踪，同时又不影响最终用户的使用体验。

我们现在的业务中使用第三方Cookie地场景确实很多，要全部禁用，然后使用替代方案，整个过程要做到不影响最终用户的使用，其工作量还是不小的。

时间表

Chrome官方计划于2024年第一季度开始禁用1%用户的第三方Cookie，这段时间算是一个测试期。然后2024年的第四季度开始，将逐步覆盖到100%的用户。整个进度会受英国竞争和市场管理局所关心的一些关于市场竞争问题处理情况的影响（这部分对于我们来说不重要，可以不用细究）。

事实上2023年第四季度局部测试就已经开始了，只不过这段时间是一些主动参与的组织先行开始测试。

这是Chrome官方给出的计划。不过这个计划在咱们国内可能不太适用，因为毕竟咱们的Chrome是不能自动更新的。咱们这边应该会整体滞后一些。

我们该怎么应对

我们现在很多业务都在使用第三方Cookie的机制，现在Chrome要禁用它了，那我们的业务怎么办？

Chrome的Privacy Sanbox隐私沙箱技术提出了一系列方案来应对该问题。隐私沙箱技术其实是一系列API的集合，咱们后面会单开文章，依次讲解。

几个措施如下：

咱们下面分别进行讲述。

措施1：检查目前的第三方Cookie使用情况

第一步我们需要看一下目前项目中第三方Cookie的使用情况。有下面几种方式：

检查设置了SameSite=None的Cookie。关于SameSite的具体使用方法，可以参考我们的文章

该属性的意思是对跨站请求携带Cookie没有限制。如果你的代码中有这种设置，那很有可能对这个Cookie有跨站的需求，这类Cookie很可能会作为第三方Cookie。
Chrome DevTools中Network面板里面，任一请求点击看详情时，可以看到请求和响应的Cookie，点击SameSite项，可以把所有的SameSite=None的cookie找出来。
Chrome DevTools中Application面板中，左侧的Storage下面的Cookie子菜单点击进去可以看到当前网站所存储的所有Cookie，点击SameSite可以找出所有SameSite=None的Cookie。
如果你的Chrome是118版本或者以上，那Chrome DevTools有一个Issues选项卡，如下图：

DevTools Issues 面板

这里会列出当前站点所有的第三方Cookie。

当我们检测到有使用第三方Cookie的机制的情况时，如果第三方Cookie不是我们自己团队维护，则最好通知相关人一起去解决该问题。

另外Chrome开发团队还在开发一个Chrome扩展来做相关的事情，说2023年11月就会发布。

如果检测出我们的网站确实有使用第三方Cookie地情况，那我们下一步需要通过主动禁用第三方Cookie来测试我们的业务是否能正常运转。

措施2：测试禁用第三方Cookie的情况

有几种方法可以直接让Chrome禁用第三方Cookie。

地址栏输入：chrome://settings/cookies，选择阻止第三方Cookie。
如果你的Chrome是118版本或者以上，可以进入flag设置：chrome://flags/#test-third-party-cookie-phaseout，然后直接将Test Third Party Cookie Phaseout功能开启。开启后，Chrome会在最下方提示你重启浏览器。
设置命令行启动参数 --test-third-party-cookie-phaseout，用命令行启动Chrome时，带上该参数。用我的Mac电脑举例如：/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --test-third-party-cookie-phaseout 不过作者亲测不起效果，建议还是用第1和第2种方法。

禁用掉第三方Cookie后，我们就可以做回归测试了，可能相关业务都得测试一边。

如果真的测试出问题了，我们该如何解决呢？请往下看。

措施3：Partitioned(CHIPS )机制

如果你不需要做跨站点的追踪，那我们可以使用Partitioned机制，来让Cookie依然可以跨站。什么是跨站点追踪可以看我们之前的文章

Partitioned是Cookie的一个属性，当我们在设置第三方Cookie时加上这个属性则意味着只有用户在访问当前网站（或者其一级域名站）时第三方的服务才可以获取到该Cookie。

想进一步了解Partitioned机制的具体内容，可以看这篇文章

措施4：可以指定有限的几个可跨站的站点

如果你们确实有跨站访问Cookie的需求，例如你们公司规模较大，有好几个网站，你们有一个独立的埋点服务，它有独立的域名，它会往客户端种Cookie来标记每个客户端。这个埋点服务只供你们公司自己的业务使用，不会像广告公司那样对大量网站进行追踪从而摸清用户的行为，造成用户隐私泄露。

Chrome对这种情况也有应对方案，就是可以让埋点服务的Cookie进行有限数量站点的跨站，这个数量上限是5个域名。Chrome 117版生效。

Chrome把这个特性叫做RWS，全名是Related Website Sets，中文翻译是相关域名集。要想让第三方Cookie能在这上限数为5的域名下可以被使用，那就需要告诉浏览器这个第三方和这几个域名是有关系的，这也是这个特性叫做相关域名集的原因。

措施5：requestStorageAccess()

这套API的名字叫Storage Access API（SAA）。这个名字确实有点不太形象，它最主要的API就是document.requestStorageAccess()。如果你的应用是作为第三方的网站以iframe的形式嵌入在其他网站中运行，那你可以调用这个API来向浏览器请求使用Cookie，但是这个API有个比较麻烦的限制，它需要用户主动和你的第三方内容产生交互，然后你才可以在交互事件处理函数中调用document.requestStorageAccess()，向用户请求存储Cookie的权限，用户点击同意后，你才能存储和读取Cookie。

浏览器会向用户询问是否允许第三方内嵌网站使用Cookie，Chrome现在的界面是这样的：

上图是浏览器的提示信息，我相信国内没有哪个网站愿意让用户看到这种让人困惑的提示信息吧。

所以笔者预测这个特性在国内的普及率一定不会高。

措施6：Federated Credential Management（FedCM）

中文可以翻译为联合凭证管理。这套机制是为了针对身份联合(Identity Federation)问题而专门定制的解决方案。

在身份联合机制中，普通网站不会去存储和管理具体的用户信息（具体的用户信息就是指用户的用户名、密码等信息），也不用去做具体的身份验证的功能，整个身份验证操作交给一个可信赖的第三方去做，这个第三方叫做Identity Provider（身份提供方）。这种机制在国外和国内都被广泛使用。

身份联合机制在国内的具体例子就是单点登录、第三方登录，第三方登录再具体一点就是像微信登录、微博登录，在国外的具体例子就是Facebook登录等。

身份联合机制一直需要依赖第三方Cookie、iframe、或者redirect（重定位）这些技术。而这些技术目前都被认为有可能导致用户隐私泄漏，容易被滥用，而用户却全然不知。

FedCM联合凭证管理就是作为一种第三方Cookie的替代技术，用于实现身份联合。

想详细了解FedCM联合凭证管理可以看这篇文章

措施7：Private State Tokens API

中文可以翻译为私有状态Token API。它原来的名字叫Trust Token API信任Token。

该机制的目的是为了帮助广告商解决人机识别问题。广告商不再需要使用数字指纹技术来追踪用户的行为从而进行人机识别，也不再需要使用第三方Cookie。

该机制可以当作人机识别的一种辅助机制，所以人机识别是指网站需要区分当前跟网站交互的是人类还是计算机程序，网站肯定不会希望计算机程序跟自己交互。但是该机制并不是像图形验证码之类的工具一样直接对人机进行区分，而是某些可信赖网站A对客户端人机识别通过后，分发给客户端浏览器一个Token，浏览器通过Private State Token的API保存了该Token，然后该用户再访问其他网站B时，其他网站B就可以再通过Private State Token的API来确认是否有某刻信任网站A的Token，如果有的话，网站B再用Private State Token的API向可信任网站A进行确认，验证通过后，网站B就可以认为客户端是一个人类。该机制的本质实际上是一种信任传递机制。通过这种方式，广告商就可以更轻松地识别出真人，从而不被骗取广告费。不再需要使用数字"指纹"收集技术。

目前该机制在W3C那边还处于非常早期阶段，最终的API会成什么样子还不能确定，因此建议大家只是了解一下就好。

如果你想看其具体的API可以先看其标准草案

措施8：其他供广告商使用的API

Topic API
Protected Audience API
Attribution Reporting API

这些API都是供广告商使用的API。

咱们可以不用了解其API细节，因为他们都还处在概念阶段，最终的API还远未确定。按照W3C正常的速度看，一般都是至少要5年以上，一个新的特性才可以放心的使用。

企业版Chrome的支持

企业版Chrome在国内可能很少有企业使用。大部分企业版Chrome用户不会参与2024年第一季度的1%用户的测试。如果企业内部网站暂时不想禁用第三方Cookie，可以关闭该功能

非广告场景可以申请延迟禁用第三方Cookie

Chrome官方在其博客上表示，如果你确实无法短时间内去除第三方Cookie，而且你也不是广告商，那你可以申请延迟禁用第三方Cookie，不过Chrome官方会对申请进行审核。

但是Chrome暂时还没有提供申请方式，目前还只是计划，如果我们的企业确实有需求，可以关注一下。

Chrome将会对特殊场景延迟禁用第三方Cookie

原话大致翻译如下：

跨站点（第三方）Cookie在网络上已经存在了超过四分之一个世纪，一直起着关键作用。任何改变，特别是破坏性的改变，都是一个复杂的过程，需要大量的协调，并采用渐进的方式。虽然新加的新的cookie属性和新的以隐私为重点的API能够应对大部分情况，但时某些特定场景可能很难覆盖，我们还是希望这些站点的用户的体验不会受到影响。

最典型的一种场景是这样的，在身份验证或支付流程中，顶级站点要么打开弹出窗口，要么重定向到第三方站点进行操作，然后返回到顶级站点，这时会在重定向的第三方站点中或嵌入的第三方站点中使用Cookie。我们打算提供一组临时的规则来识别这些情况，允许这种场景在有限的时间内使用第三方Cookie，以便给站点更长的时间来实施必要的更改。

上报问题的方式

Chrome官方也是意识到这次更改所带的巨大影响，它们提供了上报问题的渠道，不过作者发现该链接无法打开，或许过一阵子就好了。如果你有任何疑问，也可以向他们提问

结束语

本篇到此结束。