例如，对于一个普通的站点，这意味着如果一个已经登录的用户跟踪一个发布在公司讨论论坛或电子邮件上的网站链接，这个站点将不会收到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浏览器停止运行此脚本，那么你可能要连续很多天盯着一个你永远也不会去点的广告，或者你会持续看到一个你已经购买过的产品广告。
