EasyList “瘫痪”,将被迫迁移
为了不被广告打扰,不少用户都会在浏览器中安装广告拦截扩展,如今也有不少浏览器直接内置了这个功能。这些广告拦截工具都是由不同的 "过滤列表" 驱动,这些规则列表可以告诉广告拦截工具应该如何准确地拦截广告。这之中,EasyList 则是最知名、使用最广泛的一个过滤规则,它是一个由社区管理和维护的项目。
AdBlock Plus、uBlock Origin、AdGuard 等广告拦截工具都有在使用 EasyList,甚至是默认就勾选了它。除此之外,还有很多过滤规则是基于 EasyList 演变而来的,基本上等同于只要你在使用广告拦截工具,你就绕不开 EasyList。
几周前,EasyList 的维护者看到了项目的流量出现的几大幅度的增长。整体的流量迅速从每天几 TB滚雪球般增长了 10-20 倍。结果发现,这一激增的来源是来自印度的 Android 设备。在调查了这个问题之后,发现具有广告屏蔽功能的应用程序在滥用 EasyList 的服务器。
- 有(多个)开源的 Android 浏览器,实现了广告拦截功能
- 浏览器是由其他几个在印度非常流行的浏览器分叉而来
- 浏览器有一个非常严重的缺陷,它在每次启动时都会试图下载过滤器的更新,在 Android 系统上,它可能每天都会发生很多次,它甚至可以在浏览器在后台运行时下载更新。
EasyList 本质上就是一个文本文件,可通过以下地址获得:https://easylist.to/easylist/easylist.txt。尽管文件并不大,但是如果你现在尝试下载这个文件,你会发现需要很长的时间才能下载完成。
EasyList 被托管在 Github 上,并通过 CloudFlare 进行代理。不幸的是,CloudFlare 不允许非企业用户使用这么多的流量,现在所有对 EasyList 文件的请求都被扼杀。
虽然 EasyList 尝试了联系 CloudFlare 以获得支持,但后者表示他们无法帮助。为 EasyList 提供服务实际上可能违反了 CloudFlare 的 ToS。
我们看到有很多访问 https://easylist.to/easylist/easylist.txt 的请求,这触发了自动 DDos 缓解。根据在 Cloudflare 被请求的 URL,它也违反了我们的 ToS。所有的请求都是 txt 文件扩展名,这不是一个网络内容。为了使你的用户能够使用 https://easylist.to/easylist/easylist.txt,你需要将这个 txt 文件移到另一个子域,并禁用代理。换句话说,你不能使用 Cloudfiare 来缓存或代理对这些文本文件的请求。
对普通用户而言,此次事件对你是否有影响取决于用户使用的广告拦截工具具体是什么,因为有些广告拦截工具是将过滤列表托管在自己的服务器中,不直接从 EasyList 下载更新。而另一部分广告拦截工具则可能需要切换到镜像域。
目前还不清楚 EasyList 到底会怎么做,但做出的任何改变都将会影响许多其他依赖 EasyList 的开源项目。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
AMD 公开全新光追技术,将很快开源
实时全局照明(Real-Time Global Illumination)是在游戏等性能关键型应用或任何其他有实时限制的应用中实现更加动态和物理真实世界的关键。 现代 GPU 中的硬件加速光线追踪允许对几何体进行任意的交叉查询,这使得在运行时可以完全评估间接照明。不过,为了在不断提高的图像分辨率下保持高帧率,每个像素点只能追踪少量的光线。现有的解决方案,如基于探针的技术,以每帧几条射线为代价,对辐照度信号进行了近似处理,但这样的方式也存在缺少细节,以及对光照变化的反应时间慢的问题。另一方面,虽然重采样技术可以捕捉到更多的细节,但通常会有较差的性能和更多的噪点,对于当前的 PC 硬件和游戏主机来说,采用这样的技术也不切实际。 为了找到一个平衡点,实现高照明保真度,同时保持低运行时开销,AMD 近日提出了一个解决方案,该方案可以动态估计全局照明,而不需要任何内容预处理,从而能够轻松地集成到现有的实时渲染管线中。 AMD 设计了全局照明管线,通过在空间和时间上重复使用照明信息进行采样和过滤,从而充分利用每一个样本,并通过将场景照明持久化在两个不同层次的辐射度缓存中来实现,如下图所示: Scr...
- 下一篇
Ustore存储引擎详解
目录 设计原理 核心优势 使用指导 Ustore存储引擎,又名In-place Update存储引擎(原地更新),是openGauss 内核新增的一种存储模式。此前的版本使用的行存储引擎是Append Update(追加更新)模式。追加更新对于业务中的增、删以及HOT(HeapOnly Tuple)Update(即同一页面内更新)有很好的表现,但对于跨数据页面的非HOT UPDATE场景,垃圾回收不够高效。因此,Ustore存储引擎应运而生。 设计原理 Ustore存储引擎将最新版本的“有效数据”和历史版本的“垃圾数据”分离存储。将最新版本的“有效数据”存储在数据页面上,并单独开辟一段UNDO空间,用于统一管理历史版本的“垃圾数据”,因此数据空间不会由于频繁更新而膨胀,“垃圾数据”集中回收效率更高。 Ustore存储引擎采用NUMA-aware的UNDO子系统设计,使得UNDO子系统可以在多核平台上有效扩展;同时采用多版本索引技术,解决索引清理问题,有效提升了存储空间的回收复用效率。 Ustore存储引擎结合UNDO空间,可以实现更高效、更全面的闪回查询和回收站机制,能快速回退人为“误...
相关文章
文章评论
共有0条评论来说两句吧...