
Chrome limits off-store extension installs - Osmose
https://code.google.com/p/chromium/issues/detail?id=128748
======
justinschuh
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.

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

~~~
justinschuh
Chrome has supported inline extension installation for a few versions now:
[https://developers.google.com/chrome/web-
store/docs/inline_i...](https://developers.google.com/chrome/web-
store/docs/inline_installation)

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.

~~~
dzohrob
Thank you, I hadn't come across this yet. This should mitigate the changes to
the user flow.

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

~~~
justinschuh
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
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?

~~~
justinschuh
This change adds a few extra steps for an off-store install, unless the user
or administrator configures things otherwise. That's it; updates and existing
installations aren't affected at all. The details are very clear if you read
the discussion or a few of the comments in the bug.

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

~~~
tiziano88
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?

~~~
Kerrick
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?

~~~
tiziano88
I was specifically asking about jonknee's use case, I never claimed that this
would be an ideal solution for every other possible scenario. That said, your
request to have a mouse-free way to install extensions is totally sensible,
and I would be surprised and disappointed if they did not think of alternate
ways to do that (perhaps using the command-line).

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

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

------
marshray
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?

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

~~~
Kerrick
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...](https://developers.google.com/chrome/web-
store/program_policies)

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

~~~
BrianEatWorld
I don't know that drag and drop will work either. I am working in Canary right
now and the drag and drop raises the exact same denial message as the off site
install.

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

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

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

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

~~~
BrianEatWorld
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...](https://developers.google.com/chrome/web-
store/docs/inline_installation)

------
BrianEatWorld
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...](http://code.google.com/chrome/extensions/external_extensions.html)

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.

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

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

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

~~~
Kerrick
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...](https://chrome.google.com/webstore/detail/gnbchcphjnmbmknnoefjdfiginagghbk)

[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...](https://gist.github.com/514ae4d858027303bc95#file_response.txt)

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

~~~
Kerrick
No, nobody has purchased that app. A few people have purchased a $5 recipe app
that I made, but nobody has purchased the $999 joke app. If they did, I'd feel
really bad and offer them a refund.

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

