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[6]: Locking down the "open" browsers.
By oiaohm on 2018-06-14 05:36:03
> 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.


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


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

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.
Permalink - Score: 3
.
RE[7]: Locking down the "open" browsers.
By Alfman on 2018-06-14 13:12:39
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/...

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
Permalink - Score: 2
.
RE[8]: Locking down the "open" browsers.
By oiaohm on 2018-06-14 13:39:05
> 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.

The thing is you have two groups of users asking for mutually exclusive things. So you have those asking for security for banking and the like who really don't care about side loading but security is foremost. Then you have those who want to side load where security is not foremost.


> 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.
Lot of attacks against legitimate in store extensions have been fixed since them.

So allowing sideloading made the damage from flaws in legitimate extensions worse.

Not exactly signing even with legitimate store extensions with flaws the persistence was reduced.
>
> 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/...

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. Again, we should aim for secure by default, but respect owner's wishes to customize.


Chrome will forced at some point to remove switch as well. Attackers have got very good at changing the switches without users noticing.

Sometimes the right choice is user needing to choose at installation if particular features are on offer or not.

Really its foolish to attempt to cover everyone needs with 1 program when the needs are in fact mutually exclusive.

Really have you been able to describe a switch attackers could not modify. Please do not say the chrome command line one as there are already attacks that get past that. Firefox default of not allow so far as not been defeated.

Now requesting a unbranded that is released with the same versions as the stable for development and the like would be valid request in some ways. Drop the switch idea unless you can design something attackers are not documented defeating.

Alfman really you want to blame the developers without consider the problem they have in front them.

If web brower gets know as a likely browser to have you bank raid how long will it have market share. So security is a serous problem.

Of course the issue with development version breaking and the like is different problem to allow signed extensions right. For developers could there not be a unbranded same versions as branded release that follow the same versions as the branded in auto updates. Thinking unbranded the same versions as the release are on the mozilla servers just not with aligned update.

Basically have the unbranded fixed up to do this would provide a route for everyone legal to have what they want while making attackers life has hard as possible.
Permalink - Score: 3
.
RE[9]: Locking down the "open" browsers.
By Alfman on 2018-06-14 13:54:12
oiaohm,

> The thing is you have two groups of users asking for mutually exclusive things. So you have those asking for security for banking and the like who really don't care about side loading but security is foremost. Then you have those who want to side load where security is not foremost.

I'm sorry, but it is absolutely wrong and disingenuous to claim that these are mutually exclusive. That's the whole point since the first post, what I'm asking for gives everyone what *they* want on *their own* devices. What you are asking for gives you what *you want* on *my device*. But why should you or anyone else have a say what goes on on my device?

Edited 2018-06-14 14:04 UTC
Permalink - Score: 1
.
RE: Locking down the "open" browsers.
By psychicist on 2018-06-14 14:49:49
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.
Permalink - Score: 0
.
RE[2]: Locking down the "open" browsers.
By ssokolow on 2018-06-14 17:25:47
> 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/platf...

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.
Permalink - Score: 3
.
RE[5]: Locking down the "open" browsers.
By echo.ranger on 2018-06-14 21:15:59
> 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.
Permalink - Score: 3
.
RE[6]: Locking down the "open" browsers.
By Alfman on 2018-06-14 21:45:09
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.
Permalink - Score: 2
.
RE[7]: Locking down the "open" browsers.
By ssokolow on 2018-06-14 22:35:47
> 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
Permalink - Score: 2
.
RE[7]: Locking down the "open" browsers.
By oiaohm on 2018-06-14 23:26:00
> > 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
Permalink - Score: 2

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?