The HTML <script> element does not do any URL checks before loading a script. This results in regular web pages (from http://) being able to successfully load scripts from chrome://. The chrome scripts lose their privileges, of course, but it is a simple matter of |"functionname" in window| to detect whether the script was available and loaded. Worse, |var source = "" + functionname;| returns the implementation of a function, which enables the web page to do a more fine-grained distinction across application or extension versions. This is probably not a security bug in itself, but I'd classify it as an unwanted information leak that makes targeting exploits easier. When a security hole is discovered in an extension, it is easy for the attacker to only activate the exploit on systems where the extension is installed. Other potential uses are keeping out "unwanted" AdBlock or GreaseMonkey users from web sites - sure, they can disable JavaScript for web pages, but to enjoy the web most users won't do that, and "crossing" the web<>chrome barrier in this way shouldn't be possible from the start. Testcase coming up.

Simple demonstration page detecting the presence of GreaseMonkey, IE View, FlashGot and Mouse Gestures.

for extensions that ship their own interfaces, webpages can also check for if ("nsIFoo" in Components.interfaces) to detect them...

<script> must be doing some kind of CheckLoadURI, because a src attribute with a file: URL is blocked. (That's a good thing, because otherwise it would be possible to read someone's prefs file if you knew its location.) Why aren't src attributes with chrome: URLs blocked?

*** This bug has been marked as a duplicate of 292789 ***

Since this was duped against a public bug, please remove the security flag.

(In reply to comment #3) > <script> must be doing some kind of CheckLoadURI[....] Why aren't src > attributes with chrome: URLs blocked? Because Vidur told it not to, apparently http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/base/src/nsScriptLoader.cpp&mark=517-518#510 Easy enough to fix, wonder who we'd break?

Remote XUL, apparently, see bug 292789.