Linked by Thom Holwerda on Tue 12th Jun 2018 23:21 UTC
Google

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?

Order by: Score:
Okay, Google ...
by WorknMan on Wed 13th Jun 2018 01:38 UTC
WorknMan
Member since:
2005-11-13

We strive to ensure choice and transparency for all Chrome users as they browse the web.


https://www.youtube.com/watch?v=ztVMib1T4T4

Reply Score: 5

Comment by ssokolow
by ssokolow on Wed 13th Jun 2018 01:56 UTC
ssokolow
Member since:
2010-01-21

Always nice to see Google giving Mozilla a helping hand. (Firefox still allows inline installation, but mitigates the risk by having more human overview on what extensions they sign.)

That said, this seems to only affect the APIs used for triggering an extension install from within a website, so I'm sure this will just push such extensions to encourage people to add --enable-easy-off-store-extension-install to their Chrome launcher and then install the extension via the offline workflow for unsigned extensions.

...and if that goes away, we'll probably see ad-blockers that run inside userscript hosts, daring Google to restrict all userscripts.

Edited 2018-06-13 02:03 UTC

Reply Score: 3

Locking down the "open" browsers.
by Alfman on Wed 13th Jun 2018 06:05 UTC
Alfman
Member since:
2011-01-28

Firefox and now chrome. We expect this from closed/proprietary software, but it's disappointing to see open source browsers going this route now too. This is so short sighted and goes against the principals of FOSS philosophy. No users were asking for forcefully imposed restrictions in either case. Sideloading should be a choice.


https://developer.mozilla.org/en-US/Add-ons/Distribution

Add-ons need to be signed before they can be installed into release and beta versions of Firefox. This signing process takes place through addons.mozilla.org (AMO), whether you choose to distribute your add-on through AMO or to do it yourself.

...

Starting with Firefox 43, add-on extensions and multi-item add-ons that include extensions need to be signed by Mozilla before they can install in release and beta versions of Firefox. Themes, and other types of add-ons such as spelling dictionaries, don't need to be signed.


This disgusts me, 3rd party innovation should be a right, not a privilege. At least with open source, 3rd parties can remove these anti-features and publish unofficial owner-friendly versions like waterfox and srware iron.

https://www.waterfoxproject.org/en-US/
https://www.srware.net/en/software_srware_iron.php


Ironically we have to sideload the full browser now just to allow sideloaded extensions. However sideloading browsers is another right that's under attack by some vendors.

What happened here? Computers used to be about promoting innovation and empowering users, but we're making a decidedly dark turn by stripping our choices and deploying technology in ways that restrict us and hold back innovation in order to control us ;)

Reply Score: 2

ahferroin7 Member since:
2015-10-30

Strictly speaking, Google Chrome is not open source, it's proprietary. Chromium is open source, but Chrome is not.

Reply Score: 3

Alfman Member since:
2011-01-28

ahferroin7,

Strictly speaking, Google Chrome is not open source, it's proprietary. Chromium is open source, but Chrome is not.


Hasn't chrome (the proprietary build) always been restricted?
https://www.howtogeek.com/202825/what%E2%80%99s-the-diff...
Extension Restrictions. For Chrome, Google disables extensions that are not hosted in the Chrome Web Store.


It's possible that I'm mistaken, but with this announcement coming from chromium.org, I assume it means that the open source chromium version will also become locked down going forward.

https://blog.chromium.org/2018/06/improving-extension-transparency-f...


It makes me wonder if linux distros will push out browsers with sideloading by users prohibited?

Ubuntu repos only offer chromium, you actually have to add a 3rd party repo to install google's proprietary chrome browser.
https://askubuntu.com/questions/510056/how-to-install-google-chrome

If anyone has answers, please weigh in.

Reply Score: 2

ahferroin7 Member since:
2015-10-30

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. In fact, that method of sideloading is a common secondary component of social engineering attacks, which is most likely why Google is doing this. 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.

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

Reply Score: 3

Alfman Member since:
2011-01-28

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?

Reply Score: 2

ahferroin7 Member since:
2015-10-30

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.

Reply Score: 3

Alfman Member since:
2011-01-28

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

Reply Score: 2

ssokolow Member since:
2010-01-21

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

Reply Score: 2

FlyingJester Member since:
2016-05-11

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.

Reply Score: 2

oiaohm Member since:
2009-05-30

Firefox and now chrome. We expect this from closed/proprietary software, but it's disappointing to see open source browsers going this route now too. This is so short sighted and goes against the principals of FOSS philosophy. No users were asking for forcefully imposed restrictions in either case. Sideloading should be a choice.


Sorry there are users asking to be protected from malware infected browsers. So claiming no users are asking for this is wrong.


https://developer.mozilla.org/en-US/Add-ons/Distribution
"Add-ons need to be signed before they can be installed into release and beta versions of Firefox. This signing process takes place through addons.mozilla.org (AMO), whether you choose to distribute your add-on through AMO or to do it yourself.

...

Starting with Firefox 43, add-on extensions and multi-item add-ons that include extensions need to be signed by Mozilla before they can install in release and beta versions of Firefox. Themes, and other types of add-ons such as spelling dictionaries, don't need to be signed.


This disgusts me, 3rd party innovation should be a right, not a privilege. At least with open source, 3rd parties can remove these anti-features and publish unofficial owner-friendly versions like waterfox and srware iron.
"

Malware infected browser is not an owner-friendly thing. Yes what Mozilla has done is hard. Doing nothing is also wrong.

Ironically we have to sideload the full browser now just to allow sideloaded extensions. However sideloading browsers is another right that's under attack by some vendors.

What happened here? Computers used to be about promoting innovation and empowering users, but we're making a decidedly dark turn by stripping our choices and deploying technology in ways that restrict us and hold back innovation in order to control us ;)


Really open source software has to protect reputation as well to have end users. Having malware sideloading is not a good thing for reputation.

Basically instead of being annoyed see if you can design a more flexible system that meet the requirement of protect users who want malware protection with third party vetted extentions and those who want to side load.

Really I think those two are in fact mutually exclusive. To prevent malware loading all executable extensions have to be vetted by someone.

This might be a case were firefox and chrome need two brand names. One for those who want to side load and one for those who want the security of third party vetted. Of course nothing says mozilla/google could not make both.

Reply Score: 3

WorknMan Member since:
2005-11-13

Basically instead of being annoyed see if you can design a more flexible system that meet the requirement of protect users who want malware protection with third party vetted extentions and those who want to side load.


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.

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

Edited 2018-06-13 12:46 UTC

Reply Score: 1

Alfman Member since:
2011-01-28

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!

Reply Score: 2

oiaohm Member since:
2009-05-30

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/questions/1101877

Malware did start enabling auto validation off.
https://www.theregister.co.uk/2016/04/04/top_firefox_extensions_can_...

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.

Reply Score: 3

Alfman Member since:
2011-01-28

oiaohm,

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

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



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/2016/04/04/top_firefox_extensions_can_.....


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

Reply Score: 2

ssokolow Member since:
2010-01-21

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.

Reply Score: 3

oiaohm Member since:
2009-05-30

oiaohm,

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

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



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

That is the right link 2015 is when the problem appears. The reason why that feature is being removed back then is there is a problem.


"Malware did start enabling auto validation off.
https://www.theregister.co.uk/2016/04/04/top_firefox_extensions_can_...


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

You did not read carefully enough.
The method described relies on a popular add-on that is vulnerable to be installed, and then for the add-on that takes advantage of that vulnerability to also be installed.
This here is in fact sideloading. So a weakness in browser so malware has a long term presence it sideloads it own extension.


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.

Attacker are looking for the option and will code it into their sideloading solution if it possible.

ssokolow finds that I could remember where it was. Firefox splits into 2 when the remove the feature to install extensions unsigned from branded forms their browser.
https://wiki.mozilla.org/Add-ons/Extension_Signing#Unbranded_Builds

The unbranded builds can be installed next to the firefox branded builds. The unbranded has extension signing off can be option. Like you are doing banking and the like having your extensions validated most cases a good thing and this will be safer done by branded form of firefox where extension signing checks cannot be turned off.

Now if you are testing out some new prototype extension as a developer you will be using the unbranded forms. If you are needing to side load something that mozilla will not approve(ok this could be really dangerous) again unbranded form and harm comes to you its your fault.

This is a fairly good compromise particular when you wake up in 2015 attackers started sideloading hostile extensions.

Yes Mozilla has given another option to the prior configuration on off switch. Of course the way Mozilla has done you have to intentionally install a particular versions that are intentionally not heavily advertised to use unsigned extensions so you should know what you are getting yourself into. Its not like Mozilla with firefox has made it absolutely impossible to use unsigned extensions.

Reply Score: 3

Alfman Member since:
2011-01-28

oiaohm,

That is the right link 2015 is when the problem appears. The reason why that feature is being removed back then is there is a problem.


Well duh, we know it's a problem. It's a problem caused when devs started imposing restrictions on users rather than listening to what the users needed & wanted. Go back a couple posts you claimed users were asking for this, yet your link is evidence of the exact opposite where users are asking how to disable the restrictions.


You did not read carefully enough.
The method described relies on a popular add-on that is vulnerable to be installed, and then for the add-on that takes advantage of that vulnerability to also be installed.
This here is in fact sideloading. So a weakness in browser so malware has a long term presence it sideloads it own extension.


Except that official legitimate store extensions were vulnerable too.

ssokolow finds that I could remember where it was. Firefox splits into 2 when the remove the feature to install extensions unsigned from branded forms their browser.
https://wiki.mozilla.org/Add-ons/Extension_Signing#Unbranded_Builds

The unbranded builds can be installed next to the firefox branded builds. The unbranded has extension signing off can be option. Like you are doing banking and the like having your extensions validated most cases a good thing and this will be safer done by branded form of firefox where extension signing checks cannot be turned off.


I used to run the dev versions, but I've stopped running the dev builds due to broken updates. A better way to handle it would have been to have a switch and just not support users who have sideloaded extensions enabled, that approach would cover everyone's needs better without requiring users to get developer builds. We should aim for secure by default, but respect owner's wishes to customize.

Then again my opinion stems from a firm belief in openness where owners are in control. I strongly oppose a future where owners can't do things on their own devices because someone else holds the keys. If you don't have this belief in openness like I do, then of course you'll be more amenable to restrictions like these.

Edited 2018-06-14 13:28 UTC

Reply Score: 2

WorknMan Member since:
2005-11-13

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.

Reply Score: 2

ssokolow Member since:
2010-01-21

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-extension-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.required 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/firefox/organizations/

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

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

Nightlies:
https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly

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

Reply Score: 2

grat Member since:
2006-02-02

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.

Reply Score: 5

WorknMan Member since:
2005-11-13


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....' ;)

Reply Score: 0

Ford Prefect Member since:
2006-01-16

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

Reply Score: 4

Alfman Member since:
2011-01-28

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

Reply Score: 1

echo.ranger Member since:
2007-01-17

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.



The people who need this protection are the ones who aren't interested in decreasing their knowledge gap; they're interested in completing a task or visiting a site or paying their bills online or whatever. These people should be protected precisely because they A) have no interest in taking additional steps on their own, and B) because of A are a likely avenue of attack. Not doing anything, or telling people to "learn" isn't going to solve anything.

Reply Score: 3

Alfman Member since:
2011-01-28

echo.ranger,

The people who need this protection are the ones who aren't interested in decreasing their knowledge gap; they're interested in completing a task or visiting a site or paying their bills online or whatever. These people should be protected precisely because they A) have no interest in taking additional steps on their own, and B) because of A are a likely avenue of attack. Not doing anything, or telling people to "learn" isn't going to solve anything.


...which is exactly why we are in favor of disabling it by default but allowing those who explicitly search for it to turn it on. It's the best solution satisfying the needs of both types of people. It's like sideloading on android, normal users benefit from the protection of the app store, but power users who need & want more control can change the policy on their own devices.

Reply Score: 2

ssokolow Member since:
2010-01-21

echo.ranger,

"The people who need this protection are the ones who aren't interested in decreasing their knowledge gap; they're interested in completing a task or visiting a site or paying their bills online or whatever. These people should be protected precisely because they A) have no interest in taking additional steps on their own, and B) because of A are a likely avenue of attack. Not doing anything, or telling people to "learn" isn't going to solve anything.


...which is exactly why we are in favor of disabling it by default but allowing those who explicitly search for it to turn it on. It's the best solution satisfying the needs of both types of people. It's like sideloading on android, normal users benefit from the protection of the app store, but power users who need & want more control can change the policy on their own devices.
"

Side-loading is different because it's an OS-level setting that the OS can reliably deny applications the ability to programmatically toggle.

Anything Firefox can do, another Win32/POSIX/etc. app can do because they both have the same privilege level when it comes to available persistent storage APIs.

(TL;DR: Android runs apps in a sandbox and stores the sideloading setting's state outside that sandbox. To do the same for Firefox, it would have to run and store its data in an execution context that legacy "can mess with anything in the user account" Win32/POSIX applications can't touch.)

Edited 2018-06-14 22:38 UTC

Reply Score: 2

oiaohm Member since:
2009-05-30

"The people who need this protection are the ones who aren't interested in decreasing their knowledge gap; they're interested in completing a task or visiting a site or paying their bills online or whatever. These people should be protected precisely because they A) have no interest in taking additional steps on their own, and B) because of A are a likely avenue of attack. Not doing anything, or telling people to "learn" isn't going to solve anything.


...which is exactly why we are in favor of disabling it by default but allowing those who explicitly search for it to turn it on. It's the best solution satisfying the needs of both types of people. It's like sideloading on android, normal users benefit from the protection of the app store, but power users who need & want more control can change the policy on their own devices.
"

Power users can install a different version. This is the reality. Normal users needing the protection don't want to have the skills to have to check if unsigned sideloading is on or off. Think about a chromebook in developer mode it displays a message every boot warning user. Power users of browsers don't want to put up with this either.

If you explicitly search it on mozilla site you will find the unbranded version that does what some power users want. Please note not all power users want to have the ability to side load unsigned either. Because some power users only use firefox and the like for banking and actions like where they want everything as secure as possible.

The group wanting unsigned side loading and the group needing protection are mutually exclusive.

You ask both groups want they want when you attempt to make it work you in hell.

Groups wanting protections.
1) Don't want to have any knowledge to have the protection.
2) Don't want to see warning messages they have to fix if the protection has been disabled just prefer it not able to be disabled.
3) Large percent of the group wanting protection are not power users so don't have a large amount of knowledge to fix anything.

Groups not wanting the protection.
1) Don't want a warning message every single time they run their browser to display the weaken security.
2) They don't want to have to-do per device unlocking that would most likely involve adding more DRM code to firefox.

Android devices where you can unlock the boot loader by contacting vendor and getting per device id code means attacker cannot do this on mass simply. This cannot be done to firefox. The per device unlocking is the other way to make it as hard a possible for the attackers. 2 versions of the application is way nicer than this.

The idea of a hidden control option does not cut it as the option cannot be hidden and has to be in in face choice and in the fact difference.

Requiring a different installer is in face the groups not wanting the protection get to agree once to it. No message to bug users who don't have skill to fix it. No message to bug users who don't want the protection.

The reality is the best solution for this is split into two different named productions built from the same source. The name tells you the protection level. Also splitting in two covers the case power user wants protection on some sites and not on others.


Remember the message information user that protection is off if you did a program embedded option cannot be something they can automatically click though. So highly annoying. Way more annoying than having to install a different version of program..

Alfman trying to do this as 1 application you are going to either not properly protect the users who need protection or annoy the live hell out of power users every time they run the program without protection. This is truly a mutually exclusive problem the happiest solution for most two groups of applications. Of course you cannot make everyone 100 percent happy so we have people like you who don't really understand problem and don't attempt to fix it and take a overly simplistic view of the problem so complaining.

Edited 2018-06-14 23:28 UTC

Reply Score: 2

zima Member since:
2005-07-06

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.

They were also much less useful back then; and for example you probably wouldn't want to do online banking with them...

Reply Score: 2

Alfman Member since:
2011-01-28

oiaohm,

Sorry there are users asking to be protected from malware infected browsers. So claiming no users are asking for this is wrong.

Malware infected browser is not an owner-friendly thing. Yes what Mozilla has done is hard. Doing nothing is also wrong.




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.

The reason your premise is wrong is because users who don't want siding don't have to enable it in the first place.

There's a huge moral difference between changing the defaults to help keep users safe and forcefully imposing restrictions on everyone; we need more Richard Stallmans to fight this mentality!

Edited 2018-06-13 13:36 UTC

Reply Score: 2

grat Member since:
2006-02-02

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?

Reply Score: 3

darknexus Member since:
2008-07-15

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?

Reply Score: 0

grat Member since:
2006-02-02

On android, I don't get a pop-up that offers to enable side-loading-- and even if I did, it would warn me that something nefarious is trying to happen.

The difference is that Chrome can still trick you into loading an application from a non-approved source. I'm OK with that being disabled.

I would like the option to manually enable side-loaded apps, however, even if it means going into chrome settings.

Reply Score: 2

Alfman Member since:
2011-01-28

grat,

On android, I don't get a pop-up that offers to enable side-loading-- and even if I did, it would warn me that something nefarious is trying to happen.

The difference is that Chrome can still trick you into loading an application from a non-approved source. I'm OK with that being disabled.

I would like the option to manually enable side-loaded apps, however, even if it means going into chrome settings.


Yep, anyone who believes in sideloading being a choice (rather than being forced into a walled garden) should agree with that.

Reply Score: 2

psychicist Member since:
2007-01-27

What happened here is that we should use browsers other than Chrome and Firefox. No companies should ever be allowed to acts as gatekeepers to an open web.

Chrome and Chromium only support x86 and ARM. Firefox is going down the Rust hole. So I will try to make the transition to browsers that are free software and not biased towards any architecture in particular.

I hope GNOME Web (formerly known as Ephiphany) and Falkon (formerly known as Qupzilla) will be good enough and work across architectures, so Google and Mozilla can keep their browsers to themselves.

Reply Score: 0

ssokolow Member since:
2010-01-21

What happened here is that we should use browsers other than Chrome and Firefox. No companies should ever be allowed to acts as gatekeepers to an open web.

Chrome and Chromium only support x86 and ARM. Firefox is going down the Rust hole. So I will try to make the transition to browsers that are free software and not biased towards any architecture in particular.


The Rust compiler supports every target LLVM does and has been a driving factor in writing or improving LLVM backends like the in-progress AVR backend and then more-complete MSP430 backend.

https://forge.rust-lang.org/platform-support.html

Even in C++, you don't magically support every compiler without effort, so I'm curious which platform pre-Rust Firefox supported that LLVM does not.

Reply Score: 3

Testbed
by darknexus on Wed 13th Jun 2018 12:17 UTC
darknexus
Member since:
2008-07-15

If users accept this, Android will probably be next.

Reply Score: 1

There is some confusion here I think...
by galvanash on Wed 13th Jun 2018 17:08 UTC
galvanash
Member since:
2006-01-25

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/external_extensions

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

Edited 2018-06-13 17:15 UTC

Reply Score: 4

Alfman Member since:
2011-01-28

galvanash,

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

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

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/a/answer/188453
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 ;)

Reply Score: 2

galvanash Member since:
2006-01-25

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-chrome-extension-from-file

Edited 2018-06-13 19:19 UTC

Reply Score: 4