Chrome limits off-store extension installs

https://code.google.com/p/chromium/issues/detail?id=128748

by Osmose • 14 years ago

63 84 14 years ago

code.google.com

SnowLprd• 14 years ago

This change is being made without any buy-in from the community, ostensibly for security reasons. I'm skeptical, given the inherent incentives involved.

nimbupani3• 14 years ago

I have no issues with the process, but only concerned with the way this change was made. The issue keeps referring to https://code.google.com/p/chromium/issues/detail?id=55584 for "details", but there is nothing there except statements asserting how much of a "big problem" this is.

I think this is a bigger problem with large open source projects in general where implementors are oblivious to which functionalities developers cherish and value. Any change in such features would require a more thorough explanation.

Osmose• 14 years ago

It may be an issue of having multiple channels of communication, and the bug tracker is only one of them.

For example, though I work for Mozilla, I'm not terribly good at keeping up with the mailing lists, so every so often something pops up in Bugzilla (which I read more frequently) that seems to have come out of nowhere.

And of course stuff happens in our IRC channels that never makes it to a bug; same with internal emails. There's a lot of effort involved in making sure your communication is clear and accessible when you have several different modes of it.

nimbupani3• 14 years ago

This is very similar to issues in W3C specifications. I just think a bug tracker should be the primary reference material to track discussions around a specific bug. I wish there was a way to link to IRC channel discussion around this bug and otherwise if possible.

But nevertheless, I think it would be better if implementors summarize discussions outside of the bug tracker into the issue itself.

eigenvector• 14 years ago

This nicely illustrates the difference between merely being "open source" (Chromium) and being developed in the open (Firefox). At the very least a decision of this magnitude would have been discussed in the community BEFORE being merged in any sane openly governed project.

justinschuh15• 14 years ago

I don't know why you're claiming this wasn't developed openly. The bugs are all public (the first was filed ~2 years ago); the code is checked into the public tree and has been enabled on canary for almost a month. It wasn't a heavy-handed or rash change, and the impact on both users and developers is minimal.

apendleton• 14 years ago

For those of us that have already-deployed off-store extensions in the wild, what options do we have for migrating our users to the new, Webstore-powered versions? Or will their extensions just silently stop updating (or, worse, working altogether)? If it's the latter, your claim that this change will have minimal impact on developers and users is patently false, since you'll be breaking currently-released and -deployed applications that used to work and met the previously-documented requirements, with no warning whatsoever. Further, the suggestion that this is justified because it was committed to a public repository is absurd: are all developers of Chrome applications supposed to follow every single commit to Chromium's repo to ensure that our extensions won't break? What happened to Chrome's supposed immunity to breaking extensions with new releases, which you claimed made your extension model superior to Firefox's?

petegrif2• 14 years ago

I'm sorry. This is NOT a meaningful channel. And this is NOT appropriate communication. But to be honest, what I find most scary about this is the fact that you think it is.

jonknee4• 14 years ago

This is a pretty big change to bring in without warning. It would be nice if extensions could be signed but not on the store. I have extensions for internal business apps, they make no sense on the store but having a techy installation process is a big hassle. Google could even host the code (and have the ability to revoke), I just want a way to have "private" extensions that only only delivered to who I want.

tiziano882• 14 years ago

From the discussion: "In order to install off-store extensions, the user must download them to a directory and drag them onto chrome://extensions/.". Is this not a viable solution for your use case?

Kerrick7• 14 years ago

For one thing, this can't be done without a mouse to drag-and-drop with. This limits the extension of off-store extensions to those who can use a mouse, which is an accessibility issue. Are handicapped users or keyboard-only users just thrown to the wayside these days?

jonknee4• 14 years ago

I guess we will find out, that sounds like a pretty big roadblock for the skill level of users I am working with.

There seem like there's a better solution out there, at leat for my use case. I serve the crx bundle from the same domain that it interacts with, that seems like it could be pretty malware proof.

rictic• 14 years ago

From the discussion it looks like the chrome devs want to support this use case. I think the idea is that you can add more trusted installation locations.

jonknee4• 14 years ago

That's great, but what's the enterprise supposed to do? You don't want ABC Corp CRM app in the Google store, it only makes sense to people who work for ABC Corp.

justinschuh15• 14 years ago

I thought I explained the reasoning on the bug, but I can give it another go. Users are being tricked into installing malicious extensions, and thus getting compromised in significant numbers (Facebook "like" selling is a major target). We have continuously improving measures in the WebStore to catch malicious extensions, and the volume there is very low. However, we don't have a way of catching malicious off-store extensions. So, the best solution is to disallow other sources by default, and provide technically inclined users and enterprise administrators with the ability to add trusted sources.

This is basically the same model that every Linux distro uses, so I'm not sure what the complaints are about. I'm also surprised Firefox hasn't proposed something similar, since I'm told they're seeing the same trend.

icebraining2• 14 years ago

This is basically the same model that every Linux distro uses, so I'm not sure what the complaints are about.

What do you mean? In both Debian and Ubuntu I can install a .deb (equivalent to .crx) just fine. I don't have to approve its source beforehand.

justinschuh15• 14 years ago

The extension manifest has update information in it, so when you install a CRX you're inherently configuring an installation source. That's something you have to take into account here.

Kerrick7• 14 years ago

Indeed. I can simply double click a downloaded .deb file and it'll install. To get the equivalent of this new Chrome policy, it'd have to require me to save the .deb file to a specific location, open Synaptic Package Manager, and click-and-drag the .deb file into the package manager to install it.

dzohrob4• 14 years ago

The complaints are about a major change occurring with little warning.

For context, I've spent the last 2 months working on an extension that asks users to install from our site during signup. Making them install through the Web Store will increase confusion (why am I no longer on CoolWebsite.com?) and hurt conversion rates.

notatoad• 14 years ago

>Making them install through the Web Store will increase confusion and hurt conversion rates

will it really? do you have any metrics or research that backs that claim up?

I would have hoped that users would be more trusting of an installer from a vetted source like the app store than they would be of an unfamiliar file extension from an unknown website.

justinschuh15• 14 years ago

Chrome has supported inline extension installation for a few versions now: https://developers.google.com/chrome/web-store/docs/inline_i...

That should address any user confusion, while still hosting the extension in the WebStore. It also saves the hosting bandwidth and guarantees that your extension updates over a pinned SSL channel, which protects your users in case your key is ever compromised.

nimbupani3• 14 years ago

What are some of these Facebook "like" selling sites that allow installing extensions?

(merely curious, and completely off-topic)

duskwuff• 14 years ago

I think you've parsed that sentence incorrectly. The issue is that some sites are selling "likes" on Facebook -- e.g, you pay them $X and a site of your choice gets some large number of FB likes driven its way. The way many of these sites probably operate is presumably by way of a a bunch of Facebook users with malicious Chrome extensions.

smoyer2• 14 years ago

And I think the concern is that a closed ecosystem might gradually replace the open one that exists now. I don't have a philosophical problem with protecting users from themselves (or even being protected from myself).

y0ghur7_xxx• 14 years ago

> This is basically the same model that every Linux distro uses

If that were true, to install google chrome/earth or whatever on ubuntu I would have to

- get google apt repository

- add it to my list of sources

- import google repository key

- run apt-get update

- run apt-get install google earth

instead of simply doubleclicking on the the downloaded deb.

rogerbinns• 14 years ago

You do know that after installing the downloaded deb it adds the google apt repository to your sources and adds the key so that all future updates are done the apt way? (You can also edit files to prevent this behaviour.)

forgotusername• 14 years ago

AFAIK Firefox already has the ability to blacklist offline extensions.

nnethercote• 14 years ago

Mozilla does have an extension "blocklist", but it's used very infrequently, mostly for confirmed malware. It also distinguishes between "soft" blocks, which the user can re-enable, and "hard" blocks, which the user cannot.

rsanchez12• 14 years ago

The solution is to take the same method to detect malware in the store and add it to the browser, unless you guys won't support open source solutions because you think it will lead to more security.

FuzzyDunlop• 14 years ago

A good idea in theory, but if it gets tied to a 6 week release cycle it won't be as effective.

Also, I'd rather not have my browser slowed down at every startup because it has what is essentially a built in anti-virus.

justinschuh15• 14 years ago

I realize why this seems like a good solution at first glance, but it's actually very impractical. First off, much of the detection you want to do is computationally expensive and just can't be bundled into a standalone application shipped to end users. Consider simulated/sandboxed execution, which is great for identifying malicious code but typically requires a whole supporting environment to work.

Second, even when you can push some subset of detection to the client, the fact is that doing so undermines its own effectiveness. Malicious code detection is an arms race, and once the bad guy knows exactly how your detection works he'll alter his signature accordingly. So, by keeping the detection private you force the bad guy to come to you if he wants to test it. And he needs to keep resubmitting his code until it passes, which is in-and-of-itself a useful collection of data for malicious extension detection.

Finally, malicious code detection is often a rapid-response situation. You're constantly getting more data, and evolving and experimenting with different methods. So, you don't want to be bound to a multi-week release cycle, or risk destabilizing Chrome by forcing more frequent releases.

jasonlotito• 14 years ago

> So, the best solution is to disallow other sources by default

No, it's not. It's the best solution you can come up with at the time, and one that likely presents the least amount of effort. Doesn't mean it's not a piss-poor solution. It also doesn't mean it's not going to cause additional problems.

Now if we want to distribute a plugin, we effectively have to bow to the whim of Google. And when I read stories like this: http://news.ycombinator.com/item?id=4092080, I'm not comforted.

> I'm also surprised Firefox hasn't proposed something similar

Maybe because this isn't the only solution?

Let me put this in simple terms: this is the easy way out. The simple way out. This is the low hanging fruit. It's a solution that is, in effect, the worst possible solution. It's the lazy solution. If you can't admit to that much, you're blind.

Time to go donate again to Mozilla.

justinschuh15• 14 years ago

I'm sorry you're unhappy with the change. We spent quite a while considering this, and it's the best solution we could come up with for the safety of our users. As has already been mentioned, it's still very easy to install extensions. It's just a few extra steps per install, or some additional configuration by the user or administrator. However, we're always open to better proposals.

As for how the WebStore is handled, the story you linked to seems to show a positive resolution. The extension was improperly flagged, but the developer appealed and his extension was quickly re-listed.

nikcub• 14 years ago

I publish a number of Chrome extensions outside of the web store (thousands of users).

I avoid it intentionally. There is no reason why Google needs to know everybody running my extensions, and nor do I want or need Google sending me users.

The understanding was that Chrome extension development was an open environment. Hence why a lot of developers use Chrome and develop for it.

I don't see how this is different to users being able to click on an download and run an executable file. Add an additional security warning if you like, there are already two (as many as an executable) and they are pretty clear about what is taking place.

What you are proposing to do (or have already done) is a crap solution to a real problem.

The web store is no safer. I searched for 'youtube video downloader' the other day and the top result was malware. It had solid (turns out, fake) reviews and registered has having tens of thousands of users. I only found this out after installing it.

I see this as nothing more than a play to control the ecosystem surrounding Chrome. I completely regret investing so much time into developing Chrome extensions. Push issues like this one or two more times and you may lose more than the developer community.

justinschuh15• 14 years ago

As I've explained to others, this was a considered decision taken to protect our users. I don't claim that the WebStore is immune from malicious extensions, but all our data very clearly showed off-store extensions to be the major vector by a very large margin.

I don't think this marginal increase in friction for off-store installs is a bad compromise. However, if you have a better suggestion, I'd be happy to hear it. Also, I'd ask that you report the WebStore extension you believed to be malicious, in the interest of protecting other users.

petegrif2• 14 years ago

This is a BIG problem for my use case. Worrying.

I applaud the motivation but am very disturbed by the unilateral way this has been sprung on us.

campnic2• 14 years ago

I have spent a few minutes trying to think of an alternative to this. I understand that users getting tricked into installing malware is a big issue. I think we, as developers, are paying a bit of a price for the number of popups we used to put in front of people so they don't read or understand anything that is on them (see: EULAs). Could you maybe comment on other paths you considered when making this change?

Could there be a way to just have the signing cert for an extension be provided/known by google, even for third parties, so that if reports happen the extensions using that certificate could be remotely disabled? I'm seeing both sides of the argument, just seems like this issue goes even beyond extensions.

justinschuh15• 14 years ago

Extension packages are already signed, but we can't track the signatures outside the WebStore. You can prevent key churning by centrally tracking keys, but that generally devolves into the ActiveX Authenticode model. So, you've traded a basically free central distribution point for a high monetary cost to entry because that's a big part of how you penalize bad behavior.

As to what we've done previously, it's involved SafeBrowsing integration and blocking known malicious extensions. However, that approach has serious limitations: responses are an immediate oracle; preemptive manual intervention isn't practical; users are vulnerable to MitM and/or DoS; latency means you'll almost always have victims before your analysis completes; you may never see the full malicious extension files.

benmccann2• 14 years ago

I don't want my extension on the Chrome webstore discoverable by the whole world. Extra steps will lower my conversion rate tremendously given how non-technical my users are.

aboodman• 14 years ago

If the reason you don't want your extension discoverable is because its an internal extension for an enterprise, then you should be aware that you can add trusted sites via enterprise policy. So this won't be a problem for you.

marshray3• 14 years ago

Was there some new law of nature added in the last few years that says as soon as any app platform takes the lead its vendor must begin restricting the distribution channels available to 3rd party developers?

Wouldn't it be awesome if Microsoft and Apple forbade competing walled gardens (such as Chrome) from running apps on their operating systems?

georgemcbay• 14 years ago

"Wouldn't it be awesome if Microsoft and Apple forbade competing walled gardens (such as Chrome) from running apps on their operating systems?"

That's funny because both of them have already done that. Not on Windows, and MacOS, but on WinPhone7/Win8Metro and iOS.

justinschuh15• 14 years ago

What? The only thing changing here is a default configuration value that actually gives users and administrators more control. This isn't like iOS or Windows RT, where you have to download an exploit and void your warranty to install software from a third-party source.

marshray3• 14 years ago

Yes, it may be not evil like WindowsRT and iOS and it may improve the security of users. But it's another brick in the wall being erected between 3rd party developers and users.

2000 Microsoft: "Developers, developers, developers"

2012 Apple, Microsoft, Google: "Won't someone please think of the poor users' security! (and give us a NN% cut off the top while you're at it"

Kerrick7• 14 years ago

If I want to distribute an extension that users want but Google won't allow, such as a pornography browsing extension (disallowed by the CWS policies [1]), there's a HUGE change from an end user's viewpoint. I am FORCED to host it elsewhere.

Installing an extension from the CWS is as simple as clicking the CWS Install button and accepting the security/permissions warning. Currently, installing an extension from a third-party site is as simple as clicking the site's Install button and accepting the security and permissions warnings. To the end user, these are practically the same experience, and only one extension method must be learned.

After this change, the end user will have to learn that extensions are powered by files, that only .crx files are extensions, that a .crx file must be downloaded to install an extension (but only manually if the extension is hosted somewhere other than the CWS), and that they must drag-and-drop a previously downloaded .crx file to a Google Chrome or Chromium tab that has a specific settings page open.

This is confusing, and necessitates that a user learn two different workflows to accomplish the same task from different sources. This turns non-CWS extensions into second-class citizens, and it's not as simple as enabling inline installation [2] if your extension would go against Google's policies.

[1] https://developers.google.com/chrome/web-store/program_polic...

[2] https://developers.google.com/chrome/web-store/docs/inline_i...

protomyth4• 14 years ago

I would imagine that some of this is CEOs of companies getting tired of being dragged up to Capital Hill for a "hearing" every time some 3rd party developer does something bad[1] or the press mis-report the impact of some design decision[2]. A developer or IT friendly solution takes a lot of work, and with the size of the consumer market and number of lawyers getting hip to tech, I would imagine the full on lock down is the final goal. WinRT, OS X 10.8, and Chrome browsers / ChromeBooks.

1) Path

2) The iPhone's cell tower list http://www.mobiledia.com/news/88279.html

marshray3• 14 years ago

OK but now that they're reviewing and approving every app based on its behavior and content it seems like if anything that's going to put them on the hook far more. https://en.wikipedia.org/wiki/Common_carrier

slig2• 14 years ago

All the latest malware that I see spreading on facebook came from Chrome extensions. Users don't care, they click and install stuff. Then the extension, which can interact with any page, can spam walls and comments on facebook.

bob_kelso• 14 years ago

But what happens if someone complains about my extension and Google decides to pull it from the store?

Kerrick7• 14 years ago

It happened to me. I am the developer of a joke extension [1] that got reported for abuse one too many times, and Google took my developer account off the Web Store, then they sent me an email about it [2], stating that it was breaking a policy that it simply wasn't.

I replied to them explaining the situation [3], and they reinstated my developer account (and that extension) within 4 days [4]. Still, if they had "carefully reviewed" my case and decided against me, I may have had my primary source of income (developing Chrome extensions) taken away from me because of a joke extension.

[1] https://chrome.google.com/webstore/detail/gnbchcphjnmbmknnoe...

[2] https://gist.github.com/514ae4d858027303bc95#file_email.txt

[3] https://gist.github.com/514ae4d858027303bc95#file_reply.txt

[4] https://gist.github.com/514ae4d858027303bc95#file_response.t...

slig2• 14 years ago

it remembers be about the "I'm rich" iPhone app that was selling for 999 usd. I'm very curious to hear if any user has bought your app.

tuxidomasx• 14 years ago

I think restricting access in this way will slow the growth of browser extensions/addons as platforms for launching full-fledged web services and apps.

I see more and more web apps relying on extensions for a core part of their functionality, and this is only going to hurt them.

For installing non Web Store extensions, I would rather see an extra warning message or notification, rather than a protracted process that many users wont be able to figure out. Extensions are good, but not if they're hard to install.

rsanchez12• 14 years ago

Such a shame that this appstore mentality is becoming the norm.

Erunno• 14 years ago

Unfortunately Google's policy doesn't cause only malicious extensions to be removed from their web store. For instance, All Mangas Reader, a combined reader and management tool for online manga sites, was removed from the store for "copyright infringement", although it's the sites that are hosting the mangas doing the infringement and not the extension. Additionally, the copyright problem does not apply to all jurisdictions where the store is accessible. ChromedBird, a Twitter client extension, was also removed because Google didn't like that it contained the "chrome" string (at least this problem was easily alleviated by changing the name to SilverBird).

As long as it's still possible to install non-webstore extensions I'll learn to live with that restrictions as it's not an activity I perform often in the first place.

zobzu• 14 years ago

Yay, another "lets enforce our products to end users" on the cover of "security".

Can't wait for Google to remove the checkbox on every Android for "allow 3rd party software install", cause you know, it has to come from Google Play else it's OMG dangerous, and all the users are dumb and check the checkbox and install random apks. And look there's a nice illusion of choice, you need a procedure so complex that almost no one will be willing to do it (and thus you're forced into Google Play).

For security. /trustworthy.

drivebyacct2• 14 years ago

What? This is the same as the Android feature. External installs are blocked by default and the user can change that setting and acknowledge the security risk.

jimrandomh• 14 years ago

I publish an extension, Textcelerator (https://textcelerator.com) off-store. This is the first I'm hearing about this, and it would completely the sign-up flow for my extension. (My extension is in the Chrome store, but my landing page doesn't link there.)

Fortunately, it seems this only affects the head versions for now, not the version regular users get on a new install (I just tried it) or an autoupdate, so I have some time to switch links around and make it work. However, I really think there needs to be some sort of deprecation before this is rolled out, probably in the form of a warning on download if Developer mode is enabled, backported to versions 19 and 20.

BrianEatWorld3• 14 years ago

Its mentioned further down in the comments, but if youre on the Chrome Store already, you can use Inline Installation. This allows you to use roughly the same flow you use now.

https://developers.google.com/chrome/web-store/docs/inline_i...

BrianEatWorld3• 14 years ago

I have an extension on the Chrome Store, but I also distribute it via bundling and bundling requires an executable. For the bundle, I use the registry method found here: http://code.google.com/chrome/extensions/external_extensions...

Will this method still work?

I originally had the exe simply open a window to our Chrome store listing, but the friction was ridiculous. We would get about 5 installs for roughly every 100 we were paying for.

Chrome limits off-store extension installs

Related Stories