Making the permissions as fine-grained as possible - as google is doing here - is a good way to prevent an extension from becoming malicious in the future.
Most users just click yes to all of these things. Those who would skip installing an extension because of this are an extreme minority.
This isn't perfect, but it comes with some advantages. It's more work for an extension author to check for the permissions than to just write their application logic normally. This means that the lazy authors start coding their apps correctly (just try to do the thing and let the OS handle asking for permission), and only the malicious authors are left nagging for permissions early.
If you have more legitimate than malicious app on your platform, you can at least sort of train some users to think what the malicious apps are doing is weird. If most of your apps don't ask for permissions up front, then the ones who do start to look weirder.
If I go to a website, and a permission pops up asking to access my webcam, and I didn't do something to make that permission pop up... that is really weird and I'm going to click 'no'. And when I click no, if the website wants to be cranky about it, they have to write extra code to hide whatever content is already loaded and pop up a dialog complaining. If I click OK and then immediately click a button and revoke that permission, they need to have even more code continually running in the background to detect it.
Again, it's not hard for a malicious extension/app to do that, it's just that only the malicious extensions/apps are going to do that. So it becomes easier to educate users with simple rules like, "if a site asks for a permission that's unrelated to what you're doing, always say no." It also becomes easier for users who are already careful about permissions to be paranoid and grant them carefully, because they don't have to decide up-front whether the app is worth installing -- they can decide later on whether or not they trust it to have access to something.
Part of having fine-grained permissions is in getting rid of what I call the Terms of Service version, where you just stick anything you might ever want inside of a manifest and then users either accept everything or the app doesn't install.
Are you sure it's this simple? Adblockers and password managers for example require wide ranging permissions to work and there's plenty of popular extensions in the same situation.
Fine-grained permissions will allow for this sort of thing.
So yes, the functionality of most popular extensions will be covered by the new APIs, because Google will designing the new APIs with those popular extensions in mind.
They need to fix the UX here and it doesn't seem like they intend to.
Example: Stylish -- https://arstechnica.com/information-technology/2018/07/styli...
You cannot read all the code of all the extensions you use, and if you are 'regular user', you shouldn't, but you trust some power users, researchers, developers who read the code of particular version of particular extension.
All that is needed is some infrastructure for that. You could even tune the percentage of people you trust who audited the new version of extension to mark it automatically updated for you.
That's not actually have to be anonymous audit process, most of the people in security industry have names, and you know, they actually use extensions too, so they usually read the code anyway. All we need is the checkbox where they could 'ack' the extension.
Unless there's another option, I agree with the OP of this thread. Not allowing a 'locked dependency' type of mechanism for extensions continues to be very dangerous.
Alternate idea: Google can take responsibility for software they are distributing in a more serious manner.
For small extensions that add basic browser functionality (e.g. reorder tabs, enable autocomplete), I wish Google would enable users to verify open-source extensions. I trust the version of the code that I have reviewed on github. I do not trust that the kid who wrote this extension won’t go rogue and upload a malicious version in a future autoupdated release. So the only way I can verify the code that I run is to install it from the Chrome Web Store, copy the code and verify it, uninstall the Chrome Web Store version, and then load the unpacked extension (or even publish my own copy of it to the Chrome Web Store). This is pretty cumbersome.