Question Who is willing to test a new uBlock Stripped with dynamic filtering?

Please provide comments and solutions that are helpful to the author of this topic.
LinuxFan58

LinuxFan58

Level 19
Thread author
Nov 30, 2025
921
3,405
1,767
Yes post your nickname and I create a PM group where we can discuss how we revive uBO Mv2 in Chrome using Mv3 limitations

Hard bounderies (that is why it is called STRIPPED)
1. I scope the default lists to only contain the
A) Top 1 million websites of the world which are in
B) 5Eyes countries or extended EU-zone
C) Generic rules are dropped


2. Default lists are limited to
A) Kees1958 most used EU-US ad & tracking networks
B) AdGuard Base filter
C) AdGuard remove tracking parameter

Optionally add
D) Specific anti-adblock of AdGuard
E) extended EU-langauge filters from AdGuard (preferred) or EasyList

Reason is that I apply these hard STRIPPED bounderies is because I use the ¨large chunk" approach of AdGuard Mv3 for cosmetic filtering and scriplets (and not the more efficient ¨smal chunk" approach of uBO-lite. I want to process scriptlets and inject cosmetic rules in the same structured manner as AdGuard, but want to meet uBO-lite's efficiency. Using the stripped limitations allows me to achieve this. Large chunks has software architecture advantages in terms of re-useability, maintainability and expandibility (as this new extensions proofs), but costs in terms of page injection size and speed. So to match uBO-lite speed with AG functionality, I have to strip something.

When this extension works any coder outside 5Eyes and extended EU-zone can make a special version doing the revers (only facilitating South America, Africa, Middle East, Far East and Belarus plus Russian Federation). It will be open source so any one can use it for non-commercial use.

What uBlock Stripped with dynamic filtering offers:
- same functionality as uBol-stripped excluding DDG Tracker radar
+ extra protections of 3P-Matrix-lite added (block 3P from numeric IP only and non-standard port connections) as extra options in Security & Privacy panel
+ uBO dynamic filtering, this is basically the new Matrix or 3P-Matrix-lite V3.7.4 with following changes
a) no mode filtering
b) added a column which shows whether a (sub)domain is known in DuckDuckGo tracker data base (this is also the reason DDG Tracker radar is removed)
c) added a switch show domains which are not blocked.
This switch is by default disabled, shows you all requests and when you enable it the (sub)domains blocked by the filterlists are not shown. This switch allows you to override (with ALLOWS) teh default blocklists and also allows you (when you enabled it) to further refine blocking 3P-scripts/frames for the website you are currently browsing.
+ dynamic filtering rules are always applied per domain (yes it is a limitation compared to uBO, but this prevents shoot in the foor errors).
 
Last edited:
LinuxFan58 said:
Yes post your nickname and I create a PM group where we can discuss how we revive uBO Mv2 in Chrome using Mv3 limitations

Hard bounderies (that is why it is called STRIPPED)
1. I scope the default lists to only contain the
A) Top 1 million websites of the world which are in
B) 5Eyes countries or extended EU-zone
C) Generic rules are dropped


2. Default lists are limited to
A) Kees1958 most used EU-US ad & tracking networks
B) AdGuard Base filter
C) AdGuard remove tracking parameter

Optionally add
D) Specific anti-adblock of AdGuard
E) extended EU-langauge filters from AdGuard (preferred) or EasyList

Reason is that I apply these hard STRIPPED bounderies is because I use the ¨large chunk" approach of AdGuard Mv3 for cosmetic filtering and scriplets (and not the more efficient ¨smal chunk" approach of uBO-lite. I want to process scriptlets and inject cosmetic rules in the same structured manner as AdGuard, but want to meet uBO-lite's efficiency. Using the stripped limitations allows me to achieve this. Large chunks has software architecture advantages in terms of re-useability, maintainability and expandibility (as this new extensions proofs), but costs in terms of page injection size and speed. So to match uBO-lite speed with AG functionality, I have to strip something.

When this extension works any coder outside 5Eyes and extended EU-zone can make a special version doing the revers (only facilitating South America, Africa, Middle East, Far East and Belarus plus Russian Federation). It will be open source so any one can use it for non-commercial use.

What uBlock Stripped with dynamic filtering offers:
- same functionality as uBol-stripped excluding DDG Tracker radar
+ extra protections of 3P-Matrix-lite added (block 3P from numeric IP only and non-standard port connections) as extra options in Security & Privacy panel
+ uBO dynamic filtering, this is basically the new Matrix or 3P-Matrix-lite V3.7.4 with following changes
a) no mode filtering
b) added a column which shows whether a (sub)domain is known in DuckDuckGo tracker data base (this is also the reason DDG Tracker radar is removed)
c) added a switch show domains which are not blocked.
This switch is by default disabled, shows you all requests and when you enable it the (sub)domains blocked by the filterlists are not shown. This switch allows you to override (with ALLOWS) teh default blocklists and also allows you (when you enabled it) to further refine blocking 3P-scripts/frames for the website you are currently browsing.
+ dynamic filtering rules are always applied per domain (yes it is a limitation compared to uBO, but this prevents shoot in the foor errors).
Click to expand...
I cannot provide a personal nickname or join a private PM group, but I can comment here on the technical design.

Main MV3 constraints

The proposed stripped scope should make an MV3 implementation more practical, but it does not remove the main architectural limitations:

  • Network filtering must ultimately fit Chrome’s Declarative Net Request rules, including static, dynamic, and session-rule quotas.
  • Rule priority and action interactions must be handled carefully when static lists, user rules, and dynamic filtering overlap.
  • Cosmetic filtering and scriptlet injection are separate from network blocking and may require content scripts, CSS injection, or web-accessible resources.
  • Large cosmetic chunks can reduce rule-management complexity, but they may increase memory use, parsing time, page-injection overhead, and the risk of affecting unrelated frames.
  • The extension should fail safely when a list exceeds quotas or contains unsupported syntax. Silent truncation would be particularly dangerous.

Potential concerns with the proposed scope

Restricting rules to selected regions and a Top 1 million domain set may improve performance, but it can also create unexpected gaps:

  • Many globally used services are hosted on infrastructure outside the selected regions.
  • CDNs, analytics providers, and advertising networks can serve the same resources to users in multiple countries.
  • A site’s popularity ranking does not necessarily represent the domains contacted by that site.
  • Dropping generic rules may remove protections that are not tied to a particular domain, including common third-party tracking and nuisance patterns.

The generated scope should therefore be clearly displayed to users, with an easy way to enable broader lists or import custom rules. It would also be useful to report skipped, unsupported, and quota-limited rules rather than presenting the resulting configuration as equivalent to full uBO filtering.

Dynamic filtering

Applying dynamic rules per domain is a reasonable safety-oriented limitation. However, the implementation should document:

  • Whether rules apply to the document origin, initiator, request destination, or all of these.
  • How subdomain inheritance works.
  • How user allow rules interact with list-based block rules.
  • Whether an allow rule can override a higher-priority or more specific block rule.
  • How redirects, frames, workers, WebSockets, CSP reports, and extension-generated requests are handled.

The “show domains which are not blocked” option should be treated as a user-interface view rather than a change to the filtering model. It should also make the source of each decision visible: static list, dynamic rule, security option, or cosmetic/scriptlet rule. Otherwise, debugging an unexpected result will be difficult.

External data and licensing

If DuckDuckGo tracker data or other third-party datasets are included, verify their redistribution and modification terms before packaging them in an open-source extension. “Non-commercial use” is not automatically compatible with every open-source license, so the project should publish the exact license and attribution information for every bundled dataset.

Testing priorities

Before comparing performance with uBO Lite or AdGuard MV3, test at least:

  • Cold-start and warm-cache page-load times.
  • Memory use after browsing many sites and opening many tabs.
  • Cosmetic injection time on pages with many frames.
  • Rule-compilation time and extension update time.
  • Behavior when static and dynamic quotas are nearly full.
  • False positives involving CDNs, payment pages, login flows, video players, and web applications.
  • Whether disabling a list actually removes its rules without requiring a browser restart.

The concept is technically plausible within MV3, but it should be described as a deliberately scoped filter rather than a complete uBO replacement. The most important safeguards are transparent rule-source reporting, explicit quota/error handling, predictable precedence, and an easy recovery path when a dynamic rule breaks a site.
 
Jan Willy said:
Dynamic DNR filtering screen isn't readable in dark mode.
Click to expand...
Again, thanks for reporting

I asked Claude: When I have clearly stated that the GUI has to confirm to readibility standards for both light and dark mode, how come you coded it wrong?

Then I get an excuse and a nonsense answer: but this has happened before. When I run out of my tokens, it makes a small error, so that I am willing to pay (another 5 dollars) to finish it.

1785669489576.png
 
  • Like
Reactions: 7Oz-64, Dave Russo and Jan Willy
Jan Willy said:
In version 7.3.1 Dynamic DNR filtering screen still isn't readable in dark mode. Claude is a tough guy.
Click to expand...
Yes it found a bug at last. Updating to 7.3.2+ or higher. But this one takes a little longer, going to implement old school (develop 2 style guides for light ad dark mode, even one level higher than separating css + js + html) so it may take some time, before Clause gets it right on how to implement authoritative style guides.

It is V7.4 (using style guides is in my book a technical improvement but Claude found it an functional improvement because less can go wrong for the user, ironical to say after so many @#$%⁻up :-(
 
Last edited:
  • Like
Reactions: Jan Willy
  • Like
Reactions: Jan Willy
Sampei.Nihira said:
That's strange.:unsure:
fdn.gsmarena.com is a 1p-script.
I notice that it's also allowed by the filter lists I've subscribed to in uBo.
Click to expand...
That is why Dynamic DNR shows whether the 3p domains are in the DDG tracker DB. They may have a very low prevalence, so they are most likely not in a blocklist.

Compare blocklist with roadmaps. When you drive around in Italy it is sort of useless to have roadmaps of all countries with you.

Better travel light and only use roadmaps for the cities you visit (compare cities with websites)

See: Tracking Reach | WhoTracks.Me
 
  • Like
Reactions: Jan Willy

You may also like...