It's good that it doesn't pretend to be a rebuttal, because it'd be a bad one.
I'm pretty sure the point of making a declarative content blocking API for adblockers is not to block all possible ways of writing a malware extension. It is just to make the most popular category of extensions safe by design. Once that has been done, it's then much easier to improve the situation with the remaining niche use cases.
What would those improvements look like? It could be finding other common ways of dangerous permissions being used by legit extensions, and extracting these patterns out as explicit and safe capabilities. It could be changing the messaging to make it easier for users to understand how dangerous the requested permission is (which they can't reasonably do while those dangerous permissions are still used by adblockers!). Or it could be a stricter review process for any extensions needing such permissions.
This extension that the author themselves think would never pass review doesn't really rebut that in any way.
The ad blockers this affects are popular because they do more than declarative black lists. It may make them safe by design, but it also makes them something completely different and less capable than what they are today. There's some room to be suspicious about that.
That's totally fair. Nobody except the people who proposed / approved the project know what the main motive was. It could be trying to hinder adblocking, could be security, it could be performance, or it could be that somebody just wanted to copy Apple.
If we as outsiders try to reason about that decision, it makes sense to pick the strongest version of those motives, not just strawmen. There's a good security argument to be made, and a silly security argument. If you pick the latter one to argue against, of course it will look like a bad excuse, leaving the more venal explanations as the only possibilities.
How is preventing extensions from blocking requests making them safe by design. You can still use the API to record every network request and send it to a server.
Chrome extensions that contain malware aren't written and submitted to the chrome store hoping to sneak past review. Malware authors _purchase_ the intellectual property of fulling functioning, useful extensions, and update them to contain their extra malware payload. I'm not sure where you got the idea that a review would be involved here at all.
AFAIK updates go through a review process as well.
Reducing the attack surface has similar benefits for this case. There will be fewer extensions with dangerous permissions around for bad actors to buy, and the the reviews for the remaining legit use cases for those dangerous permissions can be stricter.
I'm pretty sure the point of making a declarative content blocking API for adblockers is not to block all possible ways of writing a malware extension. It is just to make the most popular category of extensions safe by design. Once that has been done, it's then much easier to improve the situation with the remaining niche use cases.
What would those improvements look like? It could be finding other common ways of dangerous permissions being used by legit extensions, and extracting these patterns out as explicit and safe capabilities. It could be changing the messaging to make it easier for users to understand how dangerous the requested permission is (which they can't reasonably do while those dangerous permissions are still used by adblockers!). Or it could be a stricter review process for any extensions needing such permissions.
This extension that the author themselves think would never pass review doesn't really rebut that in any way.