4 ms·

> 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

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

est 13y ago
> 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 13y ago
  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 13y ago
    Right, so thats why .exe installers for extensions will now be popping up, which is not exactly better security-wise.
derefr 13y ago
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 13y ago
  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 13y ago
  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.
venomsnake 13y ago
Extracting banking information? Session intercept, credentials theft - you need some form of cooperation with the user and the browser to get them.
- mehrdada 13y ago
  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.
7952 13y ago
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.
higherpurpose 13y ago
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 13y ago
  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 13y ago
    I think that's a little naive. Google sells Hollywood movies and tv shows in their Play store.
    - mhurron 13y ago
      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.

est 13y ago

> 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 13y ago
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 13y ago
  Right, so thats why .exe installers for extensions will now be popping up, which is not exactly better security-wise.

derefr 13y ago

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 13y ago
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 13y ago
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.

venomsnake 13y ago

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

mehrdada 13y ago
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.

7952 13y ago

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.

higherpurpose 13y ago

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 13y ago
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 13y ago
  I think that's a little naive. Google sells Hollywood movies and tv shows in their Play store.
  - mhurron 13y ago
    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.