正文
最初,理论上屏蔽广告似乎是有风险的。采用这种技术的网站的案例非常模糊。在2016年8月,一位来自拥有Pornhub.com(MindGeek)的公司的员工,开始反对Chrome API添加WebSocket屏蔽功能。依照Alexa的数据,Pornhub是互联网上第63个访问量最大的网站。
BugReplay检查了几个MindGeek的网站,果不其然,他们发现,即使已经安装Adblock Plus插件,也能看到这些来自MindGeek所属的广告网络中的Pornhub广告,被标识位“垃圾广告”。
在下面的截图中,你可以在网页顶部看到一个横幅,表明该网站已发觉用户使用了广告屏蔽插件,并邀请用户订阅收费广告免费版的网站。在网页的右侧你能看到广告。
他们是如何做到的?
当用户访问Pornhub.com时,它会尝试检测您是否有广告屏蔽插件,如果检测到一个,它就打开一个WebSocket连接,作为传递广告的备份机制。
查看BugReplay浏览器记录:
https://app.bugreplay.com/shared/report/938a04d2-546c-42e9-87d2-ec4f0f7a792f#/view
你可以看到多个网络触发请求,被AdBlock阻止了:它们在网络流量中被标记为「失败」,如果你单击详细信息中的一条,你能看到失败原因是:net::ERR_BLOCKED_BY_CLIENT. 这是Chrome阻止资源加载时报告的错误。
你可以在网络面板中单独找到WebSocket框架,或者只查看WebSocket创建请求。WebSocket连接的域名是:「ws://ws.adspayformy.site.」,这不过是针对广告屏蔽插件的玩笑而已。
当WebSocket加载时,浏览器为每个可用于广告的点发送一个带有JSON编码有效载荷的帧。检出一个WebSocket框架,你可以在框架数据中看到广告数据被返回:
-
在zone_13,JavaScript应放置广告。
-
在media_type的图像,让页面知晓用哪种元素来创建(大多数是视频广告,在这篇文章我选择了一张图像,因为这样相对温和)。
-
图像本身是base64编码的,因此可以使用data uri scheme来重建。
-
一个「img_type」(「image/jpeg」)通过data uri。
广告屏蔽插件主要是用webRequest API进行工作的,因此通过在WebSocket上利用base64编码来传输数据构建广告,是一个绕开广告屏蔽的相当聪明的方式。
下一步是什么
2016年10月25日,在Chromium Tracker上,一名贡献者写了一个补丁,增加了使用webRequest API来阻止WebSockets的能力。如果这个补丁被接受,将会集成到Chrome stable版。见:
https://bugs.chromium.org/p/chromium/issues/detail?id=129353#c77
广告屏蔽插件作者可以选择在何时或何时推出最新版本的Chrome浏览器,以便让内容提供商(如Pornhub)了解他们在广告屏蔽战争中的下一步行动。
更新
自从BugReplay开始研究这个技术时,AdBlock Plus和uBlock Origin已经发布解决方法来阻止这种技术,而AdBlock和其他人还没有。
对于AdBlock Plus而言,包装器在发送/接收WebSocket消息之前执行虚拟Web请求。扩展将这些虚拟Web请求识别为表示WebSocket消息。如果应该阻止相应的WebSocket消息,它就拦截并阻止它们。然后WebSocket包装器基于虚拟web请求是否被阻止来决定允许/阻止WebSocket消息。
对于uBlock Origin来说,他们发布了一个解决方法,具有“使用CSP指令来屏蔽WebSocket的能力”。