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:
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.
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.
> 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.