Manifest V3 对于 AdGuard 来说完全是大顺风的优势, 因为它们不靠浏览器扩展盈利, 而是靠客户端程序许可. 虽然浏览器扩展几乎能应对 80% 的拦截需求, 但 Google 起了一个底, YouTube 开了个头, 对浏览器扩展的限制越来越大, 虽然 MV3 不是为了针对广告拦截器而设下的, 但来自 Chromium 主线的推动足够开始改变很多东西. 对广告拦截的目标也应该尽快提升到内容拦截.

AdGuard 是商业化运作的软件公司, 创办于俄罗斯莫斯科(虽然目前总部已经迁到塞浦路斯), 旗下的所有免费产品都是开源的, 包括浏览器扩展, AdGuard Home 和 Android 专用内容拦截器. 它们的主要营利产品是: AdGuard 客户端, 私人 DNS, VPN.

对浏览器操作了如指掌的电脑玩家绝对不会落下广告拦截器插件, 但要真正将广告拦截运用自如就要更加深入地了解了广告拦截器, 否则最后只能靠其他人写的过滤器规则来拦截自己看到的广告. 当广告拦截器和互联网广告主的对决开始, 这种滞后性会变得非常突出, 况且广告主自己还控制着浏览器内核的主导权呢?

第一个网页广告和第一个广告拦截器几乎是统一时间出现, 自上世纪九十年代至今, 广告和广告拦截器的对决从没有停止过. 但是互联网广告诞生至今已经变得越来越多样, 而广告拦截器似乎始终以浏览器扩展插件为阵地, 这种滞后的局面何时才能迎来转变? 如果说在浏览器里用浏览器扩展拦截广告就是在 "八角笼" 里和广告公平互殴, 偶有优势. 但似乎已经让人忘记了, 这场广告和反广告的比赛的目的本应该是让我们保持主动并占据上风且不将对手打垮, 而不该是在对手的规则里展开他口里的 "公平对决".

笔者将依照自身亲身经验分析市场上最流行的, 依靠广告拦截而商业化运作的公司 AdGuard 的主要产品的特性, 得出它们产品的相对如今其他流量广告拦截器之间的区别, 以及存在的独特优势和依旧存在的局限性.

比赛在即, 裁判却决定将跑道越缩越窄, 以前在赛场上还能靠人数优势, 前赴后继接力才能和另外骑着自行车的选手一较高下. 但现在跑道越来越窄, 人数优势变得越来越小, 回头发现对手的自行车已经早就换成了摩托, 细看之下, 这位选手似乎和刚才还在闲聊的裁判长得似乎有点相似... 比赛开始了, 你应该如果取胜?

内容拦截类

内容拦截是 AdGuard 主线产品的核心功能, 它们又分为浏览器扩展和客户端两类, 按照对过滤器特性的兼容性, 可以得出其内容拦截能力的高低:

"CoreLibs Apps" 是指使用闭源库 CoreLibs 开发的 AdGuard 客户端, 目前在 Windows, MacOS 和 Android 进行了适配和发行, 是付费产品.

基础修饰符兼容性

如果只使用基础的规则和修饰符, 那么基本上它们之间除了来自浏览器内核和程序访问能力的限制外, 没有什么区别.

但是如果过滤的需求范围来到了浏览器扩展的能力范围之外, 区别就开始逐渐显现. 以下是 AdGuard 内容过滤规则高级修饰符的兼容性对比:

高级修饰符兼容性

看起来优势也并不多? 但别忘了, 现在对比的范围已经离开浏览器这个约束范围了, 浏览器扩展和 CoreLibs 应用已经处于不同的应用层面.

对内容的 "拦截" 开始过渡到 "重写" 和 "替换" 时, 就需要深入到传输层. 目前在传输层才能实现的高级修饰符有:

  • $hls: 移除 HLS 列表中的内容片段.

  • $jsonprune: 移除 JSON 响应中的片段.

  • $network: 阻止特定 IP 的连接.

  • $referrerpolicy: 替换页面的 referrer 策略(Referrer-Policy).

  • $replace: 使用正则表达式替换响应内容中的字串符.

如果需要让 AdGuard 实现这些功能, 或者需要在浏览器之外继续过滤内容, 那么就需要使用基于 CoreLibs 的 AdGuard 客户端.

AdGuard 浏览器扩展

这里的浏览器扩展仅指能够独立实现内容拦截的浏览器扩展.

这是对抗同类产品而设置的「守门员」, 免费且开源, 它的目标应当是引导用户去购买它们的付费产品. 与 uBlock Origin 之类的浏览器扩展来说并没有突出的优势, 在本章节开头的规则兼容性对比中就能看出, 浏览器扩展能力范围的拦截任务与其他流行的内容拦截扩展并没有什么独特优势. 但是文章如开头所说, MV3 的推进可能会改变这类扩展的格局.

局限性

虽然浏览器扩展适配了主流的浏览器, 但实际上由于浏览器内核的限制, 只有 Chrome, 类 Chromium 和 Firefox 的扩展才能实现完整过滤器特性, 而例如 Safari 由于 WebKit 的限制无法实现完整的过滤器特性, AdGuard 也专门为 Safari 版本的 AdGuard 浏览器扩展开设了独立的发布页面:

Safari Release - AdGuard versions

AdGuard 团队也在它们的博客文章中解释了为什么 Safari 中的内容拦截扩展能力受限:

YouTube ads in Safari: why do you see them and can they be removed? - AdGuard Blog

当然这是所有的内容拦截类浏览器扩展都要面对的问题, 如果需要完全限制这一类扩展, 那么就需要在浏览器内核上动手. 比如 Google 起头以 Chromium 为首而计划实施的:

虽然这两个提议并没有人认为就是为了针对广告拦截器, Google 对 Chromium 中实现 Web Environment Integrity 的计划也已经破产. 但很明显, 广告主对如今的广告拦截器很不满意, YouTube 也突然开始了反广告拦截器的行动. 虽然它肯定不是第一个反广告拦截的, 但 YouTube 的背后恰好还是 Google.

YouTube's Crackdown Spurs Record Uninstalls of Ad Blockers | WIRED

连 FBI 都推荐使用广告拦截器去拦截搜索引擎中搜索结果的广告, 很明显这场「战斗」已经变得异常胶着, Google 的身影已经变得无处不在, 毕竟 Google 的大部分收入都是靠广告.

如果不能阻止浏览器扩展拦截浏览器广告, 那么就离开浏览器, 比传统网页更适合广告的是移动互联网.

AdGuard 客户端

AdGuard 的客户端是相对于浏览器扩展而强化内容过滤能力的独立应用, 它实际上更类似于一个工作在浏览器之上的专用防火墙. 在使用 HTTPS 过滤前, 它的过滤能力还不如浏览器扩展, 因为浏览器中的扩展一样都工作在 OSI 模型中的第七层: 应用层, 并且它独立于浏览器也无法使用浏览器扩展才能使用的的 API. 此外如果不使用过滤功能, 它也还能仅充当 DNS 代理客户端.

当配置完成 HTTPS 过滤, 系统默认信任来自 AdGuard 客户端的 SSL 证书后, 此时的它就开始使用 MiTM(中间人攻击) 的方式进行内容过滤, 工作方式开始介入 OSI 模型中的第四层: 传输层. 对仅使用 HTTPS 加密的流量实行完全的解密, 过滤和重写.

AdGuard for Windows 中的 HTTPS 过滤配置界面

桌面客户端与之配套的有一个用于控制客户端的浏览器扩展, 名叫 "AdGuard 浏览器助手", 可以在浏览器里控制外部客户端对指定站点的过滤, 还能充当元素选择器生成规则即时拦截广告元素.

与 AdGuard 客户端配套的浏览器扩展

闭源之路

AdGuard 客户端目前仅在 Windows, Mac 和 Android 操作系统适配并发行. 它们都是基于的闭源库 AdGuard CoreLibs 开发的闭源产品.

要注意的是, 目前 AdGuard 的 iOS 客户端只是用于应对移动端 Safari 内容拦截的应用, 它作用类似于 Safari 浏览器扩展, 定位接近于 Android 平台的「内容拦截器」, 它也不开源, 也不是基于 CoreLibs 开发的产品. 因此现在 AdGuard 唯一支持全功能过滤的移动端应用只有 Android 平台.

规则优先

客户端在多平台都有实现和发行, 它的过滤能力也完全取决于规则. 虽然客户端中有许多功能都是能以开关或选择的形式让用户轻松就能使用, 比如 DNS 代理, 隐形模式和浏览安全等模块, 但这些功能实际上都与内容拦截没有关系, 它们并不能帮助用户拦截更多的广告, 更多的只能算是一种加强上网安全和隐私的附加功能.

为了让不精通技术的用户也能轻松使用客户端, 在 DNS 过滤器和内容过滤器的都添加了可供用户直接选择并使用的过滤规则订阅, 并且客户端安装完毕实际上就默认启用了数个 AdGuard 直接负责维护的过滤器订阅. 这种配置能够应对绝大多数的内容过滤的需求.

以规则为核心实现过滤的客户端中, 有两种类似但并不完全相同的 AdGuard 规则:

  • DNS 过滤规则
  • 内容过滤规则

前者仅作用于 DNS, 在 DNS 层面的域名解析过滤拦截和重写. 后者作用于 HTTP 和 HTTPS, 对应用的请求和内容进行过滤拦截和重写, 它们使用相似的规则语法, 主要区别在于修饰符, DNS 过滤规则语法中拥有与其能力符合的独有修饰符, 比如 $dnstype 和 $dnsrewrite, 详见 DNS 过滤规则文档:

DNS 过滤规则语法 | AdGuard DNS Knowledge Base

又由于 DNS 规则语法几乎与内容拦截规则相同(除了部分修饰符), 所以基本上来说 DNS 过滤规则也能直接当作内容过滤规则使用. 在实际使用的时候, 如果能够在 DNS 请求时就能将内容进行拦截, 那么就应该优先使用 DNS 过滤.

过滤行为

本节开头说过, AdGuard 客户端实际上是一个防火墙. 但目前在 Windows 上只会选择性过滤在其设置中加入过滤名单中的应用程序, 客户端会默认添加部分常见的需要过滤的引用程序, 比如各种浏览器(Edge, Chrome/类 Chromium, IE), Steam, Potplayer 等等. 如果需要过滤不在其中的应用程序, 那么就需要手动添加到名单中, .

选择性过滤的名单

在 Android 平台上略有不同, AdGuard 的 Android 客户端是一个更全面的防火墙, 不仅支持网络访问控制, 还会默认对所有应用程序进行过滤, 包括新安装的甚至系统应用, 而 MacOS 上的 AdGuard 过滤行为介于 Windows 和 Android 之间, 这是由于不同操作系统使用的不同过滤技术导致的:

基本上来说, AdGuard 所有已实现并发行的客户端中, Android 和 MacOS 都在使用 VPN 或类 VPN 的方式过滤网络流量, 这在配置完成 HTTPS 过滤的情况下能够提供最全面的过滤特性和效果. 但 Windows 是一个例外, 如果没有在名单之中的程序就不会被过滤, 即使现在使用的 WFP 技术完全能够直接做到防火墙一样的控制, 但不知道为什么没有做. 不过在 Windows 客户端的 GitHub Issue 队列中, 过滤全局的流量已经被提上 v8.0 版本的日程, 而且优先级非常高(P2):

Filter All Traffic By Default · Issue #4732 · AdguardTeam/AdguardForWindows - GitHub

局限性

面对深入到传输层的内容拦截, 难道就是广告拦截的万能钥匙了吗? 并不, 如果了解了 AdGuard 实现过滤的方式就能「反击」:

  • SSL 证书验证: HTTPS 过滤依赖 SSL 证书, 应用可以实行证书验证, 比如常见的 HPKP(HTTP公钥固定) 和证书透明度(CT)检查.
  • 重新编码或使用加密协议: AdGuard 虽然能够解密 HTTPS, 但目前无法对解密后的响应或请求再次解码, 只需要对重要的响应内容进行二次编码, 即使是 base64 都能够使用于处理数据的过滤器规则失去作用. 或者进一步直接使用加密协议, 在端对端加密盛行的今天, 这也是很常见的做法.
  • 提前代理流量: 应用能够直接内置 VPN 或其他技术的流量代理, 在流量到达拦截器之前进行伪装或加密. 当然任何应用也能做到要求用户通过 VPN 才能访问对应的网络资源.

专用内容拦截器

专用内容拦截器主要是指通过其他软件提供的 API 而非通过系统网络流量进行针对性内容拦截的拦截器, 虽然 AdGuard 自己只把 Android 上还存在于 Google Play 上的那款 AdGuard 叫做 "内容拦截器"(目前仅适用于三星浏览器和 Yandex 浏览器). 实际上 iOS 平台的 AdGuard 客户端也是这类专用内容拦截器, 因为它只能用于 Safari 浏览器内的内容拦截, 通过规则修饰符的兼容性来看, Android 专用内容拦截器是所有 AdGuard 内容拦截器中效果最差的, 其次就是 iOS 客户端和 Safari 浏览器扩展(两者一模一样).

在 Google 的 Manifest v3 执行后, 浏览器扩展类的内容拦截器按照运行方式或许应该也要被归类为专用内容拦截器. 不过在浏览器内这种特定环境下, MV3 的浏览器扩展拦截器对过滤规则修饰符的兼容性依旧比现有的专用内容拦截器好得多.

AdGuard DNS & AdGuard Home

AdGuard DNS 是由 AdGuard 托管的私人 DNS 服务, 同类产品有 NextDNS, RethinkDNS, NovaXNS. 提供 DoT, DoH, DoQ 加密 DNS 服务, 可设置自定义的 DNS 过滤规则. 计费方式是订阅制, 也提供免费使用的基本层.

同宗同源不同样

AdGuard Home 是 AdGuard DNS 依赖软件的简化版, 它们都基于相同的开源库, 但在其基础上构建的产品一个是闭源的专有软件, 一个是使用 GPL 3.0 开源许可发行的自由软件. Home 是供自托管使用的 DNS 中继服务器软件, 对个人和家庭局域网环境还提供了 DHCP 服务器的功能, Home 支持几乎所有的传统和现代安全 DNS(除了 DNSCrypt): 明文, DoT, DoH, DoQ; 支持 DNSSEC, RDNS 和 ECS 扩展. 同样 Home 也支持自定义 DNS 过滤规则, 甚至能够订阅 DNS 过滤规则列表(闭源产品 AdGuard DNS 仅支持订阅通过验证的列表). 虽然 Home 是 AdGuard DNS 的简化版, 但并不是用来和它竞争的对手, Home 仅提供软件, 而 AdGuard DNS 是一整套的解决方案, Home 经常被拿来比较的对手是 Pi-Hole.

如果只是内容拦截

DNS 简单又脆弱, 是网络攻击中经常被针对的互联网基础设施. 它是人类访问互联网的必经之路, 为了让 DNS 正确无误且安静地工作, 延伸出了很多安全 DNS 协议, 发展到现在 DoH(H2/H3) 和 DoQ, 也终于在速度, 安全和易用之间达到了平衡. 由于大部分的广告, 追踪和恶意内容为了在线上传播也要依靠 DNS, 所以基于 DNS 最初原型 "Hosts 文件" 衍生发展出了如今的 DNS 过滤规则, 对通过 DNS 的恶意域名进行错误的 DNS 响应, 这样就能针对性地利用 DNS 的特性实现了粗略的内容拦截功能.

所谓粗略, 因为 DNS 只能对域名进行作用, 如果所有的广告都用自己的独特域名, 那么在 DNS 层面进行内容拦截早该屡试不爽. 但实际情况是越来越多的恶意内容被掺杂在正常的域名中进行请求和响应, 更有的广告直接被写在了请求响应中, 和正常内容混杂在一起. 对于这种情况如果还使用 DNS 进行拦截只会 "杀敌一千自损八百", 破坏整个在线服务体验的完整性.

DNS 设计之初并没有考虑内容拦截, 它只是恰好能做到在应用层进行 "疏" 和 "堵" 的系统而已.

早年的 HTTP 时代, DNS 非常容易被 "污染" 导致流量被劫持传输恶意内容, 并且难以被及时发现. 后来 TLS/SSL 让 HTTP 进化到了 HTTPS, 结合 CA 证书链已经很少让 DNS 污染导致流量劫持难以察觉了. 到了如今 "合法" 的恶意内容盛行的现代互联网, DNS 劫持开始被部分互联网用户反向利用来针对这些恶意在线服务的域名, 也促使诞生了 AdGuard DNS, NextDNS, Quad9 等等一类 "安全 DNS", 这些依旧是内容拦截对抗广告的一个战场, 只是战况不太激烈而已. DNS 也随着 HTTP 进化, 越来越难以被干扰, DNS 查询特征也变得越来越隐秘, 大多数的操作系统甚至应用都开始内置 DNS 客户端进行独立的 DNS 查询.

AdGuard VPN

这可能是相对同类竞争对手来说最没有特色的产品, 市面上的 VPN 已经早就变得泛滥. AdGuard 的 VPN 并没有被宣传为突破审查, 突破封锁, 也没有标榜流媒体专用, 也没有明说可以用于 P2P 传输. 对于这类产品的爱好者来说, AdGuard VPN 几乎不会被考虑, 更多的时候是和 AdGuard 的其他产品捆绑销售, 比如 AdGuard DNS. 当然, 在 AdGuard 品牌和营销的加持下, 也会变成泛泛之辈中值得留意的选择.

AdGuard VPN 自一开始就没有选择主流的协议, 而是使用了自己开发的新协议, 他们也在自己的文章中表示了自己的独特协议具有的优势, 并且表示相比其他协议更难以被探测.

协议如何运行：深入了解独特的 AdGuard VPN 协议 - AdGuard VPN Blog

但是, 在众多加密网络代理协议的实践下证明: 私有协议难以被检测不是因为它完美无瑕, 只不过是因为这种协议普及程度不及针对性检测和封锁的必要性. 笔者并不认为 AdGuard 会加入这场猫鼠游戏之中, 把它当作是自卖自夸的口号足矣.

AdGuard 也在他们客户端系列产品中加入对 VPN 产品的联通, 在移动设备上和桌面设备上 AdGuard 客户端和 AdGuard VPN 相互配合使用也比其他的 VPN 组合更顺畅一些.

这类平庸的 VPN 产品最大的对手应该是 Cloudflare Warp, 以及各类安全产品中提供网络保护用途的 VPN, 比如 Apple One 提供的 VPN, Google One 提供的 VPN; 以及传统反病毒公司 Norton(诺顿), Kaspersky(卡巴斯基)在高级订阅套餐中提供的网络保护功能. 对于软件集成, 交互体验和服务体验, 这些实力干瘪的独立 VPN 服务几乎没有优势(或许独立销售也是种优势).

有趣的事实

Google, Amazon 和 Apple 拒绝上架 AdGuard 客户端的原因是相同的

现在去 Google Play, Amazon Appstore 和 App Store 上下载 AdGuard 是不可能下载到包含全功能的 AdGuard 客户端的.

Amazon Appstore 是 Amazon(亚马逊) 运营的一个 Android 软件商店, 类似于 Google Play.

2014 年开始到 2018 年的 5 年间, 三家主要的移动应用商店先后实行了新政策使得 AdGuard 的全功能客户端被迫下架, 这三位给出的政策理由如出一辙: 干扰或阻止其他第三方应用程序显示广告的应用程序不会被允许上架.

所以, 很久之前, 至少 2018 年以前, iOS 版本的 AdGuard 都能和如今的 Android, MacOS, Windows 版本的 AdGuard 一样进行系统层面 HTTPS 过滤, 那时的 AdGuard Pro for iOS 对于 AdGuard for iOS 来说的确是具有更高级功能的版本. 但如今的 App Store 上的两个 AdGuard 客户端都只是 Safari 专用的内容拦截器而已.

这三家控制着全球移动应用发行的巨头不仅是软件或硬件巨头, 更是广告巨头, 他们比任何软件开发者都清楚广告到底对自己, 对互联网究竟意味着什么.

起源于俄罗斯的麻烦

互联网不是一个独立于现实世界的虚拟世界, 因此互联网产品也无法完全摆脱来自现实世界的引力, 特别是现实之中来自人的恶意.

起源于俄罗斯的 AdGuard 很早就明白了这一点, 他们在 2009 年成立公司的 5 年后就将总部迁移到了欧洲的塞浦路斯, 一方面为了避免原始身份的猜疑, 另一方面也趋近了来自政策层面对它们主营业务的适宜: GDPR.

除去一些人尽皆知的商业和资本考量, 塞浦路斯本身的地理位置和政治占位也是商业公司总部的好选择之一, 特别是经营全球性产品的公司.

AdGuard 虽然运营的位置变化了, 但运营和开发的人员依旧不少是俄罗斯籍的, 这一点无法轻易改变.

时间来到了 2022 年, 乌俄战争又让这个隐患爆发, 这场战争不仅卷入了士兵和平民, 还包括无数与这两个国家直接或间接关联的其他国家, 无数人被要求表态, 被要求站队, 现实的战争动员了一场互联网的战争, 没有人知道他们的动机和目的.

来自乌克兰的软件公司 MacPaw 运营的 MacOS 软件套装订阅服务 Setapp 在 3 月 10 日突然告知用户, "为了应对俄罗斯对乌克兰的入侵" Setapp 在他们的软件套装中下架了 AdGuard, 意味着订阅 Setapp 的用户无法再获得 AdGuard 的授权, 随后有用户表示需要 AdGuard 尽快解决这个 "俄罗斯问题":

AdGuard needs to address the Russian issue now : r/Adguard - Reddit

当天 AdGuard 团队就发表了事件回复, 表示在这个时间前订阅了 Setapp 的客户可以凭收据兑换为期一年的 AdGuard 个人许可:

虽然 AdGuard 很早(2 月 25 日)就对乌俄战争的话题发表了看法, 表示希望尽快结束战争, 因为乌克兰有他们的支持团队以及他们的家人和朋友:

Announcement on the Topic of the War in Ukraine : r/Adguard - Reddit

而 Setapp 自此之后也就没有了回应, AdGuard 自 2020 年加入 Setapp 订阅一直到该事件, 没人会意想到会闹出这样的问题.

之后过去了 6 个月, 事态依旧如此. 有 Mac 用户发现 Setapp 运营公司 MacPaw 开发的某款 MacOS 文件清理软件(CleanMyMac X)还将 AdGuard for Safari 例为了 "可疑" 软件, 并且明确显示了这是由于 "该软件由俄罗斯人开发或拥有" 导致:

Is AdGuard Spyware? | MacRumors Forums

Is AdGuard Spyware?

"这些应用程序与俄罗斯或白俄罗斯的开发商有关联或归其所有, 政府当局可以根据请求直接访问他们的数据, 而无需法院命令."

直到现在, Setapp 也没有任何表示, 他们的订阅软件列表中依旧没有 AdGuard.

结语: 内容拦截的「无限战争」

广告拦截已经从最初的 Hosts, DNS, 到达了浏览器扩展. 如今越来越复杂和无孔不入的广告和追踪证明 DNS 层面的过滤只是一种越来越难起到作用的手段, 直到浏览器扩展的出现大多数人都度过了和广告相安无事的几年, 直到一些隐私和安全的话题把广告拦截升级成一种意识上的正义, 广告拦截自此变得广泛, 更应该用 "内容拦截" 来形容. 从田园年代的贴片广告到现在的 Cookies, 追踪器, 侵入式内容, 深度包检测, 内容拦截逐渐从被动接受后清除, 变为主动从网络层面直接剔除和修改, 内容拦截的深度和广度已经不是如今的浏览器扩展能够完全胜任的了, 很多的 "广告" 已经从浏览器逃离, 藏进了更深的地方, 藏进了浏览器内核, 藏进了操作系统, 藏进了智能家居, 藏进了网络运营商...

内容拦截对互联网用户来说意味着一种选择的主动权利, 能够选择「我愿意看到什么」和「我希望给你什么」的权利. 如果隐私是种资产, 那么资产所有者理应拥有控制资产和把它作为交易「筹码」进行讨价还价的权利, 在主动出让之前不应该被无缘无故浪费和挟持. 如果互联网完全赋予了用户这种权利, 那么内容拦截器自然就没有了存在的必要, 可惜现在它的必要性已经越发凸显, 甚至多次推到了风口浪尖.

即使是如今采用更加激进过滤手段的 AdGuard 客户端, 依旧还在和 "广告" 苦斗着, 除了软件开发者还有无数默默无闻的过滤器规则维护者, 虽然苦战没有尽头, 但证明了浏览器扩展之后的下一代内容拦截技术或许应该是: MiTM 代理过滤.

虽然不完美, 甚至手段可能遭人质疑正当性, 但至少现在有了新的办法, 并且是有效的.

那么在这之后, 内容拦截技术的下一代又会是什么呢?