Manifest V3, webRequest, and ad blockers
-
A true proof of the impact of MV3:
Adguard AdBlocker (MV3 Beta).
-
@barbudo2005 is it for each filter list limit or global 5000 rules for all lists?
Also, what if we create 10x sub-list, with 5000 rules each to overcome the limit?
-
"Notifications: Due to the new APIβs rule limits, users may see frequent notifications when they exceed these limits.
Why this is happening: Manifest V3 divides rules into static (built-in) and dynamic, with strict limits.
Static rules: 30,000 rules per extension, with a cumulative limit of 330,000 for all extensions installed by a single user.
For regexp rules, the limit is 1,000 per extension.
The maximum number of simultaneously enabled filters is 50.
Dynamic rules: a strict cap of 5,000 rules. This limit also includes 1,000 regexp rules.
If this limit is exceeded, only 5,000 converted rules will be applied in the following order: first user rules, then allowlist, and finally β custom filters.
Converted rules are rules that have been transformed to DNR format using declarative converter. During this conversion process, some rules may overwrite others (badfilter), some may be combined (removeparame), resulting in a list of rules with a slightly different order.
From this list of converted rules, we will only use 5,000 rules. The rest of them will be displayed in the editor, but not applied.
The current situation is an improvement from the prototype stage, and we express our gratitude to the W3C group for considering our feedback in issues such as:
Adjusting the maximum number of static rule-sets and enabled rule-sets
Increasing the maximum number of dynamic rules to 30,000
For now, we are operating with 5,000 rules instead of 30,000 as we are in the process of categorizing the rules to fit within these limits. Further updates on this will be provided in future releases."https://adguard.com/en/blog/adguard-mv3-beta.html
-
I delete EasylistSpanish+Easylist and add only EasylistSpanish and the new Rule limits are:
-
-
Please, I beg you, do not think badly of me.
I am just testing the effectiveness of these adblockers.
I will continue to wait until the end of THE adblocker.
-
@barbudo2005 said in Manifest V3, webRequest, and ad blockers:
uBO Lite is almost at the limit:
312,900 of 329,997
try to activate more lists and see what happens
I wonder where those limits come from (Google?), why exactly 330,000? What are these numbers based on?
with a cumulative limit of 330,000 for all extensions installed by a single user
So they (Google?) looked at typical number of rules in uBO (about 330,000) and decided to set limit by that (330,000) number?
-
@Stardust Google. 30.000 static rules + 5000 dynamic rules.
Perhaps the extensions manage to get the other ~3000 in some way.
https://developer.chrome.com/blog/improvements-to-content-filtering-in-manifest-v3?hl=en
I'll wait a bit more, but I'm slightly intrigued to test this constrained API and if it actually helps on the overall performances (I guess no)
-
@Hadden89 thanks for the link!
Based on this, I drafted and shared a proposal in the Web Extensions Community Group to define a set of rules that we consider lower risk and allow up to 30,000 of these. We still keep an upper limit to avoid performance regressions.
Yes, sure performance regressions..
We will continue to review the limits we have in place to make adjustments where needed.
no doubt about it
-
@Stardust also "with the WECG (web extensions) teams". Which is pretty much the google team xD
-
@Hadden89 I am not surprised
Ad company fighting for the browser performance
-
Said:
try to activate more lists and see what happens
Custom filters cannot be added to uBO Lite.
-
AdGuard MV3 maintains three features that should be incorporated into the built-in adblocker:
Element picker:
User rules list:
Filtering log:
-
Another powerful feature that maintain is ExtendedCSS:
"AdGuard's TypeScript library for non-standard element selecting and applying CSS styles with extended properties."
- Pseudo-class :has()
- Pseudo-class :contains()
- Pseudo-class :matches-css()
- Pseudo-class :matches-attr()
- Pseudo-class :matches-property()
- Pseudo-class :xpath()
- Pseudo-class :nth-ancestor()
- Pseudo-class :upward()
- Pseudo-class :remove() and pseudo-property remove
- Pseudo-class :is()
- Pseudo-class :not()
- Pseudo-class :if-not()
I tried a uBO rule with
has-text:
and it worked without problem. -
@barbudo2005, I use the WebEraser script, which do the same as the AG Element picker, it is maybe a workarround until Vivaldi can incorporate it to it's blocker. It's somewhat outdated, but until now it woks as it should
-
From what I have reviewed from Adguard (MV3 Beta), the Vivaldi team has a pretty high bar to beat.
-
According to MV3, do we have a thread about the future of Site Bleacher or Cookie AutoDelete? Both developers hosting on github are not active anymore.
As I am using Cookie AutoDelete since a few years, I am looking for a replacement for such a valuable tool in case MV3 is unavoidable for Vivaldi. -
@bariton I didn't find a MV3 alternative for these kind of extensions yet. Also, any cookie blocker (also in MV2 form) doesn't handle even the new isolated cookies. So we can only hope here.
-
@Hadden89, there isn't any alternative extensions for SiteBleacher or Cookie Autodelete in the store, also not for URL Tracking Stripper, clear Urls, Local CDN, Decentral Eyes and some others, are banned from the store, as also URL unshorten extensions. Google obviously don't like extensions which blocks it's dirty tricks to track the user, even with it's URL shortener.
The only possibility will be to emulate these with scripts or inbuild features in the future. Maybe to add them in dev mode, but this also will end with the Mv2 support in Vivaldi. -
Some of my testing tools for web development and accessibility (WCAG/WAI) will fail after Mv3. And there are no alternatives. Bad.