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

Issue 33505 link

Starred by 21 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 2010
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

issue 89590

  • Only users with Commit permission may comment.

Sign in to add a comment

Content script injection not working on Extensions gallery

Reported by, Jan 29 2010

Issue description

Chrome Version       : 4.0.302.3 (Official Build 36935) beta
URLs (if applicable) :
Other browsers tested: N/A

What steps will reproduce the problem?
1. Install the attached test extension.
2. Verify that a message popup triggers on a https page such as
3. Visit and observe that the script 
does not trigger.

What is the expected result?
A message box showing that the script triggered.

What happens instead?
Nothing at all.
690 bytes Download

Comment 1 by *, Jan 29 2010

Labels: -Area-Undefined Area-Compat-System
Status: Untriaged
Labels: -Area-Compat-System Feature-Extensions
Status: Available
This is as-designed (as a way to prevent privilege escalation).  However, it's 
something that we're considering changing (we have another approach in mind to prevent 
escalation), so for now I'll leave this bug open.
Labels: Area-Feature
 Issue 33849  has been merged into this issue.
Labels: -Area-Feature Area-UI

Comment 6 by, Feb 20 2010

Please change this behavior. For the Google Dictionary extension, I've seen lots of 
users comment that the extension is broken b/c they naturally try it first on the 
gallery page from which they just installed it.
We're debating this now.  FYI, for this to fix your particular use case, we would also 
need to fix issue 36400.
 Issue 55086  has been merged into this issue.
 Issue 55086  has some suggestions about a way this could work.
Status: WontFix
Unfortunately, I don't think it's practical for us to support this.
Not addressing this bug has pretty severe consequences for extensions that aim to improve accessibility. Users who depend on accessibility extensions to navigate the web will not be able to use the extensions gallery.
Yes.  Third-party accessibility extensions have the same issue with chrome:// pages as well (which we're also not going to open up to content scripts).  Accessibility will need to be addressed with either built-in functionality or special purpose APIs.

What are the specific security considerations here? Can you describe the privilege escalation scenario?

Also, what is the specific URL exclude pattern at work here? The reason I ask is because myself and others who intend to write security enhancing extensions will need to either display a dialog warning the user when they try to visit such urls, or block their navigation entirely. Especially if these exclude patterns include http urls that can be used by a malicious network adversary to inject plugins and other exploits via redirection and MITM.

See also:

Comment 14 by, Sep 14 2010

Mike: The gallery provides a lower-friction install experience than normal web pages because it is trusted. We don't want to run content scripts on it because they could abuse this to auto-install more extensions, thereby increasing their privilege.

Right now, when installing an extension off the gallery, there is a single modal dialog that pops up that users accept. There are known issues with single prompts like this, where they can be attacked by tricking users into double-clicking.

In the future, we actually plan to take it further and have no modal dialog at all. You simply click install on the gallery and you get the extension. This would be even easier to exploit.

The gallery URL is always https. It is configurable (for testing), but is usually will also be used in the future.
aa: Technically the gallery URL is not always https. If the user just types just "" in their url bar, they hit http, which gives a 302 to https.

So it is very important that the content script exemption is only for https. If the http url ever doesn't actually give a 302 because of an MITM, that is a security issue for any extension trying to do things like disabling plugins, fingerprint protection, request filtering, etc, because the MITM could serve anything over that http url instead of the 302.

For our uses with Tor, we require an even higher standard and aren't comfortable having any blanket exemptions to our protections.. We don't strictly require the ability to inject into holy and sacred urls such as this, but we do require one of either the ability to inject into them, or the ability to warn a user before loading any content from them, even over SSL.

So we would need either a special "gallery-inject" permission (that perhaps excludes us from ever hosting in the gallery), or we would need Web Request to give us at least the ability to cancel such a page load (and display a modal dialog/alternate page).

Comment 16 by, Sep 15 2010

Mike: We have plans for WebRequest to be able to cancel/modify requests. Your brother Matt is actually the one working on that :).

I'm personally really excited about the kinds of things people can build when they can cancel/modify requests. Extensions such as the EFF's https-everywhere become much easier.
Ok, cool. So long as there is some way we can handle these special urls with Web Request so that we can ensure that users don't unknowingly (get forced to) navigate to them, that should be an acceptable solution. I just want to make sure they also aren't exempt from these urls. It would seem to me that the ability to get Web Request notification for these special urls should also give accessibility extensions a chance to inform their users that they are non-functional, too.

Btw, I'm actually co-author on HTTPS-Everywhere. It is one of the security-enhancing extensions I hope to port/write for Chrome :)

I've been doing a fair amount of work as part of my job at the Tor Project to track all these APIs to ensure that there is some acceptable subset that allows developers to write these types of security-enhancing extensions, and still be able to give security guarantees about their behavior:

Comment 18 by, Nov 11 2010

1, I'd rather click "OK" twice to install an extension than to be forbidden using extensions on gallery pages. Some extensions, such as mouse gestures, are so useful that their absence makes browsing the gallery very cumbersome.

2, Why not grade the APIs: Some APIs are potentially dangerous, don't let them run on gallery pages. Some APIs are harmless, let them run. 

Comment 19 by, Jul 18 2011

Blocking: 89590

Comment 20 by, Jun 21 2012

Blocking: -89590 chromium:89590 chromium:89590
Project Member

Comment 21 by, Oct 13 2012

Blocking: -chromium:89590
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 22 by, Mar 11 2013

Labels: -Feature-Extensions -Area-UI Cr-Platform-Extensions Cr-UI

Sign in to add a comment