[gorhill]

> It isn’t “nothing else”, cosmetic rules can still be updated independently “over-the-air”.

It's not just about cosmetic rules, it's also about DNR rules other than block/allow/allowAllRequest: redirect=, removeparam=, csp=, etc.

If the idea is that these DNR rules require non-fast-trackable thorough reviews, but dynamically updating them will bypass those thorough reviews, than I am at a lost to understand the logic of treating them as requiring thorough review.

If these DNR rules are considered potentially harmful thus requiring thorough reviews, why would they be allowed to be downloaded from a remote server and dynamically created in the first place?

There is also the content scripts-based filters, which is something that change every day. This is where we diverge, I chose to go fully declarative because this way these content scripts are injected reliably in a timely manner by the MV3 API.

This is not the case when injecting in a event-driven manner since the extension's service worker may need to wake up, fully restore its current state, then by the time it's ready to inject the content scripts programmatically, it might be too late as the target webpage has already started to load.

[ameshkov]

The “safe rules” concept is a little strange indeed, not very consistent.

I actually agree that for an MV3 ad blocker I’d better have a fully declarative default (emphasis on default), but I’d like to provide an option to grant more permissions and allow more rules. I’ll wait until declarative cosmetic rules become a thing before going this way though.

What I don’t like about your way is that it’s very difficult to use the MV3 version for filters development, filter list authors will have to re-build the extension every time they make any change to the underlying filters.

Maybe this is not a big problem though, we’ll only see it when MV3 becomes the only option and there will be more issue reports from its users.

[dotproto]

> If the idea is that these DNR rules require non-fast-trackable thorough reviews, but dynamically updating them will bypass those thorough reviews, than I am at a lost to understand the logic of treating them as requiring thorough review.

While they solve similar problems, these are different systems with different constraints.

* In order to allow something through the review process without close examination, you need to be sure it will not compromise end users. The block, allow, and allowAllRequests actions are known to present minimal risk to user's web browsing activities. The same cannot be said for redirecting requests or modifying a request's headers.

* Dynamic rule registration logic can be statically analyzed for risk assessment purposes. For example, say you're looking at two extensions that both have dynamic rules. Extension A only dynamically register block rules based on remote configuration. Extension B has <all_urls> and passed an arbitrary JSON object to the updateDynamicRules call. Personally, I'd be very concerned about what Extension B could do at the developer's behest, whether intentionally or if the dev's servers are compromised. IMO Extension B may even cross the line on what store policy permits.

* Expectations for extension's static content are different from an extension's dynamic operations. If an extension has code that explicitly does something nefarious and that passes review, the review process will be raked over the coals by commentators. If an extension's static contents are benign but a developer makes it do something nefarious at runtime, there is more understanding that this behavior may not have been visible to reviewers during the review process.

I'm sure there are more differences worth mentioning, but I need to run.

As a final parting thought, if safe rules and fast track review were already implemented and dynamic rules were being proposed today, I expect we'd be having conversations about whether or not devs should be able to register unsafe dynamic rules. I think there's a realistic possibility that we wouldn't allow it. Or if we did, that this capability would be gated by a new permission with a warning.