[mehrdada]

> Why couldn’t this problem be solved by having a setting/option to load extensions that are not hosted in the Chrome Web Store? Unlike modern mobile operating systems, Windows does not sandbox applications. Hence we wouldn’t be able to differentiate between a user opting in to this setting versus a malicious native app overriding the user’s setting.

Sounds a bit BS to me. In what reasonable threat model the attacker can run arbitrary code on the user's system, but will need a Chrome extension to do nasty things? The attacker could just replace the Chrome binary altogether, for instance.

I understand that there can be conceivable security benefits as a result of this change, but I think the real motivation is control, not security.

[higherpurpose]

Because it is BS. The drag and drop "security feature" for external extensions was more than enough to protect against the vast majority of "evil extensions" (which I believe was a small amount to begin with, and Google never even bothered to show us any numbers behind these "scary external extensions that are totally going to destroy the world if we don't do this", before they even implemented the drag and drop restriction).

Watch for their next step - getting rid of all Adblockers in the store. This has nothing to do with security, or rather very little to do with it. The real agenda is something entirely different (not letting the user to install whatever extensions he wants: Adblock, TPB unblockers, Hulu/Netflix unblockers, Youtube downloaders, and so on). MPAA didn't get on W3C's board for nothing, after all.

I've warned before this would happen, when MPAA joined the W3C. They're going to demand more features be removed from the browsers that they think "facilitate piracy", and Google is totally going to go along with it, because many of the requests benefit them, too, especially if they get something in return from that from the big studios and so on. Some just benefit them directly (removing Adblock).

[mhurron]

W3C doesn't dictate what features browsers have or do not have, they're concerned with web standards. The MPAA joined to make sure DRM showed up in HTML5, not to tell Google to take out ad blockers.

If Google removes ad blockers it will be because Google's revenue is based on ads, not because the MPAA or the W3C told them to.

[Touche]

I think that's a little naive. Google sells Hollywood movies and tv shows in their Play store.

[mhurron]

And what does that have to do with an ad blocker in Chrome?

Lot's of companies sell content though the Play Store, maybe it's NBC that is forcing Google to remove the ad blocker /sarcasm.

[Touche]

> And what does that have to do with an ad blocker in Chrome?

Google owns both Chrome and the Play Store...

[mhurron]

So that means that people using the Play store can dictate what does and does not go into Chrome? Damn, I need to get that $25 developer account.

Again, what does movie distributors selling movies through the Play store have to do with the MPAA dictating what is and is not in Chrome?

[derefr]

This is defense-in-depth. Sometimes, the goal is to get a chrome extension installed. (One that, for example, creates pop-up advertisements at random intervals to generate grey-market PPM revenue for the extension author.) Windows (and it's inevitably Windows) knows enough to realize "hey, this Chrome isn't the Chrome that was here yesterday." Signed binaries and SmartScreen work together well enough that even when Chrome is installed to a user-writable directory, it'll get punted if a virus actually changes it.

But if a virus can get a perfectly valid program, with every reason to already be on the system, to do something that program already has permission to do... then it can circumvent the OS's strictures against running novel-and-unknown scripts and binaries.

[mehrdada]

Yeah, I'm sure you can construct very specific scenarios in which it would be a roadbump; I don't deny that (in your scenario, for example, you can just replace Chrome with the latest dev channel binary instead of a random patched binary.) I remain unconvinced about it as a "reasonable" threat model. Having native app access is a much greater security risk in an of itself. I wouldn't begin to worry about invalid browser extensions if I knew I have a rouge binary running.

I think it is obvious what their real motivation is.

[icebraining]

Windows (and it's inevitably Windows) knows enough to realize "hey, this Chrome isn't the Chrome that was here yesterday." Signed binaries and SmartScreen work together well enough that even when Chrome is installed to a user-writable directory, it'll get punted if a virus actually changes it.

What if the virus just installs the binary somewhere else, then updates the shortcut? There are hundreds of possible ways, it just seems futile to plug a particular leak.

[7952]

One of the main selling points of Chrome apps was a belief that they are safer than native apps. But on a lot of computers now the vast majority of sensitive information is held in browser sessions, not in the My Documents folder. Running code in a sand-boxed browser session with full permissions could be far more profitable for an attacker than running arbitrary code on the OS. The only way to maintain security is to control access to the particular ecosystem within which data exists (in the way Facebook does). At the moment Google are trying to control an ecosystem that includes everything the user does, which is impossible to secure in its entirety.

[est]

> solved by having a setting/option to load extensions that are not hosted in the Chrome Web Store

It is the current solution. Unzip, go to extensions, enable developer mode, load extension. Which IMHO is much more dangerous than downloading crx

[derefr]

It's a lot more of a hassle, though, to ask users to keep an extracted directory sitting around which Chrome basically symbolically links to, than to just download a .crx, drop it on the extensions window, and then delete that .crx.

Even I still get confused sometimes, as a chrome-app developer, when I move a project folder and Chrome suddenly can't find my extension. It goes against how we think of "deploying to test" in any other development workflow.

[captainmuon]

Right, so thats why .exe installers for extensions will now be popping up, which is not exactly better security-wise.

[venomsnake]

Extracting banking information? Session intercept, credentials theft - you need some form of cooperation with the user and the browser to get them.

[mehrdada]

You don't necessarily have to be a Chrome extension to do that if you can run a native app. You could read Chrome address space as a debugger, for instance.