Adjust the maximum number of static rulesets and enabled rulesets #318
Comments
dotproto
added
the
follow-up: chrome
Rob--W
added
supportive: firefox
|
@oliverdunk hi Oliver, just wanted to remind about this one, is there any update? I saw that the limits were mentioned in the known issues so I reckon it means that Chrome is supportive? |
We're definitely supportive of the general concept, and as you mentioned it's on our list of issues to resolve before announcing a new MV3 timeline. We do still want to have some discussions internally about exactly what limits to pick - at first glance your suggestions seem reasonable but we need to spend a bit more time on it just to make sure. |
Following the metrics we've added, we have good indication that we can reasonably raise the static ruleset counts for the declarativeNetRequest API without incurring an unreasonable performance impact. This CL adjusts ruleset counts as follows: enabled static rulesets: 10 (old) -> 50 (new) total static rulesets: 50 (old) -> 100 (new) We are looking into making (at least some of) the data we used for this investigation public. We may adjust these rulesets more in the future, depending on the real- world impact we see from these changes. Web Extensions Community Group Issue: w3c/webextensions#318 Bug: 1442920 Change-Id: Iabd5aa9c842825553f56827829748272605ef7ef Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4939511 Reviewed-by: Kelvin Jiang <[email protected]> Commit-Queue: Devlin Cronin <[email protected]> Cr-Commit-Position: refs/heads/main@{#1211041}
|
We’ve just landed this and it should be in Canary later today [1]. We’ve increased the limit on enabled static rulesets significantly, from 10 to 50, and the limit on total static rulesets to 100. [1] https://chromium-review.googlesource.com/c/chromium/src/+/4939511 |
oliverdunk
added
implemented: chrome
|
Not implemented yet in Firefox, tracked at https://bugzilla.mozilla.org/show_bug.cgi?id=1803370 |
|
This has been implemented in WebKit but has not yet shipped in Safari. |
|
Increasing the maximum session and dynamic count to 30,000 was also implemented in WebKit but not yet Safari. |
Proposal
We at AdGuard suppose that the limits should correspond to the functionality of MV2 extensions and this is currently not the case.
Increase the maximum number of static rulesets to 100
The reasoning is rather simple. We checked the number of filter lists that are included into three popular ad blocking extensions and here is what we got.
AdGuard filters changes history
uBlock Origin filters changes history
Adblock plus filters changes history
With the current limit of 50 rulesets we won’t be able to repeat this functionality. To conclude, we think that the maximum number of rulesets should be increased from 50 to 100 so that we didn’t reduce the users choice compared to MV2.
Increase the maximum number of enabled rulesets to 20 or higher
In order to find out what would be the adequate maximum number we analyzed public issues (raw values) from AdGuard users from the AdguardFilters repo.
It appears that 25% of AdGuard users have over 10 filter lists enabled.
In addition to that, uBlock Origin by default has 10 filter lists enabled.
If the limit is increased to 20 it will not solve all the transition issues, but it will at least be a problem for just 7% of the users.
The text was updated successfully, but these errors were encountered: