As reported by Jorge, some hackers exposed ways to detect which addons are installed by loading resource:// URIs. And as all jetpack addons use these URIs it make them a bit more unsafe. We should use another protocol which would prevent that by disallowing loading it from content.

We already discussed about new protocol specific to addon content in bug 644595, as part of Addon Page API.

Blackhat hack description: https://media.blackhat.com/bh-us-12/Briefings/Fleischer/BH_US_12_Fleischer_Implementing_Web_Tracking_gfleischer_WP.pdf

Do we have any more details on how he detected add-ons in this way? The paper is pretty short on details and I want to test if the fix I have solves it or not.

Nevermind, I found something that works. I recommend we don't land this before implementing bug 820213 for people who actually want to inject content into content

We could use an approach that I used in Scriptish to block requests to an add-on's resource: uri if the request comes from page that is not a chrome or resource uri. https://github.com/scriptish/scriptish/blob/master/extension/components/scriptish.js#L192-L198 I think we could even block requests to the internal directories via its resource: uri from outside the add-on.

I have an example of the issue on https://github.com/scriptish/scriptish/wiki/FAQ:-What-are-the-security-benefits-over-Greasemonkey%3F in the 'Stealth' section.

(In reply to Erik Vold [:erikvold] [:ztatic] from comment #5) > We could use an approach that I used in Scriptish to block requests to an > add-on's resource: uri if the request comes from page that is not a chrome > or resource uri. > > https://github.com/scriptish/scriptish/blob/master/extension/components/ > scriptish.js#L192-L198 > > I think we could even block requests to the internal directories via its > resource: uri from outside the add-on. It's a solution, but it adds a lot of work (every add-on with its own content policy for every url access from every page!) that can be avoided with a custom protocol. I should have a proof of concept up in the next few days.

I feel like this is a dupe of another bug, but I think Dan would know for sure.

I suppose we can call this done? Comment 0 is about add-ons. Legacy addons are gone and Web Extensions use moz-extension; comment 0 seems to be satisfied. resource:// still exists for internal Firefox resources (including system addons which might be hybrid/legacy ones) but bug 863246 made that better by requiring resources to be exposed intentionally.