News for hackers. Stuff that matters.
Re:Trustworthy Chrome Extensions, by default by yonran on Monday October 01, 2018 @04:58PM (#18116755)
Chrome’s auto-update forces you to trust the author of any extension you install for as long as you use the extension. Google’s “Trustworthy by default” effort doesn’t change this model since it still provides no guarantees. This works for some extensions backed by companies (e.g. Adblock), but it doesn’t work for extensions that add simple functionality.

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.

Re:Trustworthy Chrome Extensions, by default by notatoad on Monday October 01, 2018 @06:55PM (#18117487)
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.

Re:Trustworthy Chrome Extensions, by default by stouset on Monday October 01, 2018 @09:18PM (#18118110)
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.

Re:Trustworthy Chrome Extensions, by default by danShumway on Monday October 01, 2018 @09:40PM (#18118191)
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.

Re:Trustworthy Chrome Extensions, by default by seanwilson on Monday October 01, 2018 @11:48PM (#18118673)
> 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.

Re:Trustworthy Chrome Extensions, by default by Ajedi32 on Tuesday October 02, 2018 @12:07AM (#18118726)
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.

Re:Trustworthy Chrome Extensions, by default by seanwilson on Tuesday October 02, 2018 @11:34AM (#18122623)
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.
Re:Trustworthy Chrome Extensions, by default by Ajedi32 on Tuesday October 02, 2018 @12:04PM (#18122891)
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.

Re:Trustworthy Chrome Extensions, by default by kevingadd on Monday October 01, 2018 @11:00PM (#18118515)
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.

Re:Trustworthy Chrome Extensions, by default by Vinnl on Tuesday October 02, 2018 @03:15AM (#18119414)
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.
Re:Trustworthy Chrome Extensions, by default by sjs382 on Tuesday October 02, 2018 @01:28AM (#18119039)
Unless an extension can do malicious things with the permissions you gave it.
Re:Trustworthy Chrome Extensions, by default by hartz on Monday October 01, 2018 @05:22PM (#18116938)
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...

Re:Trustworthy Chrome Extensions, by default by zbowling on Monday October 01, 2018 @05:11PM (#18116851)
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.
Re:Trustworthy Chrome Extensions, by default by snaky on Monday October 01, 2018 @06:08PM (#18117229)
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.

Re:Trustworthy Chrome Extensions, by default by hollerith on Monday October 01, 2018 @10:47PM (#18118479)
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).
Re:Trustworthy Chrome Extensions, by default by meesles on Monday October 01, 2018 @05:39PM (#18117059)
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.

Re:Trustworthy Chrome Extensions, by default by Flenser on Tuesday October 02, 2018 @01:35AM (#18119061)
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.
Re:Trustworthy Chrome Extensions, by default by madrox on Monday October 01, 2018 @07:53PM (#18117767)
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.