Various folks at various times have discussed whether or not content scripts should have access to style info that is normally chrome-privileged (f.e. the rules in stylesheets loaded from a different domain than the domain from which the page was loaded). After discussion and deliberation, I've come to the conclusion that they should. Addons can load pages from any domain via Request and Page Worker. And they can modify any page via Page Mods. So it seems to me that they should be able to access all the style info available about a page via the content scripts they attach to pages, even if those content scripts don't necessarily have other chrome privileges. Having said that, I'm not sure how to go about implementing such access. As I understand it, currently such access is granted to code that runs with chrome privileges and denied to code that runs with content privileges. Perhaps we can implement an interface in content scripts that exposes this information.

Here is how I see this feature: We want two different features in the same JS context: - access a reference to a content node - access to XPCOM As it touch to content documents, we have to take care of incoming e10s changes. We need to ensure that addons using such feature will work when content document is going to be in another process. So we can't solve this issue by exposing something new in addon code. We have to play around content script, as addon scripts won't have access to content nodes when Firefox switch to e10s. My current proposal is to add an option to all APIs related to worker/content script. When `contentScriptPriviledged` attribute is being set to `true`, the content script will be executed using system principal, instead of web page one. This patch is limited to context-menu usecase from devtools needs, it will require additional work to ensure that it is working fine with other worker related APIs.

Paul: here is the testcase you mentioned on #jetpack coming from: https://builder.addons.mozilla.org/addon/1009704/latest/ updated to make it work with proposed patch.

Thanks Alexandre. This is exactly what we needed.

I'm curious, does this give the content-script the ability to manipulate objects beyond the context of the web page it controls? Would changing its principal let it e.g. get full XPCOM access? Or could it use one of the the newly-granted objects to get access to full XPCOM? That would lose most of the damage-control benefits of the postMessage-pipe limitation.

(In reply to Brian Warner [:warner :bwarner] from comment #4) > I'm curious, does this give the content-script the ability to manipulate > objects beyond the context of the web page it controls? Would changing its > principal let it e.g. get full XPCOM access? Or could it use one of the the > newly-granted objects to get access to full XPCOM? That would lose most of > the damage-control benefits of the postMessage-pipe limitation. Yes, you are right. It goes against the security approach of content scripts by giving system principal and any xpcom usage. But the usecase is here. We need to give devtools and other addons developers the ability to manipulate content nodes with XPCOMs. Then we should not forget that content scripts handle two important things: 1/ security 2/ e10s And regarding e10s, it doesn't make sense to implement another lower level with more priviledges API that would mostly be identical to page-mod. However, I totally understand your comment here, I don't have clear answer on how we should expose such feature: - No documentation? - Multiple levels of documentation? - give the ability to tweak API, like the MVC proposal of Irakli? (something that allow to add/remove attribute on an existing API and hook methods on it)

This shows how a proxied window fails type checking when an xpcom method expects an nsIDomNode. I could use unsafeWindow for now, but I hope there is a secure solution that could accomodate this case :)

(Pushing all open bugs to the --- milestone for the new triage system)

Comment on attachment 545861 [details] [diff] [review] Add `contentScriptPriviledged` attribute to context-menu/worker The kind of API I'm hoping for here is one that exposes just the specific style information that the devtools team needs in order to implement their addon rather than simply giving content scripts full chrome privileges, which feels too easy to misuse, especially in combination with unsafeWindow! For example, the page-mods module could load another script in the content process that injects an API into the content script that provides access to style info from the page. The other script would have chrome privileges in order to access the info, but it would only expose the style info to the content script rather than full chrome access.

(In reply to Myk Melez [:myk] from comment #8) > Comment on attachment 545861 [details] [diff] [review] [diff] [details] [review] > The kind of API I'm hoping for here is one that exposes just the specific > style information that the devtools team needs in order to implement their > addon rather than simply giving content scripts full chrome privileges, > which feels too easy to misuse, especially in combination with unsafeWindow! If there was only stylesheet, it won't be an issue to do a specific wrapper, but I think there is many usecases. By default I would imagine that devtools team may want to have access to multiple kind of priviledges. Some people are expecting to have access to accessible API that is chrome-priviledged too (for example Eitan in this thread). And accessibility API is really huge, so that building a safe wrapper on top of it will be really time consuming. I'm not seeing this enhancement as a high level feature. We are speaking about XPCOM components and Firefox internals. I'm more seeing this as a low level feature for people that want to use api-utils. So it may the same story than Panel, where we want to have access to both high level and low level for the same API. About unsafeWindow, I discussed with Blake about building yet another kind of wrappers on top of it, and he seems to agree with me on the feasibility of building proxies that would expose Page JS values and avoid any kind of priviledges escalations, like xpcsafeobjectwrapper. It is something to digg to improve overall page-mod usage and security.