Hacker News new | past | comments | ask | show | jobs | submit login

This is an excellent accidental rebuttal to the entire Manifest v3 project. The stated reason for the new major version and breaking changes is officially:

> Manifest V3 represents one of the most significant shifts in the extensions platform since it launched a decade ago. Manifest V3 extensions enjoy enhancements in security, privacy, and performance...

https://developer.chrome.com/docs/extensions/mv3/intro/

Web developers (see uBlock origin for one) have been complaining that Manifest v3 breaks chrome extensions for no discernible benefit and Manifests v3 exists entirely to protect Google's ad business. This review gives fresh evidence to support that assertion and showcases Google's deception. As seen in this blog post, extensions can request literally every permission and the user permission warning actively hides the permissions beyond the content fold.These changes haven't been made for security's sake.

I wish the entire Manifest v3 was scrapped, but that likely won't happen. I'll settle for people assuming Google is lying by default.




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.


The counterpoint might be that being declarative it's easier to do static analysis to find malicious extensions. But I'm not sure how much I buy that argument, and it's no excuse to disable v2 extensions entirely.


It just removes the OnBeforeRequest() way of injecting javascript. There are other directly supported ways to inject javascript, some of them easier than OnBeforeRequest(). The counterpoint would have to be something like removing that was just the first step, and that they plan on closing all the doors. But, if you close all the doors, really all the most popular extensions are hobbled.

Edit: Removing just OnBeforeRequest() js injection does sort of uniquely harm mostly heuristic ad blocking and things like tampermonkey. It's not hard to feel like that was probably the real goal.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: