Hacker News Reader

Chrome's auto-update forces you to trust the author of an extension until it requests more permissions, at which point the extension is automatically disabled and the user is prompted to accept the new permissions to re-enable the extension.

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.

Doesn’t this simply encourage extension authors to request as many permissions as possible from the outset?

Most users just click yes to all of these things. Those who would skip installing an extension because of this are an extreme minority.

The solution to that is to only request extensions when they're needed, and to give users prominent options to grant access "only once" or to revoke access (both of which should be undetectable from extensions without extra work).

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.

> 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."

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.

Password managers don't need extensive permissions, they just need a built-in autofill API. Similarly, you could implement a basic adblocker via a declarative content blocking API.

Fine-grained permissions will allow for this sort of thing.

Does that cover the functionality of most popular extensions though? When there's an API that matches up with the purpose of the extension, it's more straightforward. I would have thought the popularity of those particular example extensions is what partially drove the creation of those APIs as well.

The APIs I mentioned in my previous comment don't exist yet. My point is that Google is going to need to _build_ APIs to fulfill all of the most common use cases (including those ones) in order to succeed in their goal of making extension permissions more fine-grained.

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.

It does, and many extensions on the store already request huge blanket permission sets they don't need. The UI flow for requesting a new permission with an update is awful to the point that many users never even notice it, so you really should just request every possible permission when you first release your extension.

They need to fix the UX here and it doesn't seem like they intend to.

I think most vigilante extensions arise from malicious players buying popular extensions and then uploading nefarious new versions. In other words, the original authors do not necessarily have incentive to request as many permissions as possible.

Unless an extension can do malicious things with the permissions you gave it.

This is also a good point. There's the related problem of the extension author selling the extension to a shady company for some extra bucks, who then pushes out an auto-installing update bundling it with malware/adware.

Example: Stylish -- https://arstechnica.com/information-technology/2018/07/styli...

You are not the majority of users though that have the ability to check extensions code to vet them. That would be a huge feature ask for small number of users and I bet you would suffer from review fatigue reading all updates to all extensions. This was the problem with many grease monkey scripts and why addons/extensions are king.

That's why people invented peer review.

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.

To get the arrangement you describe would require Google to voluntarily give up some of its current control over Chrome (or for Chrome users to switch to another browser).

So if you can't ask the downloader to verify the code, and extension developers can put almost whatever they want on your browser, what are you supposed to do? Just trust randoms to not infect your computer intentionally or neglectfully?

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.

One thing you can do to mitigate risk is to disable any extension you aren't actively using day to day and only turn them on when you need them. If an extension goes rogue it will then hopefully be detected before you activate it again.

The process you described feels like it could be handled with some automation...at least the cumbersome parts. Could even version control what you've verified in your own repo.