谷歌浏览器：2024年完全禁用第三方cookie

大家好，我叫依查。

作为一名程序员，小编时刻关注谷歌浏览器Chrome的更新。今天访问Chrome开发者社区论坛时，发现了一个非常好的消息（对于用户来说）：谷歌浏览器将在2024年全面禁用第三方cookie。但是对于资本来说有一个坏消息，那就是全面禁止cookies将对互联网广告功能产生严重影响。

Chrome 计划从2024 年第一季度开始对1% 的用户禁用第三方Cookie，以方便测试。从2024 年第三季度开始，该禁令将扩大至100%。

如果您的粉丝网站仍在使用第三方cookie，那么是时候采取行动了。第三方cookie 的时间已经不多了……需要立即进行调整。

第三方cookie 为Web 提供了跨站点跟踪的能力。它的存在对网络用户的个人隐私构成了巨大的威胁，这就是主流浏览器开始弃用它们的原因。详细信息请阅读这篇文章：

Google Chrome：对cookie 访问方式进行重大调整

这篇文章写于2023年5月，当时我看到cookie的访问方式发生了重大调整，我大概想放弃放弃第三方cookie的想法。

仅仅过了短短五个月，我就下定决心正式退出禁令计划。

主要原因是第三方cookies的影响太大了，不仅仅是谷歌。直接封禁会对当时的互联网广告功能造成严重影响，也会影响很多网站的正常功能（比如登录）的使用。

三年多来，Chrome 一直在开发一组功能，可以减少跨站点跟踪，同时确保每个人都可以自由访问在线内容和服务。这是隐私沙箱。

Privacy Sandbox 提供了一组API，为身份、广告和欺诈检测等用例提供了当前最先进技术的基于隐私的替代方案。有了这个替代方案，终于到了开始逐步淘汰第三方cookie 的时候了。

审查网站的三方 Cookie 使用情况

为了了解此禁令的影响，我们首先需要了解我们网站上的哪些位置使用了第三方cookie。

第一个，我们可以通过cookie的SameSite属性来识别，这是一个策略，用于设置浏览器在发送跨站请求时是否允许携带cookie。 SameSite 属性具有三个可能的值：

Strict：当设置为Strict时，只有当前网页的域名与cookie所属的域名完全相同时，浏览器才会发送cookie。 Lax (Lose)：设置为Lax 时，如果您导航到目标页面，浏览器将发送cookie，但仅限于顶级导航（例如单击链接或通过URL 进行导航）。浏览器不会在跨域POST 请求或通过iframe 加载的请求上发送cookie。 None：设置为None时，无论请求是同站还是跨站，浏览器都会发送cookie。但是，要使用None 值，还需要同时设置Secure 属性，以确保仅在使用HTTPS 安全连接时发送cookie。在Chrome 80版本中，cookie的SameSite属性默认设置为Lax。很多场景下，如果我们想要保留跨站cookie的可移植性，就必须主动设置SameSite=None，所以我们可以在代码中搜索并设置SameSite=。 None 的Cookie 必须是第三方Cookie。

我们可以打开Chrome DevTools的Application面板，找到Cookie，然后按SameSite排序：

另外，从Chrome 118 开始，DevTools Issues 选项卡开始提示这样的问题：跨站点上下文中发送的Cookie 将在未来的Chrome 版本中被阻止。

做个禁用测试

如果您想直接感受禁用第三方cookie对您网站的影响，您可以尝试使用

使用–test-third-party-cookie-phaseout 命令行标志启动Chrome，或从Chrome 118 启用chrome://flags/#test-third-party-cookie-phaseout。这会将Chrome 设置为阻止第三方直接饼干。

您还可以尝试使用通过chrome://settings/cookies 阻止的第三方cookie 进行浏览：

三方 iframe 的 Cookie

第三方cookie 的一个非常常见的场景是iframe 嵌入。

比如现在有一个通用的聊天服务，由第三方服务support.chat.example支持。我们的网站Retail.example 希望将此聊天框嵌入到iframe 中。该嵌入式聊天服务可能依赖cookie 来保存用户的交互历史记录。

在这样的场景中，我们可以使用Partitioned属性作为具有独立分区状态（CHIPS）的cookie的一部分，这样可以使用单独的分区进行跨站点访问。

为了实现CHIPS，我们可以将Partitioned 属性添加到Set-Cookie 标头中。

通过设置分区，站点可以选择将cookie 存储在由顶级站点分区的单独cookie jar 中。

例如，我们通过A 网站的iframe 嵌入了C 网站。正常情况下，如果禁用第三方cookie，C 网站将无法访问A 网站上的cookie。

如果C 在其cookie 上指定Partitioned 属性，则cookie 将保存在特殊的分区jar 中。只有当站点C通过iframe嵌入在站点A中时才会生效，并且浏览器将确定只有当顶级站点是A时才会发送cookie。

当用户访问新站点时，例如站点B，如果还通过iframe 嵌入了站点C，则站点B 下的站点C 将无法访问之前在A 下设置的cookie。

如果用户直接访问站点C，他将无法访问此cookie。

以下是一些潜在的用例：

第三方聊天嵌入第三方地图嵌入第三方支付嵌入子资源CDN 负载平衡用于服务不受信任用户内容的沙盒使用cookie 进行访问控制的第三方CDN 为需要cookie 的第三方提供API 呼叫者嵌入广告

相关站点的 Cookie

如果我们的第三方cookie 仅在少数相关网站上使用，然后考虑使用相关网站集(RWS) 来允许在这些已定义网站的上下文中跨网站访问cookie。

相关网站集(RWS) 听起来可能是一个新概念，但当时它们仍被称为第一方cookie 集合。

例如，我们同一网站内容由于提供不同地区的服务而使用多个域名，如：www.17.cn.com、www.17.us.com等。

像这样，具有可见关系的相关站点（例如公司产品的变体）、服务域（例如API、CDN）或国家代码域（例如*.cn、*.jp）等，我们都可以将它们添加到相关网站集(RWS) 以启用第三方cookie 共享。

{“主要”:“https://primary.com”，“关联站点”: [“https://associate1.com”，“https://associate2.com”，“https://associate3.com”，“https://associate4.com”]，“serviceSites”: [“https://servicesite1.com” \’], \’rationaleBySite\’: { \’https://associate1.com\’: \’解释如何向用户清楚地呈现跨域的从属关系以及为什么用户期望您的域具有从属关系\’, \’https://associate2.com\’: \’解释您如何向用户清楚地呈现跨域从属关系，以及为什么用户希望您的域具有附属关系\’, \’https://associate3.com\’: \’解释如何向用户清楚地呈现跨域从属关系，以及为什么用户希望您的域具有附属关系\’, \’https://serviceSite1.com\’: \’解释此子集中的每个域如何支持功能或安全需求。\’ }, \’ccTLD\’: { \’https://associate1.com\’: [\’https://associate1.ca\’, \’https://associate1. co.uk\’, \’https://associate1.de\’], \’https://associate2.com\’: [\’https://associate2.ru\’, \’https://associate2.co.kr\’, \’https://associate2.fr\’], \’https://primary.com\’: [\’https://primary.co.uk\’, \’https://associate1.de\’] co.uk\’] }站点可以使用存储访问API 通过requestStorageAccess() 请求访问跨站点cookie，或使用requestStorageAccessFor() 委托访问。当站点位于同一组内时，浏览器会自动授予访问权限，并且可以使用跨站点cookie。

这意味着相关站点组仍然可以在有限的上下文中使用跨站点Cookie，但仅限于您指定的相互相关且受信任的站点集合，并且不要冒险在同一网络中的不相关站点之间共享该跨站点Cookie。允许跨站点跟踪的方式。第三方Cookie，否则就失去了原有的意义。

潜在应用场景：

应用程序特定域名品牌特定域名国家特定域名用于服务不受信任的用户内容的沙盒域名API、CDN 的服务域名

其他场景

CHIPS 和RWS 支持保留特定类型的跨站点Cookie 访问，还可以保护用户隐私，但第三方cookie 的其他用例必须迁移到注重隐私的替代方案。

Privacy Sandbox 为特定用例提供了一组专门构建的API，无需第三方cookie：

联合凭证管理(FedCM)：支持联合身份服务，允许用户登录站点和服务。私有状态令牌：通过跨站点交换有限的非识别信息来实现反欺诈和反垃圾邮件。主题：支持基于兴趣的广告和内容个性化。受保护的受众群体：支持再营销和自定义受众群体。归因报告：可以衡量广告转化率。此外，Chrome 支持存储访问API (SAA)，以便在iframe 内进行用户交互。 Edge、Firefox 和Safari 已支持SAA。它在维护用户隐私方面取得了良好的平衡，同时仍然启用关键的跨站点功能并具有跨浏览器兼容性的优势。

存储访问API (SAA) 主动向用户显示浏览器权限提示。为了提供最佳的用户体验，只有当网站通过调用requestStorageAccess() 与嵌入页面进行交互并且之前在顶级上下文中访问过第三方网站时，才会提示用户。一旦成功授予权限，该网站将允许跨站点cookie 访问30 天。

潜在的用例是经过身份验证的跨站点嵌入，例如社交网络评论小部件、支付提供商、订阅视频服务等。

总结

为了避免业务受到影响，大家应该尽快检查自己网站上的第三方cookie，并迁移到合适的替代方案。

最后

一台电脑，一个键盘，智慧生活；

几行数字和字母，精心书写生命的美好；

一个灵感、一个方案，推动科技进步，推动社会发展。

创作并不容易。如果您喜欢，请关注、点赞、打赏。我们会不时更新有用的信息和技术相关信息。请速速收藏。谢谢你！您的一个小举动，是对小编的认可，也是创作的动力。

创作文章的初衷是：沉淀、分享、利他。我不仅想写给现在的你们，也想写给10年或20年后贪婪的工程师。现在你正站在浪潮之巅。面对神奇的互联网世界，人们很容易将一条河视为整个海洋。未来的读者已经了解了这项技术的历史，但他们不可避免地会忽略一些细节。如果未来的工程师真的创造了一台时间旅行机器，可以带你回到现在呢？那么小编的创作就是你和过去的工程师们联系的秘密密码。你可以感受到他们在这个时代的键盘上留下的余温。