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
.
Post a new comment
Read Comments: 1-10 -- 11-20 -- 21-30 -- 31-40 -- 41-50 -- 51-60 -- 61-70 -- 71-73
.
RE[3]: Locking down the "open" browsers.
By Alfman on 2018-06-13 13:44:12
WorknMan,

> It's really not that hard. Just make side-loading a hoop you have to jump through to turn it on, such that nobody's ever going to do it without having to look up directions. And when they turn it on, make them 'OK' about three dialogs that say, 'WARNING: THIS IS NOT A GOOD IDEA!!!!'

At that point, I think app developers have done their part to sufficiently protect users from themselves, and also giving users the freedom to do what they want, while sufficiently warning them of potential dangers.


Precisely!


> IMO, unless they're on an enterprise network or something, it's ultimately up to users to decide what to do.

Group policy handles this well, although I'm not sure what the chrome browser supports in terms of group policy.

For a commercial application I work on, the local user settings can be overridden by registry keys that can be locked down if desired in an enterprise setting. But we certainly don't cripple our product for everyone else!
Permalink - Score: 2
.
RE[4]: Locking down the "open" browsers.
By Alfman on 2018-06-13 13:58:57
ahferroin7,

> The thing is though, most people really don't need to be able to sideload extensions from an inline link on a website, which is what this is disabling.
...
You can still side-load via direct injection into the profile, or by manually loading things on the local system, you just won't be able to click a download link and directly install stuff.



I hope you are right, but that's not the way I read it. It sounds like google's store is going to be a requirement and that extensions that have already been sideloaded will actually be disabled.

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

This change will roll out in three phases:

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.



> Realistically, I doubt that most distros will care, it's technically improving security, and not likely to impact a vast majority of their users.

So by that reasoning, would you be in support of google disabling android side loading and killing off alternatives like fdroid?
Permalink - Score: 2
.
RE[5]: Locking down the "open" browsers.
By ahferroin7 on 2018-06-13 14:21:41
There's far less incentive for them to do so on Android though. It's pretty difficult to trick a person into granting a special app permission or go through side-loading via ADB, whereas CHrome just requires the person to click 'Yes' on one dialog that is by no means scary.

Realistically though, most people wouldn't care on Android either, as just like Chrome, it's a reasonably small population who use such thing.

Note that I'm not advocating that they should do this. Personally, I'd much rather having something you have to turn on to allow sideloading at all (they should have had this from the start though), plus a much scarier dialog when you try to side-load something. I'm just stating that realistically, it probably won't affect a vast majority of their user-base negatively.
Permalink - Score: 3
.
RE[6]: Locking down the "open" browsers.
By Alfman on 2018-06-13 14:47:38
ahferroin7,

> Realistically though, most people wouldn't care on Android either, as just like Chrome, it's a reasonably small population who use such thing.

My take on this is pretty simple:
My freedom to enable sideloading does not conflict with the majority's right not to enable sideloading. We can all have our way on our own devices.


> Note that I'm not advocating that they should do this. Personally, I'd much rather having something you have to turn on to allow sideloading at all (they should have had this from the start though), plus a much scarier dialog when you try to side-load something.

So you, WorknMan, and I are all in agreement on this point.

Edited 2018-06-13 14:53 UTC
Permalink - Score: 2
.
RE[4]: Locking down the "open" browsers.
By oiaohm on 2018-06-13 14:59:48
> WorknMan,

> It's really not that hard. Just make side-loading a hoop you have to jump through to turn it on, such that nobody's ever going to do it without having to look up directions. And when they turn it on, make them 'OK' about three dialogs that say, 'WARNING: THIS IS NOT A GOOD IDEA!!!!'

At that point, I think app developers have done their part to sufficiently protect users from themselves, and also giving users the freedom to do what they want, while sufficiently warning them of potential dangers.


Precisely!


> IMO, unless they're on an enterprise network or something, it's ultimately up to users to decide what to do.

Group policy handles this well, although I'm not sure what the chrome browser supports in terms of group policy.

For a commercial application I work on, the local user settings can be overridden by registry keys that can be locked down if desired in an enterprise setting. But we certainly don't cripple our product for everyone else!


Think closer what describe has already been tried so was voted down for very good reasons..

https://support.mozilla.org/en-US...

Malware did start enabling auto validation off.
https://www.theregister.co.uk/201...

Prefab attack tools have started appearing 3 years back those include automatically disable extension validation checks.

So we are to the point for security having an on/off switch for validation is not an option. Users general users don't in most case need the ability to run unsigned extensions there is no point putting the largest percentage of users at risk.

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.

The idea of putting a control anywhere is just a switch the hostiles are going to exploit.

Alfman the reality here the bugs asking for this are not on the public bugzilla but in the security list.

So far you have not suggested a workable solution. Start thinking you have hostile who want to embed in your browser to collect your bank details and other things and will work out ways of changing applications settings to let them do that. You have to make that as hard as possible.

This now means you need the browser split in 2. Users not needing to side load unsigned extensions need to be split from those who need to side load unsigned extensions because loading unsigned extensions is a heck of a security risk.
Permalink - Score: 3
.
RE[5]: Locking down the "open" browsers.
By Alfman on 2018-06-13 15:32:15
oiaohm,

> Think closer what describe has already been tried so was voted down for very good reasons..

https://support.mozilla.org/en-US...


I think you posted the wrong link? If not then I don't get your point, the guy's asking how to re-enable the disabled addons. The thread ends with no solution given for firefox 44 onwards.


> Malware did start enabling auto validation off.
https://www.theregister.co.uk/201...

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.



> So we are to the point for security having an on/off switch for validation is not an option. Users general users don't in most case need the ability to run unsigned extensions there is no point putting the largest percentage of users at risk.

On the contrary, having a switch satisfies the needs of both crowds. As we've said, hide the option so that only people looking for it will enable it.

Edited 2018-06-13 15:42 UTC
Permalink - Score: 2
.
RE[3]: Locking down the "open" browsers.
By grat on 2018-06-13 17:08:45
> And when they turn it on, make them 'OK' about three dialogs that say, 'WARNING: THIS IS NOT A GOOD IDEA!!!!'

Except that we've spent years teaching users to ignore SSL errors, ignore UAC warnings, and pretty much all other "Are you sure you want to do this?" dialogs.

In fact, the standard method for dealing with those pesky UAC prompts? Turn off UAC! People on this site, who theoretically ought to know better, turn it off all the time, and brag about it.

Security prompts have been made meaningless.
Permalink - Score: 5
.
There is some confusion here I think...
By galvanash on 2018-06-13 17:08:46
Inline installation is not sideloading...

You can't and never have been able to use it to sideload unsigned extensions, that is not what it is for. It is used to install extensions from the chrome app store, it is simply a way for a web site to trigger said installation without the user having to actually visit the app store themselves.

This change simply means that instead of the extensions automatically installing after the user prompts, the user instead is redirected to the app store to complete the install. That's it. It's better this way. Really...

Users press OK. They always do. Its not a good idea to let website's have the power to trigger an extension install like this, too many users just don't read the prompts and hit OK. This way they will actually get sent to the apps page in the store and will have to hit the install button themselves.

Sideloading is still possible (although its complicated, as it has always been). Inline installation has nothing to do with sideloading, nothing at all...

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

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

Edited 2018-06-13 17:15 UTC
Permalink - Score: 4
.
RE[3]: Locking down the "open" browsers.
By grat on 2018-06-13 17:11:59
> Well then I challenge you to find a single instance of a bug report/feature request where an end user has asked the devs to disable their ability to enable sideloading.
Technically correct, but totally wrong. What the users want protection from is clicking on a link, and being tricked into installing an extension that turns their browser into an ad-infested crypto-currency mining pig.

See my rant about security warnings having no meaning any longer, and the only reasonable way to fix this is to disable side-loading.

Personally, I'd rather they took the Android approach, and require you to go to another menu and manually enable side-loading first-- at least that way, there's some level of user-initiated action.

I wonder if I'm the only one who disables side-loading after I side-load an app on my android devices?
Permalink - Score: 3
.
RE[4]: Locking down the "open" browsers.
By darknexus on 2018-06-13 17:58:06
You contradict your own point though. The very fact that you can side load an app on your Android devices and then disable it is the very freedom that Google is trying to kill in Chrome. If the only solution is to disable side loading for everyone, are you going to give up those apps you side-loaded when Android's turn comes around?
Permalink - Score: 0

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

Post a new comment
Username

Password

Title

Your comment

If you do not have an account, please use a desktop browser to create one.
LEAVE SPACES around URLs to autoparse. No more than 8,000 characters are allowed. The only HTML/UBB tags allowed are bold & italics.
Submission of a comment on OSNews implies that you have acknowledged and fully agreed with THESE TERMS.
.
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?