amoreweb：浏览器屏蔽了，导致广告不能精准推送

历史回顾

在2019年8月，发表一篇文章《 a more web》，在其中说到在当代Web的安全领域中，像一样的为了更精准地为用户推送广告的技术已经背离了它被发明时的初衷而被滥用，浏览器为了用户隐私安全而进行了一些对的屏蔽的行为。而这样的行为又导致了其它替代的技术方案被越来越多地应用（），比如根据用户的设备ID、甚至根据用户设备已安装的字体等来生成用户唯一的ID以追踪用户，达到和一样的效果。这是一个双输的局面，一方面生成的用户ID不能被清除，进而用户无法控制何时清除自己的隐私信息，另一方面因为浏览器屏蔽了，导致广告不能精准地推送，广告商收入大量减少，进而导致互联网开放的环境受到破坏，因为广告商需要通过内容收费来弥补广告收的损失。为了解决这些问题，倡议开发一套新的安全标准，称之为 。

在 中，通过对进行更详细的分类和设置、对进行更激进的阻止等方式，来达到更安全的目标。致力于将这个标准建设为行业标准。

最新进展

在1月14日发布了一篇新的文章《 a more web: A path third party 》，表明将从2月的 80开始执行新的策略，对未设置“”的默认其值为Lax，即三方网站如果使用了该资源，在请求中是不会带上相关的的；对设置为None的，要求必须同时设置，否则拒绝此。

名词解读

下面来解读一下这些具体的名词。

一方与三方

是存储在浏览器中的一些key-value数据，它通过服务器返回的中的Set-来生成。比如：

Set-Cookie: name=value; Max-Age= 2600000; Domain=www.abc.com

这样在后续的请求中，如果域名、未过期等条件都满足，浏览器就会在请求的中带上相关：

Cookie: name=value

在Set-时，可以通过指定该会在发向哪些域名的请求中带上。但这个只能是当前网站的域名、或者比当前网站更父级的域名（/html/#-4.1.2.3）。比如请求的域名是，那么可以设置的域名为：、，而不能设为：、xyz.。另外也不能设为一些公共的域名，比如：com、、co.uk，这是通过一个叫 List（/）的机制来保证的。

为了判断该是否应该被带在请求中，有一个域名比较策略。假设有的域名A、和请求的域名B：

如果A等于B或A是B的子域名，则认为符合，此应该被带上如果Set-时未指定，那么只有A等于B时，才会被带上。

注意对于第二点，说有的浏览器并未这样实现。

同站与跨站

理解两个网站是否为“同一个网站”很重要，判断是否同一网站是通过叫eTLD+1的方式（eTLD = Top Level ），eTLD定义在上述的 List中，+1表示在左侧加一个子域名。eTLD+1实际上表示了“可注册的域名”，在实际中eTLD+1一般是不同的主体注册，所以要视为不同的网站。

所以下列域名都视为同一网站的：

abc.com
x.abc.com
y.abc.com
x.y.abc.com

而这样的请求都是跨站的：

x.abc.com
x.def.com
x.abc.io

根据域名不同，如果的域名与当前用户访问的网站域名为同站，那么此为一方，否则为三方。有可能同一个在网站A中是一方，在另一个网站B中是三方。

这是一个用来决定的可用网站范围的属性。它有三个值：

: 仅限于同站请求Lax: 同站请求，或者跨站的GET的会导致页面URL发生变化的导航行为，包括链接、GET的Form提交。比如在 网站的页面中嵌入了一个链接 ，那么在用户点击此链接时发起的初始请求，会带上中设置为Lax的。而那些设置为的是不会带上的。这种跨站链接还包括像嵌入到邮件中的链接。None: 没有限制，同站及跨站请求中都会带上，与传统的方式一样。

在新的的 的策略中：

如果未设置，那把其值默认为Lax。如果设置=None，还需要同时设置，否则此会被浏览器拒绝。设为之后，其它三方网站对我方网站资源的引用必须使用HTTPS，否则还是不会带上此，这也要求我方网站必须支持HTTPS。

在线测试：

上面两个网站可以用来测试浏览器的具体行为。

假设有和两个网站，通过之前的某些页面逻辑，浏览器中已经存储了如下:

Set-Cookie: abc1=ok; Domain=abc.com
Set-Cookie: abc2=ok; Domain=www.abc.com
Set-Cookie: abc3=ok; Domain=xyz.abc.com
Set-Cookie: abc4=ok; Domain=abc.com; SameSite=Strict
Set-Cookie: abc5=ok; Domain=abc.com; SameSite=Lax
Set-Cookie: abc6=ok; Domain=abc.com; SameSite=None
Set-Cookie: abc7=ok; Domain=abc.com; SameSite=None; Secure
Set-Cookie: abc8=ok; Domain=xyz.abc.com; SameSite=None
Set-Cookie: abc9=ok; Domain=xyz.abc.com; SameSite=None; Secure
Set-Cookie: def1=ok; Domain=def.com

注意下面两个在新的策略下将是不会存在的，因为会被浏览器直接拒绝，在此仅用作举例：

Set-Cookie: abc6=ok; Domain=abc.com; SameSite=None
Set-Cookie: abc8=ok; Domain=xyz.abc.com; SameSite=None

假设当前在这个网站中：

影响

对大多数应用来说，新的策略“just work”，还能防范一些跨站攻击。但如果有以下情况，就需要更新以适配：

对客户端的适配

有的客户端不能正确处理=None的情况，所以服务端代码可能需要根据不同的客户端发送不同的。不支持的客户端在这里可以找到：//same-site/-