Jump to content
Piriform Community Forums

ublock users

Recommended Posts


Comment 23 by rh...@raymondhill.net, Yesterday (32 hours ago)

In the design document, it is said that the webRequest API will no longer allow to be used in blocking mode:

> In Manifest V3, we will strive to limit the blocking version
> of webRequest, potentially removing blocking options from most
> events (making them observational only). Content blockers should
> instead use declarativeNetRequest (see below). It is unlikely
> this will account for 100% of use cases (e.g., onAuthRequired),
> so we will likely need to retain webRequest functionality in
> some form.

From the description of the declarativeNetRequest API[1], I understand that its purpose is to merely enforce Adblock Plus ("ABP")-compatible filtering capabilities[2]. It shares the same basic filtering syntax: double-pipe to anchor to hostname, single pipe to anchor to start or end of URL,  caret as a special placeholder, and so on. The described matching algorithm is exactly that of a ABP-like filtering engine.

If this (quite limited) declarativeNetRequest API ends up being the only way content blockers can accomplish their duty, this essentially means that two content blockers I have maintained for years, uBlock Origin ("uBO") and uMatrix, can no longer exist.

Beside causing uBO and uMatrix to no longer be able to exist, it's really concerning that the proposed declarativeNetRequest API will make it impossible to come up with new and novel filtering engine designs, as the declarativeNetRequest API is no more than the implementation of one specific filtering engine, and a rather limited one (the 30,000 limit is not sufficient to enforce the famous EasyList alone).

Key portions of uBlock Origin[3] and all of uMatrix[4] use a different matching algorithm than that of the declarativeNetRequest API. Block/allow rules are enforced according to their *specificity*, whereas block/allow rules can override each others with no limit. This cannot be translated into a declarativeNetRequest API (assuming a 30,000 entries limit would not be a crippling limitation in itself).

There are other features (which I understand are appreciated by many users) which can't be implemented with the declarativeNetRequest API, for examples, the blocking of media element which are larger than a set size, the disabling of JavaScript execution through the injection of CSP directives, the removal of outgoing Cookie headers, etc. -- and all of these can be set to override a less specific setting, i.e. one could choose to globally block large media elements, but allow them on a few specific sites, and so on still be able to override these rules with ever more specific rules.

Extensions act on behalf of users, they add capabilities to a *user agent*, and deprecating the blocking ability of the webRequest API will essentially decrease the level of user agency in Chromium, to the benefit of web sites which obviously would be happy to have the last word in what resources their pages can fetch/execute/render.

With such a limited declarativeNetRequest API and the deprecation of blocking ability of the webRequest API, I am skeptical "user agent" will still be a proper category to classify Chromium.


[1] https://developer.chrome.com/extensions/declarativeNetRequest

[2] https://adblockplus.org/filter-cheatsheet

[3] https://github.com/gorhill/uBlock

[4] https://github.com/gorhill/uMatrix


With such a limited declarativeNetRequest API and the deprecation of blocking ability of the webRequest API, I am skeptical "user agent" will still be a proper category to classify Chromium.



Edited by Winapp2.ini
can't seem to liberate my :lol: from the quote box :(

Share this post

Link to post
Share on other sites

If Google goes through with it I'm glad I only use a Chrome/Chromium clone (SRWare Iron Portable) just for looking at YouTube so it wouldn't be anything to just ditch it since I use Firefox ESR Portable for everything else.

Share this post

Link to post
Share on other sites

Mozilla could end up down this route too:



Manifest v3

“In 2019 we will introduce the next extensions manifest version…We intend to make the transition to manifest v3 as smooth as possible and we’re thinking carefully about the rollout plan.”

In 2015, Mozilla announced we were deprecating our extremely popular extension system in favor of WebExtensions, an API compatible with Chrome, as well as Edge and Opera. There were several reasons for this, but a large part of the motivation was standards — a fundamental belief that adopting the API of the market leader, in effect creating a de facto standard, was in the best interests of all users.

It was a controversial decision, but it was right for the web and it represents who Mozilla is and our core mission. Three years later, while there still isn’t an official standard for browser extensions, the web is a place where developers can quickly and easily create cross-browser extensions that run nearly unchanged on every major platform.

So I would like to publicly invite Google to collaborate with Mozilla and other browser vendors on manifest v3. It is an incredible opportunity to show that Chrome embodies Google’s philosophy to “focus on the user,” would reaffirm the Chrome team’s commitment to open standards and an interoperable web, and be a powerful statement that working together on the future of browser extensions is in the best interests of a healthy internet.

Share this post

Link to post
Share on other sites

Well maybe all those ad blocking developers could get together and make their own web browser, if things go bad with the popular browsers.

Share this post

Link to post
Share on other sites

i hope so...

diversity is good and for "best interests of all users , not the "similarity"



i remember me darkly, since google chrome was rising, firefox runs after googles development... not the best decision and development for the former leader of the browsers i mean.

Share this post

Link to post
Share on other sites

ublock v1.18.0


gorhill released this

Jan 24, 2019



Refactoring of the logger code for performance/efficiency purpose -- the logger output has been decoupled from the DOM.

Additionally, these features were added to the logger:

  • configuration settings
    • multiple criteria can be used for when to discard logger entries
    • ability to hide some columns
  • export-to-clipboard
  • the position and size of the logger-as-a-popup window will be remembered
  • a pause button to stop the logger from taking in new events
  • a new built-in expressions picker to filter the logger output
  • show the hostname of the document which caused the resource to be fetched
  • show the 3rd-partyness of a resource relative to both the page and the document fetching the resource
  • new visual hint to denote tab-less network requests
  • a popup panel button linked to the tab selector

Documentation will be updated eventually to account for those changes.

Closed as fixed




Commits with no entry in issue tracker

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now