www. O S N E W S .com
News Features Interviews
BlogContact Editorials
.
Google to remove ability to sideload Chrome extensions
By Thom Holwerda on 2018-06-12 23:21:41

We strive to ensure choice and transparency for all Chrome users as they browse the web. Part of this choice is the ability to use the hundreds of thousands of extensions available in the Chrome Web Store to customize the browsing experience in useful and productivity-boosting ways. However, we continue to receive large volumes of complaints from users about unwanted extensions causing their Chrome experience to change unexpectedly - and the majority of these complaints are attributed to confusing or deceptive uses of inline installation on websites. As we've attempted to address this problem over the past few years, we've learned that the information displayed alongside extensions in the Chrome Web Store plays a critical role in ensuring that users can make informed decisions about whether to install an extension. When installed through the Chrome Web Store, extensions are significantly less likely to be uninstalled or cause user complaints, compared to extensions installed through inline installation.

Later this summer, inline installation will be retired on all platforms. Going forward, users will only be able to install extensions from within the Chrome Web Store, where they can view all information about an extension's functionality prior to installing.

Am I the only one who's assuming this will eventually allow Google to remove all adblockers from Chrome?

 Email a friend - Printer friendly - Related stories
.
Read Comments: 1-10 -- 11-20 -- 21-30 -- 31-40 -- 41-50 -- 51-60 -- 61-70 -- 71-73
.
RE[2]: Locking down the "open" browsers.
By FlyingJester on 2018-06-13 18:22:04
Chromium is little better. Remember when Chromium was downloading blackbox binaries that could listen in on people's microphones on Debian?

Chromium is /not/ some utopian version of Chrome.
Permalink - Score: 2
.
RE: There is some confusion here I think...
By Alfman on 2018-06-13 18:41:11
galvanash,

> Sideloading is still possible (although its complicated, as it has always been)

https://developer.chrome.com/apps...

In short, your all getting angry over nothing... You can all put your pitchforks down.


Hmm, google seems to be putting out conflicting information regarding chrome extensions. It seems like their support pages haven't been completely updated and the generic notification at the top of chrome support pages reflects that.


It's possible your link has changed since you read it, but it now says this:

> Windows and Mac installs must come from Chrome Web Store:
As of Chrome 33, no external installs are allowed from a path to a local .crx on Windows (see Protecting Windows users from malicious extensions). As of Chrome 44, no external installs are allowed from a path to a local .crx on Mac (see Continuing to protect Chrome users from malicious extensions).

...

Both ways support installing an extension hosted at an update_URL. On Windows and Mac, the update_URL must point to the Chrome Web Store where the extension must be hosted.

The preferences file on Linux can point to your own server where you are hosting the extension. The preferences JSON file also supports installing an extension from a .crx extension file on the user's Linux computer.

...

FAQ

This section answers common questions about external extensions.

Will the methodology for allowing a “pre-install” still be supported by Google Chrome from M33 onwards?

Yes, but only as an install from a Chrome Web Store update_URL, not from a local file path.



Is google wrong?


Maybe there's a way to subvert google's restrictions somehow, but even if it can be made to work, the enterprise deployment mechanism doesn't seem like the right tool for the job IMHO. I want to use the browser, not fight with it.

https://support.google.com/chrome...
> Force-installed extensions are added to the master_preferences file that lives next to chrome.exe. This means that the CRX file can live anywhere, and the bits don't need to live on the target user's machine and don't need to be packaged into any installation script.

If you're not familiar with the master_preferences file or how it works, see configuring preferences.

There are some requirements to using this method:

This method only works if the user has access to the public extension gallery or another URL where the CRX file is kept. As such, this method might not work if the user is behind a corporate firewall or proxy that restricts access to the gallery.
This method generally only works on new installs. Making it work with an existing install is cumbersome and requires a lot of clean-up steps.

To force-install an extension using master_preferences:

Find the CRX file you want to install. Download it from the gallery, or create and package your own.

Open up the CRX with a zip program and find the manifest.json file (it's just a text file). This contains many values you will need.

Set up your master_preferences with values from the manifest.json file.



If you find more information that confirms or refutes this, please let me know. I'm just going by the info google has put out, which isn't very clear :(
Permalink - Score: 2
.
RE[2]: There is some confusion here I think...
By galvanash on 2018-06-13 19:06:47
> Windows and Mac installs must come from Chrome Web Store:
As of Chrome 33, no external installs are allowed from a path to a local .crx on Windows (see Protecting Windows users from malicious extensions). As of Chrome 44, no external installs are allowed from a path to a local .crx on Mac (see Continuing to protect Chrome users from malicious extensions).


That has been that way for a while now. You have to enable developer mode now to install an extension locally (unsigned and not in store). Before, there was a way to do it without developer mode, but it was complicated (required registry hacks on Windows). I always just considered developer mode "the way to do it".

> Maybe there's a way to subvert google's restrictions somehow, but even if it can be made to work, the enterprise deployment mechanism doesn't seem like the right tool for the job IMHO. I want to use the browser, not fight with it.

Use a canary build (they have command line switches to bypass some of this stuff) and/or turn on developer mode. Shitty answer, but it is the only way. Its not painless or easy (like I said), but it is still possible.

For day to day use though, if you want to run an extension with no fuss and muss, it pretty much has to come from the app store now (and that has been true for quite a while now). Leaving developer mode on all the time (with an unsigned extension installed) will result in a lot of security nags... If you can live with the nags it does work fine though.

I was just pointing out that you can sideload, its just been pushed into a developer only feature (similar to how Windows 10 does sideloading).

My point really was that this new restriction (i.e. the linked article begin discussed) is not related to side-loading at all. Inline installations have never allowed installing from anywhere but the chrome app store - it was just a mechanism to let developers host a page from which they could trigger installation, and it was horribly misused and amounted to no good...

ps. As of right now, this method is the quickest and easiest, and works on all platforms afaik...

https://a9t9.com/howto/install-ch...

Edited 2018-06-13 19:19 UTC
Permalink - Score: 4
.
RE[5]: Locking down the "open" browsers.
By ssokolow on 2018-06-13 19:15:14
> Starting today, inline installation will be unavailable to all newly published extensions. Extensions first published on June 12, 2018 or later that attempt to call the chrome.webstore.install() function will automatically redirect the user to the Chrome Web Store in a new tab to complete the installation.
Starting September 12, 2018, inline installation will be disabled for existing extensions, and users will be automatically redirected to the Chrome Web Store to complete the installation.
In early December 2018, the inline install API method will be removed from Chrome 71.


Translation:

1. Starting today, a random site out on the web which calls chrome.webstore.install() will trigger a redirect to the corresponding Chrome Web Store Page rather than directly popping up the "Do you want to install this Google-signed extension?" dialog.

2. Starting September 12, 2018, users will be sent to the Chrome Web Store to confirm they actually want any extensions previously installed via chrome.webstore.install()

3. In early December 2018, the chrome.webstore.install() JavaScript API will be removed.

Edited 2018-06-13 19:31 UTC
Permalink - Score: 2
.
RE[6]: Locking down the "open" browsers.
By ssokolow on 2018-06-13 19:20:05
> Interesting, but that's a flaw with firefox itself and shows that legitimate extensions within the mozilla repos were vulnerable. What's this have to do with sideloading though? Mozilla's own audits failed to catch the vulnerabilities.

It's not just that. Forcing signing was also a response to malware with an external component which was using shaped windows, programmatically overlaid and positioned, to fool the users into thinking that Firefox itself was guiding them through the process of enabling the malware extension.
Permalink - Score: 3
.
RE[4]: Locking down the "open" browsers.
By WorknMan on 2018-06-13 19:28:32
>
Security prompts have been made meaningless.


Yeah, that's why I say... make several of them in succession, with the last one being a giant, 'HEY DUMBASS....' :)
Permalink - Score: 0
.
RE[5]: Locking down the "open" browsers.
By WorknMan on 2018-06-13 19:30:14
> The idea of putting a control anywhere is just a switch the hostiles are going to exploit.

Well, if they've compromised your system to the point where they have access to the switch, why the hell would they bother to turn it off? At that point, they can do whatever they want.
Permalink - Score: 2
.
RE[5]: Locking down the "open" browsers.
By ssokolow on 2018-06-13 19:30:31
> This is why I said it need to be split. Expert/power users who should have the skill to validate what their browser is loading have a usage for the feature. So there should be a expert/power user version of firefox/chrome and a general user version of firefox/chrome possible under two different brand names.

Chrome does it via command-line switches like --enable-easy-off-store-ext ension-install which are harder for malware to reliably modify, since users can launch the browser through various avenues and they'll be ignored when externally opening a new tab in a browser instance that was launched without them.

Mozilla went the "different editions" route. Setting the xpinstall.signatures.requir ed about:config key to false is ignored in "branded" builds of the stable and beta channels, but it's obeyed in the following release channels:

ESR (Extended Support Release for organizations, ie. oldstable):
https://www.mozilla.org/en-US/fir...

Unbranded builds for the stable and beta channels:
https://wiki.mozilla.org/Add-ons/...

Developer Edition (ie. alpha channel):
https://www.mozilla.org/en-US/fir...

Nightlies:
https://www.mozilla.org/en-US/fir...

Honestly, if you have to remove the option because of how persistent and clever attackers have gotten, that's a pretty good balance to strike. The two editions average users will gravitate to, but not the unbranded versions of them, nor the versions targeted at organizations or developers.

Edited 2018-06-13 19:36 UTC
Permalink - Score: 2
.
RE[3]: Locking down the "open" browsers.
By Ford Prefect on 2018-06-13 21:56:15
Except that dialogs never worked, ever, to prevent unwitting users from doing harmful things on their computer.

Dialogs are these things in Windows that annoy you until you make them go away.

It's the same thing with Android's old permission system. Another dialog that you grudgingly accept when installing an app.

Yes there are people who are nazis about it or people who apply their common sense and actually try to comprehend what is going on, but these are not the users that need protection in the first place.


The struggle between freedom and user protection is real, and while I am all for freedom, there is no easy answer to it (certainly not "let's just slap another dialog on it").

Edited 2018-06-13 21:57 UTC
Permalink - Score: 4
.
RE[4]: Locking down the "open" browsers.
By Alfman on 2018-06-13 22:46:50
Ford Prefect,

> The struggle between freedom and user protection is real, and while I am all for freedom, there is no easy answer to it (certainly not "let's just slap another dialog on it").

No need to get fancy, just disable it by default, and let users who care go into about:config to change it. Done.

Not for nothing, but I was a kid once and computers then had virtually no protections from user error. The computers did what you asked whether it was dangerous or not. You know what, things worked out fine. I learned how to fix things and how to be responsible. I also learned how to modify them to make them better. If it weren't for the unhindered low level accessibility that I benefited from, my skills would be largely stunted today.


I think protecting people against their will is actually doing them and society a larger disservice than we are admitting. These policies that make it increasingly difficult to go under the hood ultimately increase the knowledge gap between laymen and specialists. We complain about people being dumb, yet we're guilty of creating the technology that keeps them dumb.

Edited 2018-06-13 22:58 UTC
Permalink - Score: 1

Read Comments 1-10 -- 11-20 -- 21-30 -- 31-40 -- 41-50 -- 51-60 -- 61-70 -- 71-73

No new comments are allowed for stories older than 10 days.
This story is now archived.

.
News Features Interviews
BlogContact Editorials
.
WAP site - RSS feed
© OSNews LLC 1997-2007. All Rights Reserved.
The readers' comments are owned and a responsibility of whoever posted them.
Prefer the desktop version of OSNews?