web浏览器停止运行此脚本 当浏览器全面禁用三方 Cookie

web浏览器停止运行此脚本 当浏览器全面禁用三方 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回来web浏览器停止运行此脚本，后端接受到的信号就是这些都是不同用户的请求，所以都会计入UV。同时你在排查问题时，你也无法将用户的行为串联起来，导致排查非常困难。

智能广告推荐消失

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

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

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

无法追踪转化率

当你查看一则广告时，该广告会在你的浏览器中放置一个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、浏览器插件等等

来源：【九爱网址导航www.fuzhukm.com】 免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！