janekptacijarabaci Reporter
	Description • 11 years ago

User Agent: Opera/9.80 (Windows NT 6.1; WOW64) Presto/2.12.388 Version/12.16

Steps to reproduce:

http://scriptish.org/2011/09/02/how-to-detect-greasemonkey.html



Actual results:

Option 1 - Correction: https://bugzilla.mozilla.org/show_bug.cgi?id=790732

But:
Option 2 - Works



Expected results:

Correction:
https://bugzilla.mozilla.org/show_bug.cgi?id=292789

But:
https://bugzilla.mozilla.org/show_bug.cgi?id=292789#c1
https://bugzilla.mozilla.org/show_bug.cgi?id=292789#c110
http://hg.mozilla.org/mozilla-central/file/3d20597e0a07/caps/src/nsScriptSecurityManager.cpp#l1408

Or more:
https://bugzilla.mozilla.org/show_bug.cgi?id=773886

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 11 years ago

When we locked down access to chrome:// URIs based on the registry, we left resource:// open for things flagges as ALLOW_CHROME (e.g. scripts).

Is there a reason to allow this nowadays?

	Daniel Veditz [:dveditz]
	Comment 2 • 11 years ago

This issue is not limited to <SCRIPT> tags -- if you're worried about fingerprintability then exposing a custom URL anywhere is a problem. This was true back in bug 292789 as well, the bug summary says SCRIPT but the fix applied to content in general.

We allowed accessibility for resource:/// which pointed at the installed on-disk resources that came with Firefox. I don't know if we supported alternate resource aliases at the time, but I'm sure add-ons weren't using them and that we didn't support resource aliasing in chrome.manifest (which didn't exist).

When we introduced resource into chrome.manifest we should have added the option contentaccessible=yes mechanism at the same time: let add-ons opt-in to fingerprintability just as we do with chrome content. Unfortunately anything we do may have compatibility problems: searching addon source I find 810 chrome.manifest files that define custom resource:// locations. One reason for so many is because it's used by JetPack addons so I'm somewhat hopeful that most of those don't need to reference these from content.

Alternatives that come to mind:
a) hide resource://foo/ unless chrome.manifest has contentaccessible=yes
b) hide resource://foo/ if chrome.manifest says contentaccessible=no
c) only expose resource://foo/ if the chrome.manifest has put contentaccessible=yes
   on the corresponding "content foo" line.

Between the first two a) is both safer and consistent with chrome handling but more likely to break some addons. b) won't cause any breakage (because addon authors can fix it when they opt-in) but in practice isn't going to protect many addons from fingerprintability. Both may cause backwards compatibility problems for authors who need their addons to work in both old and new versions of Firefox. We'll have to investigate what the chrome.manifest parser does with unexpected tokens on the end of a resource line.

c) is a bit random. Inspired by the fact that visibility of skin and locales files are all controlled by the content definition, this would avoid the backwards compatibility trap if the old parser will choke on a new term (not yet determined). In practice, though, some add-ons don't use the same name for their resource: and content, and some addons have multiple resource definitions. It's likely to have the same compatibility issues as a). Most /do/ use the same name for resource and content so it might require more authors to change their chrome.manifest to opt-out of visibility -- somewhere between a) and b).

I think Benjamin owns the chrome.manifest mechanism: any thoughts?

	Benjamin Smedberg
	Comment 3 • 11 years ago

Do we know why greasemonkey is using resource: ? I don't know whether web content needs access to resource: at all nowadays, but I know I'd prefer greasemonkey to just stop doing this rather than introducing extra complexity to this handler.

We could also just try making resource: not web-accessible and see what breaks.

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 11 years ago

Our built-in image/plugin document styling uses resource://

I assume we'd whitelist resource://gre/ or something?

	Benjamin Smedberg
	Comment 5 • 11 years ago

The only reason extensions would need to use resource: is to make things available to web content. I think this should be WONTFIX unless there's some other property of resource: that an extension really needs.

	Dave Garrett
	Comment 6 • 10 years ago

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #5)
> The only reason extensions would need to use resource: is to make things
> available to web content.

To use JSM in Firefox 3.x you had to load from a resource:// URI. This hasn't been the case in a long while, but people learned this to be the case. (see bug 675372 comment 9 and later) Some addon authors haven't necessarily had a good reason to switch to chrome:// URIs. You'll need to for restartless addons, but I suspect many old addons still use resource://.

	TomRitterOther (don't use this account, use :tjr)
	Comment 7 • 10 years ago

I'm trying to enumerate mechanisms to protect against this today, before it's fixed in FF proper. I don't have too much right now.  Some thoughts I haven't tested include:

1) Trying to unregister any default fingerprintable URL with setSubstitution, and registering a whole new one using a random ID
2) Migrating everything over to chrome:// with contentaccessible=no (but this probably won't work in some  use cases.)

Are there other ideas or techniques people could try and use today?

	Dave Garrett
	Comment 8 • 10 years ago

(In reply to Tom Ritter from comment #7)
> 2) Migrating everything over to chrome:// with contentaccessible=no

All chrome:// URIs are contentaccessible=no; you don't need to specify that.

	janekptacijarabaci Reporter
	Comment 9 • 9 years ago

Steps to reproduce:
http://scriptish.org/2011/09/02/how-to-detect-greasemonkey.html
(url is unavailable)

The appropriate code is:

<script type="text/javascript" src="resource://greasemonkey/addons4.js"></script>
<script type="text/javascript">
if (typeof GM_addonsStartup !== "undefined") {
  alert("I smell a monkey!");
}
</script>

	Patrick McManus [:mcmanus]
	Comment 11 • 8 years ago

is this a dup of bug 863246 ?

	bugzilla-ng
	Comment 12 • 8 years ago

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #5)
> The only reason extensions would need to use resource: is to make things
> available to web content. I think this should be WONTFIX unless there's some
> other property of resource: that an extension really needs.

They are extensively used as a less privileged alternative to chrome:// URIs especially in SDK-based add-ons. I think we should only expose them to add-ons (including unprivileged resource:// pages or WebExtensions). With web_accessible_resources (https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/web_accessible_resources) in WebExtensions, we should stop exposing arbitrary resources to content. Since the moz-extension: protocol is randomized, it is less harmful to privacy.

In short: Add-ons need resource: URIs. Not Web sites. For add-ons that need to expose resources to content, there is web_accessible_resources from WebExtensions.

Core packages like resource:/// or resource://gre/ should only be available to add-ons, just like the Components global.

	bugzilla-ng
	Comment 13 • 8 years ago

Why expose JSMs and default preferences to content? (Not an obvious security issue, but bad for privacy)

	Daniel Veditz [:dveditz]
	Comment 14 • 8 years ago

(In reply to bugzilla-ng from comment #13)
> Why expose JSMs and default preferences to content? (Not an obvious security
> issue, but bad for privacy)

See comment 4. Could be fixed by segregating the required resources into their own namespace (resource://gre-public/ ?) and hiding all the others.

	Tom S [:evilpie]
	Comment 15 • 7 years ago

This whole problem is going away with WebExtensions anyway.

	Ethan Tseng [:ethan]
	Comment 16 • 7 years ago

(In reply to Limited Availabilty till Oct | Tom Schuster [:evilpie] from comment #15)
> This whole problem is going away with WebExtensions anyway.

Yes, WebExtensions are not able to use resource:// URI.
Meanwhile, bug 863246 is landing and it would fix the issues described in this bug.