New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 128748 link

Starred by 107 users

Issue metadata

Status: WontFix
User never visited
Closed: May 2012
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression

  • Only users with EditIssue permission may comment.

Sign in to add a comment

[Regression] Unable to install extensions by running .crx file downloaded in Chrome

Reported by, May 18 2012

Issue description

Chrome Version       : 21.0.1141.0 (Official Build 137831) m
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
Firefox 4.x:
IE 7/8/9:

What steps will reproduce the problem?
1. Drag and drop a .crx file into Chrome
(You can open in a different window or browser and try bgapp.crx, https-e.crx)

2. Click on the downloaded .crx file to run it

What is the expected result?
Chrome installs the extension

What happens instead?
System dialog says "Windows can't open this file"

Please provide any additional information below. Attach a screenshot if
13.8 KB View Download
Labels: Feature-Extensions Area-UI Mstone-21
Possibly related to issue 120604 (but I can't see that one to confirm)
You are probably looking for a change made after 137689 (known good), but no lat
er than 137702 (first known bad).

Comment 4 by, May 18 2012

Status: Assigned
looks like it's

Comment 5 by, May 18 2012

pls either revert or let us know if this is working as intended.

Comment 6 by, May 18 2012

Status: WontFix
i'm told this works as intended.
Reproducible in 21.0.1148.0 (Official Build 138407)

Comment 8 by, May 23 2012

You are no longer supposed to be able to install extensions off-store in Chrome. See  bug 55584  for details.

In order to install off-store extensions, the user must download them to a directory and drag them onto chrome://extensions/.

I intend to polish this UI a bit to hide the download bar so that people don't click on it. I'd also like to add some UI that tells users that extension install is disabled off store or something, but we still haven't figured out what that will look like.

Comment 9 by, May 23 2012

 Issue 129330  has been merged into this issue.
I feel this change was made without much consultation with users or extension developers. This behaviour should be opt-in for for enterprises and users who desire it; rather than making non-Web Store extensions second class citizens.

There's already double-confirmation for off-store installs (once in the download bar at the bottom, and again in the install extension sheet).
Re: c#10

Unfortunately, end users simply "click-through" even double confirmations, leading to problems with malware.

Comment 12 by, May 24 2012

I'm sorry, but I don't understand how this could lead to more safety.
Assuming the UI will be better than now, telling you how you can actually install extensions and userscripts (as right now you don't get any UI), I guess the people who now click through the warnings will just as easily open the folder they saved the file in and drag it onto the extensions page. If some user thinks (s)he really want the extension, they'll install it anyway, no matter how. The only difference is that they now get a bit more annoyed during install because they will wonder why the browser isn't able to do it itself, making wasting their time.

In my opinion, blocking extensions/user scripts has similar effect as when you would block all executable files and compressed files, because they *may* contain viruses, allowing people to only download them by dragging the URL to chrome://downloads/.
Most people will just do all the steps required, just as they, according to you, click through all conformation warnings. The people who do not do this, will stick with old versions of user scripts, as installing the new version will be too difficult. And old versions could also mean that any incorrect behavior (read also: introduced security issues) (especially when it modifies the page) will also stay installed and executed.

Last but (although not security related) not least, it'd be an unfair advantage for extensions stored in the store. Websites won't be able to allow people to install extensions from their own site without going through many more steps. No, instead they have to redirect them to a third-party site.
And AFAIK, user scripts can't even be installed via the store, although I didn't check this.
c#12 says it very well.

It's also worth noting that there are *many* websites that direct users to install their self-hosted extensions and will go some time before they learn of the new installation process (if at all) and provide messaging to their users. This hurts both the user and the developer.

You can bet, however, the malware authors will be right on top of this. Requiring dragging and dropping will only stop the most computer illiterate of Chrome users from completing the installation process.
Expanding on my comments that there seems to have been inadequate consultation with [Chrome and extension] developers, it's worth noting that this bug was actually filed by a Chromium team member, who thought they had encountered a regression.

Comment 15 by, May 24 2012

First of all, we understand that this will be frustrating to extension developers, and our decision wasn't made lightly. We went to a lot of effort in the design of the extension system to make it possible for people to self-host. All of the formats and protocols involved in the extension system were made simple with the idea that developers could re-implement them. It makes us sad to take off-store install away.

That said: the overwhelming majority of malicious extension reports that we receive today are from off-store extensions. In the store, we have a lot more control over bad extensions: there's a (modest) fee to get a developer account, which means there needs to be a credit card involved. And if a developer is bad, we can blacklist the account and credit card. Checkout and Google account creation are monitored for abuse in their own right, and we benefit from that, too. We also analyze the source code to extensions and can detect certain malicious patterns. Of course we can't detect everything, but this can improve over time.

As to the specific issues that have been raised:

- By 'improve the UI', I only mean to make the error more obvious. Unfortunately, as you point out, we can't make it easier to install off-store extensions - that is the whole point. But we can let the user know that the installation was purposefully rejected, e.g., by showing an alert:

- Our hope and belief is that this installation mechanism will be sufficiently complex that it will reduce the number of off-store extension installs performed. But we can measure this to be sure. If it doesn't help, we'll try something else.

- Our assumption in general is that people do not update their software; that's why we built in silent autoupdate. What makes you think that user script users are different in this regard?

- I overlooked user scripts in my initial implementation, so thanks for reporting that. I have a review out to fix it:

- Unfortunately, given the scale of the Chrome team, developer, and user base, it simply isn't practical to consult with everyone who might be affected by a change. That is why we have the various pre-release channels, so that we can get early feedback, and iterate.

Comment 16 by, May 24 2012

Oh, one final thing I wanted to add: We can relax this over time for extensions that use less dangerous patterns. For example, we could conceivably allow off-store install for extensions that don't have host permissions, or include native code. Currently there are not a ton of interesting extensions that don't have host permissions, so this would be somewhat pointless. But we are working on several new APIs that we hope will reduce the need for host permissions, and once those are in place, we could allow those type of extensions to be installed off-store.

Comment 17 by, May 24 2012

>What makes you think that user script users are different in this regard?
Well, to give the example that made me discover this behavior in Chrome is the userscript downloadable from for 'www.the-west.[nl|de|...]'. This userscript alerts every time an update is available: 'for userscript The West - Cloth Calc is a new version available, please click ok to update the Userscript'. (Of course, clicking OK is broken now).
Although I'm not very familiar with userscripts, I believe (especially as there are several tutorials, like , telling you how to implement it manually), that userscripts have no automatic-updates property like the extension manifest has (the "update_url": "{{url}}" key). Therefore it's more likely they have custom update functionality, but this custom functionality all relies on the functionality that is now broken. Especially because userscripts can't update silently, they'll alert users to do it. This is the reason I think userscript users are different in this regard.

>- By 'improve the UI', I only mean to make the error more obvious. Unfortunately, as you point out, we can't make it easier to install off-store extensions - that is the whole point. But we can let the user know that the installation was purposefully rejected, e.g., by showing an alert:
Do I understand this correctly (as your changeset isn't in trunk yet)? [if I'd first tell you I have %temp% as default download directory and use 'ask where to save before downloading'], the following will happen:
1. I try to install userscript / extension X from their own web site.
2. I'll only see a warning "Extensions, apps, and user scripts cannot be installed from this web site". The download bar will be empty and chrome://downloads/ doesn't show it either
3. I have to figure out myself 
   - where the downloaded file is stored (as I would not necessarily expect it in my default download folder as I /1/ didn't choose any location and /2/ don't see anything in the downloads bar/page
   - how to actually install it
   Although I'm probably way more experienced with extensions than most end users, I wouldn't figure this out myself. End users would totally be surprised why they can't use their favorite userscript from FireFox in Chrome, or that the extension that their favorite news website offers can't be installed. With the current information, you would certainly decrease the install of user scripts and off-store extensions. Probably both by 100.00% (thereby theoretically killing full user script support in Chrome, because the webstore doesn't contain them and installing is impossible), because the amount of users that knows how to install this is close to zero.

>- I overlooked user scripts in my initial implementation, so thanks for reporting that. I have a review out to fix it:
 Issue 129150 , last comment ATM. I filed it when I first noticed this behavior (as a regression) and it's even marked as a releaseblocker (AKA very bad bug) by a Chrome dev. (I know I'm repeating c#14 now)

>We can relax this over time for extensions that use less dangerous patterns. For example, we could conceivably allow off-store install for extensions that don't have host permissions, or include native code. [...] But we are working on several new APIs that we hope will reduce the need for host permissions, and once those are in place, we could allow those type of extensions to be installed off-store.
I can totally understand blocking off store native code installs, due to it's power. However, host permissions are used by every userscript (I can't think of an example that wouldn't need it) and honestly, except for keybinding and, depending on the final implementation, infobars, I don't see any current experimental APIs that could decrease the need for host permissions for normal extensions. And for many purposes, the targeting sites must be accessible to extensions (. Also, sites that want to have their own extension for their own website and prefer to host it natively are unlikely to be independent of access to their website. (Or you should for example have to whitelist off store installs for access to the site you used to install it, although that can be worked around easily).

Although I understand that you want to prevent malicious extensions/userscripts being installed, I think the current behavior might be a bit too much of it. As said, not a single userscript can be installed anymore [+the other arguments].
If you want people to read and consider the dangers, wouldn't it help to do a way more friendly behavior, like for example the firefox behavior:?
if you install an extension, during the permission warnings dialog, do not allow installs for, say, 5-10 seconds (do show a timer of course). If people have to wait (especially if the alert is blocking tab navigation) they're much more likely to read the warnings. (Eventually you could add something additional for non-store installs like "Warning: this extension doesn't originate from a monitored source and may behave badly")?
That way the user can control themselves what they want to install, while still being sure of pointing them to the dangers. The dangers of downloading an executable are still way bigger than downloading any off-store extension. Executables however are still downloadable without additional pre-download steps. ([offtopic]And luckily we're not yet in the 'Everything must be in the cloud' time, neither can Chrome block .exe files due to some legal issues if you'd do that; people couldn't download other browsers for example; as well as other problems that would be caused by that, for example the updating-old-software issues[/offtopic])

Comment 18 by, May 25 2012

As an end user, it appears to me that this proposed change is without merit.

But, I am unclear on one point.  Is it your intention to not allow userscripts at all, or just make the install process more difficult?
We can make it more simple if developer mode switched on.

As a developer, I wanna a more convenient environment for local developing. I understand your concerns and agree that users are easy to be directed as c#11 and c#15 said. Malicious websites may guide users to turn on developer mode, but we can make it slightly difficult to do so, just by authorising developer account before user trying to turn it on, or something around that.

BTW, for my chrome 21.0.1145.0 dev and 21.0.1148.0 canary (Max OS X 10.7.4), I still can't install user scripts even by dragging the .user.js to chrome://chrome/extensions/  ( c#8 )

Comment 20 by, May 26 2012

Userscript installs are re-enabled in version "21.0.1151.1 (Official Build 139074) canary"

Comment 21 by, May 26 2012

They are *temporary* re-enabled, according to
 Issue 129919  has been merged into this issue.
Did the policy get changed again? I cannot install off-store extensions even by dragging them to chrome://extensions/ . Is this only disabled for "less secure" scripts or disabled altogether?

Comment 24 Deleted

Seems like you again can't install them in 21.0.1155.2 even by dragging them onto chrome://extensions/

When dragging it onto that page, it attempts to begin "downloading" it and creates a .crdownload file in your download directory, but never actually installs, and upon closing the browser you are told that there are unfinished downloads remaining, but they are not shown on the download page.
There will be a way to whitelist specific websites, and an option to allow extension/userscripts installation globally, right?
Something around the idea of "Installing an extension from this website is extremely dangerous etc, wanna whitelist it?".

We already manage pop-ups, cookies and more that way, everyone's happy with that.

Installing from files needs to be allowed by default, I can't develop in this environment sanely anymore.

Comment 27 by, Jun 6 2012

As of June 5 (;a=commit;h=8db1c8822a50dc31e8b0889acb499c51a513a1e6), Chrome once again only allows off-store installs by dragging them on to chrome://extensions/.

The behavior described in #23 and #25 is surprising. I wouldn't have expected any change in those revisions. Perhaps a separate bug was introduced temporarily. I'll verify when I get into work that everything on trunk is as expected.

Comment 28 by, Jun 10 2012

So Chrome, too, builds a walled garden? How does this fit into Google's values, or the Chrome team's? Is your responsibility to making sure no user of Chrome can possibly experience malware, or is it to keep the web open to anyone to shape? There was a time where Chrome felt like it clearly prioritized the latter, and making the web faster and simpler to anyone who wanted to shape it.

Comment 29 by, Jun 10 2012

Altogether the above confirms my current position of sticking to Firefox for my primary development browser and letting things degrade from there.

Comment 30 by, Jun 10 2012

Perhaps it's time to fork Chromium.

Comment 31 by Deleted ...@, Jun 10 2012

Without the extension which I know to be safe and have used for over a year,I am now not allowed to DL, I am screwed and cannot progress in my game.  I am forced to use FireFox.

Folks, relax.  This doesn't stop you from downloading and installing extensions from other locations.  It just makes you go through extra steps, turning it into a feature for more advanced users.

Labels: Restrict-AddIssueComment-Commit
This change was made to protect users. Off-store extensions have become a popular attack vector for compromising users of larger sites (e.g. Facebook). Since the trend is only getting worse, we're putting the power back in the user's hands by allowing them to control where extensions are installed from. By default, the Chrome Webstore is the only source, but users and administrators will be able to add other safe sources as they see fit.

I'm closing the comments since this isn't a discussion forum (and it's been posted to HN). Please start a thread on the chromium-discuss mailing list if you want to express your concerns.
 Issue 129870  has been merged into this issue.

Comment 35 by, Jun 29 2012

 Issue 134981  has been merged into this issue.
 Issue 135324  has been merged into this issue.
Project Member

Comment 37 by, Mar 9 2013

Labels: -Type-Regression -Area-Internals -Feature-Extensions -Area-UI -Mstone-21 Type-Bug-Regression Cr-Platform-Extensions Cr-UI M-21 Cr-Internals
Project Member

Comment 38 by, Mar 14 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment