uBlock Origin 有 5 个拦截模式：

  • Very easy
  • Easy
  • Medium
  • Hard
  • Nightmare

前两个模式同其他 AdBlock 工具差不多，按照订阅的 3rd-party 过滤列单进行广告过滤，比如 EasyList、EasyPrivacy 等；最后一个噩梦模式，网页几乎没法看；所以，我的选择只在 Medium 和 Hard 之间作出。

Medium 和 Hard 的区别

Medium 和 Hard 两个模式的唯一区别，只是 3rd-party 这一项勾选与否。

  • 3rd-party
  • 3rd-party scripts
  • 3rd-party frames

与 3rd-party 相关的有 3 项，scripts 跟 frames 被单独拿出来，其他的比如 css、iamges 等则包括在第一项未指明的 3rd-party 内。也就是说，Medium 和 Hard 的区别，关键在于是否默认拦截掉所有第三方请求。

Medium 放过除 js、frame 之外的其他请求，让第三方的图片、CSS 等得以加载，尽可能维持网页完整显示；而 Hard 拦截所有的第三方请求，网页残缺可能性更高，这时就需要用户的干预，手动进行允许和拦截，比如 CDN 缓存、用户从各处插入的图片等，uBO 会将这些手动规则记录下来，这是 Dynamic Filtering。

Medium 的问题在于：闸口开的稍宽，虽对网页的破坏性较 Hard 模式稍好，但同时却容易漏过广告、数据监测、以及其他的一些幕后动作，往往需要额外引入一些 3rd-party filters 来捕捉漏网之鱼，比如 EasyList、EasyPrivacy、Malware Domians、Ad and tracking server list 等；此外，很多页面将 js 资源放在其他域下，Medium 模式并不能让这些页面圆满展示。

Hard 的问题在于：闸口开的很小，网页高概率破碎，基本离不开人工干预，需要琐碎的一关一关去放行，逐渐积累自己的黑白名单。

小结：两个模式都离不开人工干预（dynamic filtering）。因为，或多或少，直接拦截了当前站点的第三方资源引用，一遇到资源分流或是 UGC 站点，页面内容总会有所缺失，需要人工干预一次。好处是如果挑的足够细致，会是一个完全自定义的高效规则，毫无冗余。

所以不如直接上 Hard 模式。

但人工干预的层面只有 hostname 和 request type 两块，粒度较粗，所以这两个模式的官方文档都推荐订阅 3rd-party filters 来做最后一道防护。

Dynamic filtering & Static filtering

订阅规则的好处是：巨细无遗，覆盖广，且灵活。Hostname、URL 等形式都支持；拦截、隐藏皆可配置；通配符、正则写法也随便用。

它的问题也很明显：源自于它的好处，成千上万的规则里面，既有你需要的，也有你不需要的（可能更多），影响匹配效率；装饰规则（cosmetic filters）需要操作 DOM，性能负担重。

直接订阅的第三方规则，以及自定义的符合 ABP 语法的 My filters，在 uBO 内，都被称作为 static filtering。

与之对应，uBO 内置的机制还有 dynamic filtering，即 advanced user 模式下的人工干预，包含 dynamic filtering rules 和 dynamic URL filtering rules。两者的区别是：前者应用范围广，对应的是整个网站或者整个请求资源类别；而后者只是匹配特定的 URL。

uBO 的拦截过程如下（引用自官方文档）：

关键：

  • 订阅规则（static filtering，my filters 也算一种订阅）的判定优先级是最低的
  • 非 block 资源，如 action 为 allow，进入绿色通道，直达 remote server
  • 非 block 资源，如 action 为 noop，才往下进入下一个判定环节

也就是说，自定义 dynamic filters 时，除非笃定，否则不要轻易设定为 allow， 因为 allow 会导致后续的关卡完全失效，noop 是一个更保险的选项。noop 虽会多经一步 static filtering，但如果订阅规则精简，相信查询效率不会成为瓶颈。

期望：

  • 拦截：干净、高效
  • 规则：精炼、不冗余

倾向于：自己写一些必要的 ABP 规则，作为 static filtering 的补充，但不订阅推荐的哪些臃肿列表。

组合与取舍

结合访问习惯，再过一遍。内容可分两类：

  • 经常访问的网站，不多：Twitter、Youtube、一些文档站点等
  • 缘分站点：Tweet 内提及的链接、Google 的搜索结果等

应对拦截造成的页面破坏，如果是常访站点，手工挑一次动态规则，也许再补充一点 ABP 规则，工作量也不是太大。而缘分站点，也可以分两类：常见资源被拦截，比如 jQuery、在线字体、Youtube嵌入视频等，应对如上；个体的特殊情况，比如各式子域等，只能临时放开闸门。

那么，这时候的问题还是：需不需要为了这个情况，订阅推荐的几万条第三方规则，用作最后的关口？

如果，即便几万条 static filters，对性能和资源占用的影响也不大，那么加上也没关系，无非是多些冗余。但是，影响大不大，我还不知道。

人工干预的好处

Hard 模式造成的网页破碎，并非全无好处。在手工放行和拦截时，目睹一张网页背后关联的各式服务，好奇心驱使，发现了解了更多东西。

嗯，为了拦截泛滥的网络广告和恶意内容，反而认识到更多的用户服务形式和商业产品，这是人工干预的好处，是乐此不疲的动力。