当浏览器全面禁用三方 Cookie

dl: https://bravafabrics.com/collections/a-moment-of-bliss
rl: https://bravafabrics.com/

这时 facebook 已经知道了我从 来到了 这个页面，同时，这个请求会携带 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，不区分大小写。

策略更新

在旧版浏览器，如果 SameSite 属性没有设置，或者没有得到运行浏览器的支持，那么它的行为等同于 None，Cookies 会被包含在任何请求中——包括跨站请求。

但是，在 Chrome 80+ 版本中，SameSite 的默认属性是 SameSite=Lax。换句话说，当 Cookie 没有设置 SameSite 属性时，将会视作 SameSite 属性被设置为Lax 。如果想要指定 Cookies 在同站、跨站请求都被发送，那么需要明确指定 SameSite 为 None。具有 SameSite=None 的 Cookie 也必须标记为安全并通过 HTTPS 传送。这意味着所有使用 JavaScript 脚本收集用户信息的请求默认将不能携带三方 Cookie。

然而这个改动并不会造成太大的影响，它只是给各大网站提了一个信号，因为你只需要把你想要发送的 Cookie 的属性手动设置为 none 即可：

真正可怕的是我们将无法直接指定 SameSite 为 None，只能用户自己去选择，这才是真正的默认禁用。

Chrome 也宣布，将在下个版本也就是 Chrome 83 版本，在访客模式下禁用三方 Cookie，在 2022 年全面禁用三方 Cookie，到时候，即使你能指定 SameSite 为 None 也没有意义，因为你已经无法写入第三方 Cookie 了。

当三方 Cookie 被全面禁止

现在，我们想象一下，当浏览器禁用了三方 Cookie，而我们又没有作出任何改变的情况下，会发生什么：

前端日志异常

可能有一天你会突然发现，你的 UV 暴涨，但是 PV 却没有什么变化，那可能是你的打点 SDK 使用的三方 Cookie 被禁用掉了。

这时这个 SDK 将无法在你的域下写入一个三方 Cookie设置默认浏览器失败 可能是受第三方，导致你的每次刷新页面它都会带一个新的 Cookie 回来，后端接受到的信号就是这些都是不同用户的请求，所以都会计入 UV。同时你在排查问题时，你也无法将用户的行为串联起来，导致排查非常困难。

智能广告推荐消失

上面我们提到，广告服务通过你的年龄、性别、行为来推断你的喜好，从而推送给你精准的广告，使用了三方 Cookie 来进行信息追踪的广告主将无法获得你的这些喜好，从而无法推荐给你感兴趣的广告。

这时，广告主只能在你当时的访问环境进行预定义广告，比如你正在访问宠物网站，就给你推荐宠物用品等等。

同时，可能之前广告主还会通过 Cookie 判断你阅读某个广告的次数，一旦你阅读同一个广告多次但是没有发生转化，其就会停止向你推送该广告。或者你已经购买过了这个商品，那你也不会再看到这个广告了。如果没有了频率控制，那么你可能要连续很多天盯着一个你永远也不会去点的广告，或者你会持续看到一个你已经购买过的产品广告。

无法追踪转化率

当你查看一则广告时，该广告会在你的浏览器中放置一个 Cookie，表示你已经看到它。如果随后你进入转化阶段（购买、下载等），广告主们需要能追踪每一个他们投放到你网站上的转化率，这样他们才能计算投放的效果，从而作出优化策略，如果你无法再追踪广告转化率了，那么也很难再进行投放了。

当然，以上只是建立在你没有进行任何改变的基础上，距离全面禁用三方 Cookie 还有一年多的时间，这应该是一个足够的时间让你及时作出应对。

是好是坏

虽然，这对你带来的可能是糟糕的广告体验，但是全面禁用三方 Cookie 对我们用户来讲肯定是一件好事，因为你的信息不会被轻而易举的就被别人追踪了，你的隐私信息也不会容易被泄漏。

然而事情真的那么简单么？贪婪的广告商绝对不会直接放弃对你的信息追踪，首先他们已经对你掌握了足够多的信息，而且三方 Cookie 只是众多获取你信息的一种手段，只不过这种方法更方便简单，为了利益，他们一定会找到更多的替代方案：

使用一方 Cookie 替代 三方 Cookie

如果我们引入了一个三方的 SDK，比如 google analytics ，说明我们对其是信任的，它对我们的信息收集追踪都是在允许范围内的。所以这些 SDK 依然可以使用第一方 Cookie 来完成用户身份标识符。

比如，gtag.js 和 analytics.js 会设置以下 Cookie 用户标识用户信息：

但是设置默认浏览器失败 可能是受第三方，这些 Cookie 并不是第三方 Cookie，而是设在你的域下的第一方 Cookie，比如打开 twitter 的 Cookie 信息：

我们发现 _ga 、_gid 这两个 Cookie 正是设置在其自己域下面的。

如果使用正常的 Set-Cookie 的形式，google analytics 是无法直接将 Cookie 设置到 twitter.com 这个域下面的，而且 google analytics 发起的日志收集请求也无法携带 twitter.com 这个域下的 Cookie。

打开 sdk 的代码我发现里面有使用 js 设置 Cookie 的代码：

并且，收集日志的请求中也又没携带任何 Cookie，而是把这信息带在了参数中：

这样的方式就模拟了使用三方 Cookie 标识用户信息的过程，并且完全可以替代它。总而言之禁用三方 Cookie 对这种三方 SDK 的影响并不大，只要稍微改变一下思维即可。

当然，由于 Safari 和 Firefox 已经全面禁用了三方 Cookie，一些广告营销服务也正在给出使用一方 Cookie 的替代方案，比如 Facebook Pixel：

你允许了其读取一方 Cookie 就意味着它能获取你更多的数据，这意味着你需要承担更大的用户信息泄漏的风险。而且使用一方 Cookie 也不像使用三方 Cookie 那样灵活，在某些场景下也是有很大限制的。

浏览器指纹

三方 Cookie 的主要作用是标识你的身份，从而在你下一次访问时知道你是谁，那么如果有一种技术直接就可以获取你的唯一标识时，那么就不需要再存储 Cookie 了，这个技术就是 “浏览器指纹” 。

“浏览器指纹”是一种通过浏览器对网站可见的配置和设置信息来跟踪 Web 浏览器的方法，浏览器指纹就像我们人手上的指纹一样，每个人拥有一份接近于独一无二的配置。

如果单单拿出一个配置来讲可能很多人和你拥有一样的配置，比如下面的：

Chrome 版本：UTC+8 时间：

如果单独看每个配置，那他们都不能作为你独一无二的特征，但是综合起来看呢？比如就看这三项，三项的配置与你都相同的人的概率就会大大减小了。以上只是一些简单的特征，比如系统版本，浏览器版本，这些只需要一个简单的 navigator.userAgent 属性就可以拿到。

像这样的属性还有非常多个，他们可能来自 HTTP Header、Javascript attributes、浏览器插件 等等