当浏览器全面禁用三方Cookie|博客系列
苹果公司前不久对 Safari 浏览器进行一次重大更新，这次更新完全禁用了第三方 Cookie，这意味着，默认情况下，各大广告商或网站将无法对你的个人隐私进行追踪。而微软和 Mozilla 等也纷纷采取了措施禁用第三方 Cookie，但是由于这些浏览器市场份额较小，并没有给市场带来巨大的冲击。
从 2017 年截至 2019 年底， Google 面临的罚款总额已经超过 93 亿欧元，其中一大原因便是侵犯用户数据隐私。迫于巨大压力，Google Chrome 官方团队前不久也宣布，为了提升用户隐私和安全，未来两年将完全禁用第三方 Cookie。
在完全不能写入三方 Cookie 的情况下，将会对前端的数据读写方式，甚至是整个广告行业带来巨大影响。
# Cookie 的意义
众所周知，HTTP 协议是无状态的协议，如果你在同一个客户端向服务器发送多次请求，服务器不会知道这些请求来自同一客户端。
这正是 HTTP 协议得以广泛应用的原因，试想一下，如果它是有状态协议，你必须要时刻与服务器建立链接，那么如果连接意外断开，整个会话就会丢失，重新连接之后一般需要从头开始；而如果是无状态协议，使得会话与连接本身独立起来，这样即使连接断开了，会话状态也不会受到严重伤害，保持会话也不需要保持连接本身。
如果 HTTP 协议只是用来访问静态文件，那不会有任何问题，但是如果你要为广大用户提供更好的服务，服务器就需要知道每个请求具体来自于哪个用户，比如你在逛淘宝的时候你只需要登录一次，当你发起一次购买请求，服务器就已经知道你登录过了，不会再让你进行登录。
所以 HTTP 协议需要占用浏览器的一小块存储，存储当前访问用户的一些 ”状态“，然后每次发起 HTTP 请求，请求中就会携带这些状态，从而让服务器知道你是谁。 Cookie 出现的的意义就是为了解决这个问题，让无状态的 HTTP 协议拥有一小块记忆。
但是， Cookie 一经出现，就成了各大广告和购物网站窥探用户隐私的利器，他们使用第三方 Cookie 不断获取你的数据，那么什么第三方 Cookie 呢？
# 第三方 Cookie
如果是你正常的正在逛着天猫，天猫会把你的信息写入一些 Cookie 到 .tmall.com 这个域下，然而打开控制台你会看到，并不是所有 Cookie 都是 .tmall.com 这个域下的，里面还有很多其他域下的 Cookie ，这些所有非当前域下的 Cookie 都属于第三方 Cookie，虽然你可能从来没访问过这些域，但是他们已经悄悄的通过这些第三方 Cookie来标识你的信息，然后把你的个人信息发送过去了。
而 .tmall.com 这个域下的 Cookie 都属于第一方 Cookie，那么为什么还需要第三方 Cookie 呢？再打开 taobao.com，你会发现你已经不需要再登录了，因为淘宝、天猫都属于阿里旗下的产品，阿里为他们提供统一的登录服务，同时，你的登录信息也会存到这个统一登录服务的域下，所以存到这个域下的 Cookie 就成了三方 Cookie。
我们再打开已经完全禁用了第三方 Cookie 的 Safari，发现只剩下 .tmall.com 这个域下的 Cookie 了。
这时你会发现即使你已经登录了天猫，再访问淘宝也还是需要登录的，你已经无法享用这样的功能了，而三方 Cookie 可不仅仅就这么点用途，在 Web 开发中，三方 Cookie 的应用非常之广，下面我们再来具体看几个应用场景：
# 三方Cookie的用途
# 前端日志打点
大多数 Web 站点都会引用一些第三方 SDK 来进行前端异常或性能监控，这些 SDK 会通过一些接口将监控到的信息上传到他们的服务器。一般它们都需要标识每个用户来方便排查问题或者统计 UV 数据，所以当你一此请求这个站点的时候，它们可能会在你的站点上 set 一个 Cookie，后续所有的日志上报请求都会带上这个 Cookie 。
由于一般这些第三方 SDK 都是用于监控的通用服务，它们肯定会拥有自己独立的域名，比如 log.com，它在你的域名 mysite.com 下种下的 Cookie 就属于第三方 Cookie。
# 广告营销神器 - Facebook Pixel
在电商业务中，追踪流量、导流量、转换率、销售额这些都是商家最关心的问题。这时候你就可以使用 Facebook Pixel，简单来说 Facebook Pixel 像素就是一串 JavaScript 代码，可以追踪广告的转化量、改进受众定位、使广告花费回报最大化。
当访客进入到被设有 Facebook Pixel 的页面时，便会触发这段代码。比如，查看了商品或者加入购物车， Facebook Pixel 便会向系统发送请求来记录这些行为，系统可以利用这些收到的行为信息进一步的做追踪和优化。
举一个实际例子，我们进入一个国外的电商网站 Brava Fabrics ，你会发现已经被写入了一堆 facebook.com 下的三方 cookie：
我猜测这个 fr 应该就是用来标识我身份信息的 cookie，然后点击几个页面，在 network 里面找到了几个 facebook 发送的请求，下面是其中一个：
https://www.facebook.com/tr/?id=382444918612794&ev=PageView&dl=https%3A%2F%2Fbravafabrics.com%2Fcollections%2Fa-moment-of-bliss&rl=https%3A%2F%2Fbravafabrics.com%2F&if=false&ts=1586868288778&sw=1680&sh=1050&ud[ct]=eb045d78d273107348b0300c01d29b7552d622abbc6faf81b3ec55359aa9950c&ud[country]=eb045d78d273107348b0300c01d29b7552d622abbc6faf81b3ec55359aa9950c&v=2.9.15&r=stable&ec=0&o=30&fbp=fb.1.1586867082370.951509876&it=1586868284974&coo=false&rqm=GET
查看详情你会发现，有下面几个主要的参数：
dl: https://bravafabrics.com/collections/a-moment-of-bliss
rl: https://bravafabrics.com/
这时 facebook 已经知道了我从 https://bravafabrics.com/ 来到了 https://bravafabrics.com/collections/a-moment-of-bliss 这个页面，同时，这个请求会携带 fr=09wX7ui8MrvCh2SIa..BdNoGz.f.F6R.0.0.Belanb.AWXCDx 这个 Cookie。
来到 facebook，当你登录后，facebook 会把刚刚这些 Cookie 和你的 facebook Id 关联起来，然后他就可以好好的分析你的行为了：
- 有人在你的网站上完成了购买。
- 有人注册进行试用，或者以其他方式将自己标识为你网站上的潜在客户。
- 有人在你网站上的购买过程中输入他们的付款信息。
- 有人将产品添加你网站上的购物车中。
- 有人选择特定版本的产品，例如选择某种颜色。
- 有人发起了结账，但没有付款
- …
而如此强大的追踪能力，只需要你复制一段 Facebook Pixel 的 JavaScript 脚本到你的页面上就可以了。而这一切能力就建立在一个小小的 Cookie 的基础上，因为有了这个 Cookie ，Facebook 才能将这些行为与它的账号体系进行关联。
# 无处不在的的 mmstat
再来看一个我们国内的例子，平时我们在国内的搜索引擎或视频网站上搜索到一些东西，然后打开购物网站就可以收到各种你兴趣的相关推荐，这已经是大众习以为常的事情了，各大购物网站、广告商，会通过第三方 Cookie 收集你的年龄、性别、浏览历史等从而判断你的兴趣喜好，然后带给你精准的信息推荐。
比如，我们在浏览百度、优酷、天猫等网站时，都能看到几个 .mmstat.com 这个域下的 Cookie
百度：
优酷：
天猫：
当你在百度、优酷、淘宝等进行一系列的操作时，.mmstat.com 已经悄悄的通过三方 Cookie 把你的个人信息运送到了他们那边。 .mmstat.com 应该就是阿里旗下的大数据营销平台阿里妈妈旗下的域名（只是个人猜测）。打开阿里妈妈首页，可以看到，其号称是更懂消费者的数据金矿，已经建立起5亿用户的身份识别体系。你的每一次搜索、每一次购买、都会让它变的更精准，下一次你就收到更精准的推荐。
当然，三方 Cookie 只是众多获取你喜好信息的一种方式，只不过这种方式更便捷，成本更低。
# 浏览器的策略
最近几大浏览器针对 Cookie 策略的频繁改动，意味着三方 Cookie 被全面禁用已经不远了：
# Firefox、Safari —— 默认禁用
在 Safari 13.1、Firefox 79 版本中，三方 Cookie 已经被默认禁用，但是由于这些游览器市场份额较小，并没有给市场带来巨大的冲击。因为阿里的登录信息是统一存在一个三方 Cookie 下的，淘宝刚开始的处理方式，甚至是弹个框出来，告诉用户手动开启三方 Cookie ：
但是这样的处理方式对于庞大的用户来讲肯定体验是极低的，解决方案可能是先将 Cookie 种在当前域下，所有就有了我们上面的测试结果，淘宝、天猫两个网站需要登录两次。
但是三方 Cookie做的事情远不止这些，等到 Chrome 全面禁用之前，一定要提前作出改变。
# Chrome —— SameSite Cookie
还好由于三方 Cookie 对 Google 的广告业务影响较大，所以其没有立即进行禁用，而是一直陆续修改一些小的策略来对三方 Cookie 进行限制，比如 SameSite
SameSite 是 Chrome 51 版本为浏览器的 Cookie 新增的了一个属性， SameSite 阻止浏览器将此 Cookie 与跨站点请求一起发送。其主要目标是降低跨源信息泄漏的风险。同时也在一定程度上阻止了 CSRF 攻击。
SameSite 可以避免跨站请求发送 Cookie，有以下三个属性：
# Strict
Strict 是最严格的防护，将阻止浏览器在所有跨站点浏览上下文中将 Cookie 发送到目标站点，即使在遵循常规链接时也是如此。因此这种设置可以阻止所有 CSRF 攻击。然而，它的用户友好性太差，即使是普通的 GET 请求它也不允许通过。
例如，对于一个普通的站点，这意味着如果一个已经登录的用户跟踪一个发布在公司讨论论坛或电子邮件上的网站链接，这个站点将不会收到 Cookie ，用户访问该站点还需要重新登陆。
不过，具有交易业务的网站很可能不希望从外站链接到任何交易页面，因此这种场景最适合使用 strict 标志。
# Lax
对于允许用户从外部链接到达本站并使用已有会话的网站站，默认的 Lax 值在安全性和可用性之间提供了合理的平衡。 Lax 属性只会在使用危险 HTTP 方法发送跨域 Cookie 的时候进行阻止，例如 POST 方式。同时，使用 JavaScript 脚本发起的请求也无法携带 Cookie。
例如，一个用户在 A 站点 点击了一个 B 站点（GET请求），而假如 B 站点 使用了Samesite-cookies=Lax，那么用户可以正常登录 B 站点。相对地，如果用户在 A 站点提交了一个表单到 B站点（POST请求），那么用户的请求将被阻止，因为浏览器不允许使用 POST 方式将 Cookie 从A域发送到Ｂ域。
# None
浏览器会在同站请求、跨站请求下继续发送 Cookies，不区分大小写。
