New Update uBlock Origin update thread

[oldschool]

gorhill commented 4 days ago​

Observation: One of the touted benefits of MV3 was faster review process when submitting to the Chrome Web Store. Well so far that is not the case, it's rather slow and the dev build of uBO proper even cleared review while the MV3 version is still pending review despite having no broad host permissions. Hopefully things will get better, but now this is a pain point.

 

[oldschool]

µBO Lite v 0.1.22.9205 release is available from the Chrome Web Store.

Release notes​

• Renamed "uBO Lite" from "uBO Minus"
• Added ability to enable/disable filter lists
• Added support for i18n
• Added support for optional permissions through new button in popup panel. Consequences:
  • Support for specific plain CSS-based cosmetic filtering
  • Support for scriptlet-based filtering:
    • json-prune
    • set-constant
    • abort-current-script
    • abort-on-property-read
• Fixed dark theme issue
• Improved reliability of cosmetic filtering

This version appears to be a significant improvement in overall blocking.

With Steven Black's lists , test results*:

*For reference purposes only

Note: Edited above to show using only built-in and Steven Black's filters.

 

[oldschool]

Here's a nice examination of the current state of MV3 and its implications for µBO Lite:
Chrome extension manifest v3 proposal · Issue #338 · uBlockOrigin/uBlock-issues

gorhill commented 4 days ago •
edited​

Technical notes following a ~2 weeks marathon to get something onto MV3, uBO Lite. When AdGuard AdBlocker MV3 Experimental was announced earlier this month, I examined the extension behavior. The key points that stood out for me upon examination: Still require broad permissions to "Read and change all your data on all websites" at install time -- thereby defeating one of the stated benefits of MV3 regarding privacy. Worrying CPU/memory usage due to the fact that the service worker associated with the extension is constantly evicted and re-spawned, every few seconds or when navigating to a webpage (observed from the browser's Task Manager, ShiftEsc) -- thereby defeating one of stated benefits of MV3 regarding performance. Busting per-extension rule limits (30K) with just the "Block ads" list enabled resulting in ~46K DNR rules, climbing to ~71K after enabling "Block trackers" list. This motivated me to work on an MV3 version of a content blocker, hence came out uBO Lite (uBOL), i.e. a lite version of uBO to avoid the above issues. Does not require "Read and change all your data on all websites" at install time​ The only warning at install time is "Block content on any page", because of uBOL requests the declarativeNetRequest API for network filtering purpose. This constraint means some filtering capabilities are not enabled out of the box, for instances cosmetic filtering and scriptlet-based filtering. This is in line with the stated benefits of MV3. For instance, you may want to avoid giving extended permissions to uBOL while browsing your bank website, though you will still benefit from network filtering to block ads, trackers, etc. However uBOL supports optional permissions, which let the user explicitly grant extended permissions on a given site. Once extended permissions are granted on a given site, uBOL will apply cosmetic and/or scriptlet-based filtering if any of these are present for that given site. (More details) The extended permissions can be revoked at any time, through either uBOL's own user interface, or through the browser user interface. This takes care of point 1. above. No service worker required for network and extended filtering​ uBOL is wholly declarative, meaning there is no need for its service worker to be running. uBOL's service worker exists when the user is interacting with its user interface, i.e. popup panel or option pages. When you do not interact with uBOL, its service worker is likely to be evicted by the browser at some point, while network and content filtering is still applied by the browser. Network filtering occurs through the declarativeNetRequest API, while content filtering occurs through the scripting API. The scripting is a great addition to MV3, it allows for more reliable content filtering by telling the browser what CSS/JS to inject in a page in a declarative way, and how and when to do it. Once uBOL tells the browser which exact CSS/JS to inject on a page (only after you explicitly grant uBOL extended permissions on a given site), the browser from then on will inject the resources without involving uBOL's service worker, in a very efficient and reliable way. I have observed with the dev tools that the injection takes place very reliably, as documented. This sort of reliability was not possible with MV2 -- there is no race condition issues with MV3 with regard to uBOL's injected code versus a page's own code. This takes care of point 2. above. Coalescing as many distinct network filters into as few DNR rules​ The declarativeNetRequest has undergone many improvements since the first time I looked at it (now) years ago. To be specific: The priority property: this is a great addition and this solves the issue with regarding the important filter option, as this allows to have a block DNR rule to override a DNR allow rule, and vice versa. For instance, this property would probably make uMatrix's matching algorithm portable to MV3. The requestDomains property: This is a major addition, I mentioned this a few months ago (see above). This property allows uBOL to coalesce 1000s of network filters into a single DNR rule. This helps a lot with efficiently using DNR rules which are a finite resource due to the API-imposed limits. I feared there could have been a limit to the number of hostnames which can be assigned to this property, but I haven't encountered such limit. For instance the latest version of uBOL allows to enable Steven Black's Hosts File, which contains around ~140K filters, which all fit in only two DNR rules. The excludedRequestDomains property: As I mention above months ago, this property allows to convert network filters with the denyallow option, so another great addition. For instance, uBOL's default filter lists is that of uBO (minus "Online Malicious URL Blocklist", so blocks ads, trackers, and more out of the box), and as a result of the improvements above, it only uses ~20K DNR rules which correspond to ~76K network filters in uBO. This should allow to enable one or two regional lists without busting the API-imposed soft limit of 30K DNR rules per extension. This takes care of point 3. above. Issues encountered when working on uBOL. The DNR's matching algorithm differs from uBO's matching algorithm regarding modifier filters (redirect=, csp=, removeparam), so currently all of these are dropped from uBOL. More time is needed to figure out how to best convert these filters despite the DNR's different matching algorithm compared to uBO's matching algorithm. Generic cosmetic filters are another issue to investigate and decide whether these will be supported or not. Given that cosmetic filtering is declarative, it's not possible to have an element picker to create cosmetic filters. This could be accomplish only through a service worker dynamically injecting those content filters, which as stated above would lead to point 2. -- something I want to avoid otherwise this would defeat the Lite in uBO Lite. Since all filtering is done declaratively, this means there is no way to force an update of filters when something is fixed in filter lists, the fix will have to be published in the next version of the extension uploaded to the CWS. Many users of uBO will dislike the limitations of uBOL when compared to uBO. There is no point complaining about it, it's just not for you, it's meant for another kind of users -- you do not have to use it. For the record, it's not for me either (I want/need the full control uBO allows me), but I want to offer an option for those who use uBO as an install-and-forget blocker without ever interacting with it.

 

[oldschool]

While Gorhill prefers, or rather 'needs', the wide spectrum blocking of his MV2 version, he makes a pretty strong case for the motivation behind, and direction he intends to develop the Lite version. This Lite version is the way to go for users who appreciate a 'set-and-forget' type of adblocker with little performance overhead.

 

[wat0114]

While Gorhill prefers, or rather 'needs', the wide spectrum blocking of his MV2 version, he makes a pretty strong case for the motivation behind, and direction he intends to develop the Lite version. This Lite version is the way to go for users who appreciate a 'set-and-forget' type of adblocker with little performance overhead.

Especially for those who continue using Chrome-based browsers that switch to MV3 next year, since MV2 extensions will not longer work on that platform.

 

[forgottenuser79643]

Sounds like uBlock Lite is perfect for family members that may not, or cannot, understand the technicalities of the internet and ad-/tracker blocking.

 

[oldschool]

More info from gorhill, which further details the inconsistent/incompatible goals of MV3:

gorhill commented 16 hours ago •​

edited​

Notes regarding removeparam= filter option, specifically I was looking to integrate the AdGuard URL Tracking Protection filter list, which purpose is to remove query parameters often used for tracking purpose. The findings are that this filter list can't really be ported on a permission-less content blocker based on declarativeNetRequest API because host permissions must be granted for both the initiator domain and the request domain -- as per API documentation: The declarativeNetRequestWithHostAccess permission always requires host permissions to the request URL and initiator to act on a request. A majority of filters in that list looks as follow (excerpt): $removeparam=utm_ad $removeparam=utm_affiliate $removeparam=utm_brand $removeparam=utm_campaign $removeparam=utm_campaignid [...] The fact that they are meant to remove the query parameters of any outgoing network request means that for these to work in an a priori permission-less extension would require the extension to request the *://*/* broad host permission, which the browser would warn with: At which point it becomes pointless to be permission-less, and at which point we are back to defeating one of the stated benefits of MV3 regarding privacy. In fact, the scary warning does not make sense at all with what is actually happening. The whole purpose here is to remove query parameters used for tracking, and these query parameters are not data owned by the user as implied by the warning, these are data only useful to some undisclosed entities which are 3rd-party to the users and possibly to even the visited websites, and wanting to remove these should not be presented with a questionable warning that the extension is asking for read/write access to your data.

 

[oldschool]

µBO Lite 0.1.22.9248 Release notes

• Added support for more scriptlet-based filters
• Added support for procedural cosmetic filtering
  • This should help with removing inline ads on some high traffic sites (ex.: Twitter, Reddit, etc.) and also to prevent anti-content blockers on many sites.

---

Install from the Chrome Web Store (version 0.1.22.9248 is currently pending review).

 

[oldschool]

µBO Lite v 0.1.22.9274 latest release

Release notes same as above post. Not yet availble in CWS.

 

[silversurfer]

uBOLite_0.1.22.9285 latest release yet...

Release uBOLite_0.1.22.9285 · gorhill/uBlock

uBO Lite (uBOL), an experimental permission-less MV3 API-based content blocker. See summary description/documentation. Release notes New Added ability to enable broad permissions, i.e. to allow ext...

github.com

 

[Gandalf_The_Grey]

uBOLite_0.1.22.9285 latest release yet...

View attachment 269619

Release uBOLite_0.1.22.9285 · gorhill/uBlock

uBO Lite (uBOL), an experimental permission-less MV3 API-based content blocker. See summary description/documentation. Release notes New Added ability to enable broad permissions, i.e. to allow ext...

github.com

IMO it should be like that from the beginning.
Now, please get better cosmetic filtering and I'm back to uBO from AdGuard MV3.

 

[oldschool]

Now, please get better cosmetic filtering and I'm back to uBO from AdGuard MV3.

Patience, my friend. It's still early, but now he's gaining some momentum.

 

[Evjl's Rain]

IMO it should be like that from the beginning.
Now, please get better cosmetic filtering and I'm back to uBO from AdGuard MV3.

use ublock origin or adguard MV2 until June 2023
MV3 adblockers are far from usable, not much better than DNS filtering

 

[wat0114]

Patience, my friend. It's still early, but now he's gaining some momentum.

Gorhill is brilliant. If he can't overcome the restrictions impossed by MV3, then probably no one can.

 

[oldschool]

If he can't overcome the restrictions impossed by MV3,

'Overcome' is a pretty strong word. He'll only be able to implement what the MV3 structure allows, nowhere near matching the MV2 version.

 

[oldschool]

µBO Lite v 0.1.22.9301 pre-release version

Added support for removeparam= filter option​

Consequently, AdGuard URL Tracking Protection (AUTP) has been added to the set of available filter lists.

However, removeparam= equivalent DNR rules can only be enforced when granting uBOL broad permissions. If broad permissions are
not granted, removeparam= equivalent DNR rules are ignored.

Exception removeparam= filters are not supported, and these are present in AUTP and meant to unbreak some websites which are known to break as a result of removing query parameters. This is issue might be mitigated in the future by making the conversion from filters to DNR rules more complicated but this can never replace the accuracy of uBO's filtering engine being able to fully enforce arbitrary exception removeparam= filters.

Also, it is not possible to translate regex-based removeparam= values to DNR rules, so these are dropped at conversion time.

As with other filters to DNR rules conversion, the converter coallesce many distinct removeparam= filters into fewer DNR rules.

Release uBOLite_0.1.22.9301: [mv3] Add support for removeparam= filter option · gorhill/uBlock

Consequently, AdGuard URL Tracking Protection (AUTP) has been added to the set of available filter lists. However, removeparam= equivalent DNR rules can only be enforced when granting uBOL broad pe...

github.com

 

[oldschool]

A separate µBO Lite issue tracker has been started:

Issues · uBlockOrigin/uBOL-home

uBO Lite home (MV3). Contribute to uBlockOrigin/uBOL-home development by creating an account on GitHub.

github.com

 

[oldschool]

µBO Lite v 0.1.22.9305 release version

 

[Gandalf_The_Grey]

uBOLite_0.1.22.10106 released:

New​

Replaced on/off toggle switch with a slider to select one of four filtering modes: no filtering, basic, optimal, complete.

The basic mode is the default mode and does not require permission to read and change data.

The optimal mode enables more advanced network filtering (support for removeparam=, and more in the future), specific cosmetic filtering, and scriptlet-based filtering.

The complete mode adds generic cosmetic filtering, which support has been added in this release.

Any of these filtering modes can be picked as the default one from the Settings pane (except for no filtering), and can also be picked on a per-website basis to override the default mode.

Recommendation: the optimal mode is the suggested one, and complete mode should be used only on websites for which it has a positive effect -- typically this mode will take care of placeholders left behind on a page, when these placeholders have not been taken care by specific cosmetic filters of optimal mode.

A new setting to enable/disable auto-reload of webpages when the filtering mode is changed through the popup panel has been added. Enabled by default.

The filter list AdGuard CNAME-Cloaked Trackers has been added. Enabled by default.

---

Install from the Chrome Web Store

Manual installation: Download the uBlock0_0.1.[...].[...].mv3.zip package below, unzip, navigate to chrome://extensions/ in your browser, then tell the browser to load the extension.

Release uBOLite_0.1.22.10106 · gorhill/uBlock

uBO Lite (uBOL), an experimental permission-less MV3 API-based content blocker. See summary description/documentation. (no longer up to date) Release notes New Replaced on/off toggle switch with a ...

github.com

 

[wat0114]

uBOLite_0.1.22.10106 released:

Release uBOLite_0.1.22.10106 · gorhill/uBlock

uBO Lite (uBOL), an experimental permission-less MV3 API-based content blocker. See summary description/documentation. (no longer up to date) Release notes New Replaced on/off toggle switch with a ...

github.com

Installed in Edge mere minutes ago. I like the addition of the filtering modes in this release