[antonok]

> V3 has gotten better at blocking ads over time, not worse.

That may be true, but it's still significantly limited compared to MV2. And at the current rate, that is unlikely to change by the time Manifest V2 support is removed.

What's important is that MV3 adblocker developers no longer have full control over how they're allowed to modify pages. Given how adversarial the relationship between adblockers and websites is, that lack of control will be exploited almost immediately.

[staticassertion]

Yeah, so I'm against V3 mostly because I think that the pros of developers having power outweigh the cons of potential malicious extensions. I personally would have preferred rethinking a few other areas first:

1. Auditability - both in terms of the code and the behaviors

2. Improved permissions - could we have split WebRequest up?

3. Improved performance - could we have leveraged new APIs, like the declarative API, for improved performance? What about compiling to wasm? Or new APIs?

4. Capabilities/ Sandboxing - Within an extension could we slice out capabilities?

5. Improved UX around permissions. Surfacing the permissions and performance implications of extensions would be worth exploring and aided by any ability to slice up permissions more.

Chrome could even create 'sanctioned' extensions that wouldn't trigger scary popups in order to make it that much clearer when something is scary - something like "if you publish your extension such that it is digitally signed, you use 2FA or whatever, you have good standing with us, blah blah blah, we will waive that popup". IIRC Firefox did this to lower their review burden, NoScript was one of the ones on the list I think, but that would have been many years ago and I don't know if it has changed since.

That said, I don't think V3 is the end of the world. I would have preferred the other options, and I bet some people at Google explored them too and know much more about why they are/aren't viable, but I'm OK with V3. I don't really think that Google Adsense is driving this decision at all nor do I expect it to benefit them, at least not in the short/medium term.

[antonok]

Great suggestions. The "third party buys popular extension and quietly adds malware" approach is also a huge attack vector. There really ought to be some way to prevent an extension from updating until you've had a chance to review and approve that change, especially if it requests a lot of sensitive permissions.

[staticassertion]

Well, even today, if the attacker modifies the permissions it will require a re-acknowledgement. Google can also do things there, like if the extension is tied to a key (as it should be), tell developers that they are required to not provide that key to anyone else, even if they sell / transfer ownership of the extension. Instead, the new owner should register a new key, which can trigger review/ scrutiny.

Key + 2FA means the attacker has to have code execution on a developer's machine in order to publish an update (via the local session token, which you should make short lived). And Google could require a FIDO2 token if you want to bypass the "alert users that this thing uses lots of permissions".

There's a lot of stuff I'd be working on to avoid having to remove developer power.

edit: K I've been rate limited by HN so I can no longer reply for today, but them's my thoughts.

[blibble]

if someone offers a typical small extension author $500,000 for their extension, I think they're going to ignore Google's rules and handover the keys