722232 - Document loaded in the browser from `data` addon's folder should have more privileges

Status: RESOLVED INCOMPLETE

(Add-on SDK Graveyard :: General, defect, P2)

Description

[Matteo Ferretti [:zer0] [:matteo]]

Due to a change of principal In Add-on SDK 1.4, content scripts and HTML page in `data` folder have exactly the same privileges of a remote web page.

That's not most of the developers expects from a Firefox's add-on. We should give to this document (at least, to the HTML page loaded from `data` folder) a bit more privileges. They should be able to overcome the Same Origin Policy in order to do Cross Domain Request, for example, or using `toDataURL` method of canvas (that otherwise it fails).

Not sure if we want to fix the issue about dynamic XBL binding as well (see https://bugzilla.mozilla.org/show_bug.cgi?id=717937), that is related to the same issue but especially in content scripts could maybe bring some security concerns.

Comment 1

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

We can discuss this during the work week.

Comment 2

[Alexandre Poirot [:ochameau]]

We should split issues in two very different cases:
1/ restrictions of content script that fires against web page, with "web/content" priviledges,
2/ priviledges of documents loaded from data/ (Panel, Page-worker, Widget) that should not involve any content script, as we now inject `addon` in its global scope. (We still support content script for those documents, but only for compatibility)

The bug title explicitly describe 2/, that is really different from 1/.
But the description given in first comment is not explicit.
I'm assuming this bug being about 2/. (We should open another one for 1/)

2/ ends up being way simplier to address as there is way less security concerns about it. In this particular case, there is no remote-hazardous-non-reviewed code involved. So that we can assume that code comming from data/ folder is reviewed and we do not have to be very carefull about any arbitrary remote piece of code.

Having said that, it may still require some platform tweaks. If we are lucky, we may be able to use protocol flags to address some of these security exceptions:
http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsIProtocolHandler.idl#157

There may be two steps:
- ensure that web features (canvas, xbl, xhr, ...) works with documents coming from data folder (it may be already broken because of resource: protocol)
- allow doing cross domain operations


FTR, here is some examples of platform code that block cross domain features:
# Canvas
http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/nsHTMLCanvasElement.cpp#209
-->
http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsContentUtils.cpp#1196
# XHR
http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsXMLHttpRequest.cpp#1598

Currently all these security check are made in a black or white mode:
 - system principal or "UniversalXPConnect" -> can do everything
 - otherwise -> nothing

We may prefer having a third option, where we add some options in compartment/principal/something, in order to specify a precise set of priviledges we would like to give.

Comment 3

[Dave Townsend [:mossop]]

Alex, can you split this out into the bugs you think would be appropriate then we can triage them next week.

Comment 4

[Alexandre Poirot [:ochameau]]

Done. This bug is now splited in itself (everything but content scripts) and bug 734891 (only about content scripts).

Comment 5

[Firefox Bug Husbandry Bot]

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