The Wayback Machine - https://web.archive.org/web/20240419012724/https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-asked-questions-(FAQ)
Skip to content

Frequently asked questions (FAQ)

Jump to bottom
Raymond Hill edited this page Dec 9, 2023 · 44 revisions

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).

Note that at time of writing, Firefox's DNR implementation does not yet support the domainType property (bugzilla 1797408), which may cause website breakage (example).

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.

More technical details

Injecting content scripts in a non-declarative way is unreliable in MV3 due to fact that extensions are really service workers which can be suspended at any time. By the time a service worker wakes up and proceed to inject the required content scripts through scripting.executeScript API, these content scripts might be unable to accomplish their duty when the webpage has already started loading.

For an extension to be entirely declarative, it must package all the scripts to inject anywhere, the scripting.registerContentScript API doesn't allow injecting code as string, the content scripts must be part of the package.

The userScripts API does allow to inject code as string, but it's impractical as in Chromium-based browsers this requires extra steps by the user to enable the API. In Firefox, the documentation for this API has the following note:

When using Manifest V3 or higher, use scripting.registerContentScripts() to register scripts

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).

What are the upsides of an MV3-based content blocker?

For Chromium-based browsers specifically, MV3-based content blockers will properly filter at browser launch, which is not the case for MV2-based content blockers. Note though that this is not an issue for Firefox MV2-based content blockers, see uBlock Origin works best on Firefox / Browser launch.

Clone this wiki locally