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.

We can discuss this during the work week.

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.

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

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