Jump to content
CCleaner Community Forums
hazelnut

ublock users

Recommended Posts

https://bugs.chromium.org/p/chromium/issues/detail?id=896897&desc=2#c23


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

Quote

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.

:lol:


 

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:

https://blog.mozilla.org/addons/2018/10/26/firefox-chrome-and-the-future-of-trustworthy-extensions/

 

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

 

New

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

Chromium

Firefox

Core

Commits with no entry in issue tracker

Share this post


Link to post
Share on other sites

ublock v1.18.8

 

gorhill released this

Mar 13, 2019

 

Emergency fix for Chromium-based browsers, due to an unexpected change in the behavior of webRequest.onBeforeRequest in Chromium 73. Because of this, I will bypass rolling out in stages and everybody will be upgraded to 1.18.8.

Closed as fixed:

Chromium

Share this post


Link to post
Share on other sites

firefox-legacy v1.16.4.10

 

gorhill released this

Mar 15, 2019

 

Change

To get the new "uBlock filters -- Legacy" list, you will have to back up your uBO settings (bottom of Settings pane in uBO's dashboard), then restore them. This will force uBO to discard its internal version of the content of assets.json, which tells uBO where external resources are located.

Share this post


Link to post
Share on other sites

ublock v1.18.12

 

gorhill released this

Mar 26, 2019

 

Changes

The unlimitedStorage permission has been added in Firefox, to bring uBO inline with the Chromium version. As a result, when uBO updates, Firefox will notify you about the new permission:

a

Note that the Chromium version of uBO has declared the unlimitedStorage permission since it was first published in 2014.

Firefox is not yet enforcing this permission, but I decided to add it anyways since Firefox states:

Only ask for "unlimitedStorage" permission if you expect your extension's local data storage to exceed 5MB if it's not going to exceed that amount, don't ask for it.

uBO is already using more than 5MB of storage in its basic configuration.

In a future version, uBO may start to use a "persistent" indexedDB instance for its cache storage to ensure proper functioning of uBO.[1] uBO currently uses a non-persistent indexedDB instance and this may cause difficult to diagnose issues for some users as Firefox may evict uBO's cache storage at any time.

[1] uBO's cache storage is used to store filter lists, their compiled counterparts, and snapshots of various internal data structures for fast launch time).

Closed as fixed:

Firefox

Commits with no entry in issue tracker

Share this post


Link to post
Share on other sites

Anyone getting 3rd party filter update issues with

Chrome Version 73.0.3683.86 (Official Build) (64-bit) and uBlock Origin  v1.18.12 ?

(Could it be that Manifest v3 is getting started ?)

 

FireFox Quantum 66.0.2(64-bit) seems to work fine :mellow:

Share this post


Link to post
Share on other sites
1 hour ago, Hav0c said:

Chrome Version 73.0.3683.86 (Official Build) (64-bit) and uBlock Origin  v1.18.12 ?

I haven't had any issues that I've noticed with SRWare Iron Portable v72.0.3750.0 the lastest version, which is probably best it doesn't try to keep up to Chrome/Chromium by the nanosecond.

Share this post


Link to post
Share on other sites

ublock v1.18.14

 

gorhill released this

Mar 28, 2019

 

Commits with no entry in issue tracker

Share this post


Link to post
Share on other sites

ublock v1.18.16

 

gorhill released this

Apr 3, 2019

 

This is an emergency fix for NanoAdblocker#257. The issue is that whenever an empty hostname was passed to getPublicSuffix.getDomain(), the next call to getPublicSuffix.getDomain() with a valid hostname would return an invalid result. I expect the erroneous behavior to be a rare occurrence, vast majority of calls to getPublicSuffix.getDomain() are with a valid hostname.

Side effects could be that uBO was unable to properly lookup specific cosmetic filters for a site.

Closed as fixed:

Pull requests

Share this post


Link to post
Share on other sites

ublock v1.19.0

 

gorhill released this

May 10, 2019

 

New

New cosmetic procedural operator: :nth-ancestor(x), where x is the distance from the currently selected node. It is effectively a low-overhead equivalent to :xpath(..[/..]*). Using an existing filter as an example:

fastbay.org##.detLink:has-text(VPN):xpath(../../..)

Could be rewritten with the new operator:

fastbay.org##.detLink:has-text(VPN):nth-ancestor(3)

The new operator has a lower overhead as it avoids the need to create and execute XPath expressions.

Closed as fixed

Chromium

Firefox

Core

Commits with no entry in issue tracker

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...