Thread by @gorhill

It is not possible for uBlock Origin ("uBO") to retrofit its matching algorithm into the set-in-stone matching algorithm of the declarativeNetRequest API.

Matching algorithm logic of:

declarativeNetRequest API (Easylist-like filtering):

- if sb and not sa then block

uBO (*simplified* to not drown in details):

- if db then block
- else if not da then
- if sbb or (sb and not sa) then block

Also, I have this long-term goal of having a user's static filters take precedence over 3rd-party static filters:

- if db then block
- else if not da then
- if usbb or (usb and not usa) then block
- else if not usa and (sbb or (sb and not sa)) then block

A proper blocking webRequest API keeps the door opened for all kind of new matching algorithm ideas.

github.com/gorhill/uBlock…

Another big issue for content blockers relying of community-maintained filter lists, consider the level of activity:

github.com/uBlockOrigin/u…

github.com/easylist/easyl…

A declarativeNetRequest API requires a whole extension update to get the latest changes in the lists.

I consider the filter count limits of the declarativeNetRequest API to be crippling as far as uBO is concerned.

My own personal config is ~140K network filters (even though I use uBO's medium mode).

Despite having ~140,000 static network filters to enforce, the static network filtering engine just needs ~12µs/request on average on my side (as per built-in benchmark).

This tiny overhead is an investment, easily recovered back by all the resources not being downloaded from remote servers, and thus not having to be processed by the browser.

So "performance" can't be a good argument for deprecating the blocking ability of the webRequest API.

I am not against the declarativeNetRequest API, and I am not arguing against the stated advantages -- they are legitimate.

I am against the conversion of the webRequest API into a passive one and other changes crippling uBO's ability to seamlessly function as it does now.