To specifically answer Geoff's question - the difference you're seeing
between JS/CSS and docshell loads is that the former end up with the
principal of the loader, whereas docshell loads end up with the principal
of the loadee. Allowing content to load a chrome-privileged window is super
dangerous, which is why it's forbidden.

On Mon, Jun 8, 2015 at 8:18 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:

> On 6/8/15 6:57 AM, Geoff Lankow wrote:
>
>> If I have an about page marked URI_SAFE_FOR_UNTRUSTED_CONTENT, it
>> happily loads css/js from chrome://browser (in fact, about:home does
>> this), but throws a security error loading from chrome://foo. Is this
>> intentional?
>>
>
> Whether untrusted content can load CSS/JS from chrome://something depends
> on whether the chrome://something has opted into allowing that.  This
> allows extensions to expose only the things they want to expose.  See also
> https://developer.mozilla.org/en-US/docs/Chrome_Registration#contentaccessible
>
> In this case, browser/base/jar.mn has:
>
> %  content browser %content/browser/ contentaccessible=yes
>
> So yes, the behavior you see is intentional if the registration for
> chrome://foo does not explicitly expose its stuff to untrusted content.
>
> That said, it's pretty weird to me that we're exposing the entirety of
> chrome://browser like that.  Seems like we should scope it down.
>
> -Boris
>
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to