close
The Wayback Machine - https://web.archive.org/web/20231122000943/https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-asked-questions-%28FAQ%29
Skip to content

Frequently asked questions (FAQ)

Jump to bottom
Raymond Hill edited this page Nov 17, 2023 · 39 revisions
Clone this wiki locally

Frequently asked questions (FAQ)

Under construction

uBO = uBlock Origin. uBOL = uBlock Origin Lite.

If I install uBOL, will I see a difference with uBO?

Maybe. Maybe not. It depends on:

  • Websites you visit
  • How you configured uBO
  • How you configured uBOL

In short, only you can tell.

It's very possible that the sites you visit do not require any of the filtering capabilities specific to uBO, in which case you won't see a difference.

Also, mind that by default there is no cosmetic filtering or scriptlet injection in uBOL (webextensions #362), while these occur by default in uBO. In uBOL, you will have to raise the blocking mode to either Optimal or Complete to benefit from cosmetic filtering and scriptlet injection.

Furthermore, uBOL requires the default mode to be Optimal or Complete for some advanced filtering capabilities to take effect, while they are enabled by default in uBO (see Filtering capabilities which can't be enforced without broad read/modify permissions).

Is uBOL more efficient CPU- and memory-wise than uBO?

In truth, only benchmarks with proper methodology can really answer that question, otherwise it's all speculations. Given the difference between MV2 and MV3 extensions, a proper methodology would require to measure overall CPU and memory usage when loading actual webpages from real websites when both extensions are configured to act in a similar way.

At the moment, Firefox's implementation of declarativeNetRequest API is JavaScript-based and does not appear to be particularly optimized (see bugzilla 1853569). Chromium's implementation is C++-based.

Keep in mind that uBO's own JavaScript-based filtering engine has been measured to be faster than a well-known Rust-based filtering engine.

Filtering capabilities which can't be ported to MV3

Because the declarativeNetRequest API does not support the ability to enforce rules according to the top context, i.e. the URL in the address bar, the following capabilities can't be supported:

The declarativeNetRequest API does not allow to filter according to the content of response headers, thus not possible:

The following filter options can't be translated into DNR rules:

CNAME-uncloaking is up to each DNR implementation; no DNR implementation supports this capability at the time of writing.

Filtering capabilities which can't be enforced without broad read/modify permissions

The following modifier filter options can't be enforced without broad read/modify permissions, i.e. when default mode is Basic: redirect=, removeparam=, csp= (webextensions #169), permissions=. They will be enforced when default mode is either Optimal or Complete.

For instance, this explains why the rule count of AdGuard URL Tracking Protection is zero in Basic mode, since the whole ruleset consists of removeparam= filters.

When do filter lists update?

When the extension updates to a new version (webextensions #112).

There are no filter lists proper in uBOL. There are declarative rulesets and scripts which are the results of compiling filter lists when the extension package is generated. Those declarative rulesets and scripts are updated only when the extension itself updates. As a result, uBOL never makes network requests to any remote servers.

Is the limit on maximum number of DNR rules an issue?

Not really at this point. Special attention has been given to generate the smallest amount of rules when compiling filter lists into rulesets at extension build time.

The current limit imposed by the various implementations is 30K.

The default ruleset in uBOL hovers around 17K when using Optimal or Complete mode (less in Basic mode).

When also enabling all five Annoyances rulesets, three Miscellaneous rulesets, and one large regional ruleset, the total number of DNR rules is still under 30K. At that point the issue becomes more the limit on the maximum number of enabled rulesets, which is currently 10 at the time of writing (webextensions #318).