Ok, sounds like the problem here is "simply" that the CSP code is
reporting errors when it shouldn't be. I don't think that we're
actually trying to do any loads or that CSP is actually blocking
anything. We just don't realize that is the case until we've already
reported a CSP error.

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=818267

I don't think there should be any behavioral changes because of CSP
though. So if possible I would just ignore those errors.

/ Jonas

On Tue, Dec 4, 2012 at 6:31 AM, Andrew Sutherland
<[email protected]> wrote:
> On 12/04/2012 06:39 AM, Jonas Sicking wrote:
>>
>> Here:
>> http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDataDocumentContentPolicy.cpp
>>
>> I'm still confused about what the original email in this thread meant
>> by saying that CSP was applied to the document in question.
>>
>> I.e. what behavioral difference was seen.
>
>
> In the log on https://bugzilla.mozilla.org/show_bug.cgi?id=816922, we see
> warning messages like so:
> ===
>
> E/GeckoConsole(  423): [JavaScript Warning: "CSP WARN:  Directive style-src
> app://email.gaiamobile.org violated by
> http://addons.books.com.tw/G/auto_activity_new/act0000037/green_yellow.css
> E/GeckoConsole(  423): "]
> ===
>
> The presence of warnings from CSP suggests CSP is being applied to the
> document we are trying to sanitize.
>
> As to the actual breakage on the e-mail app; that was speculative based on
> comment https://bugzilla.mozilla.org/show_bug.cgi?id=814442#c14.  Subsequent
> investigation on https://bugzilla.mozilla.org/show_bug.cgi?id=816922 does
> not seem to point any conclusive blame at CSP.  The initial report may have
> been misleading because it appears dump() was not enabled on the device in
> question.
>
>
> My biggest concern was that if CSP is freaking out about the load of a
> remote style document that we might in fact be trying to load a remote style
> document or pre-fetching images or something else that would leak
> information, waste bandwidth, etc.  It sounds like the remote load would not
> happen because of the content policy, but CSP is still getting a chance to
> send a warning about it anyways.
>
> So my new, much reduced concern is that "style-src 'self'" is too strict for
> the e-mail app.  What we want is "style-src 'self' 'unsafe-inline'" so that
> we can both sanitize inline styles as well as be able to display them.  In a
> chrome-privileged world, we could load the HTML e-mail in an iframe with a
> different origin for both sanitization and display, but at least when I
> tried to do that, I found that standard protection of different origins
> against each other precluded our access to and manipulation of those DOM
> trees. (And code reading did not suggest that there were any magic outs; I
> had been hoping I could boss around data URI origins, for example.)
>
> Andrew
>
> _______________________________________________
> dev-b2g mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-b2g
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g

Reply via email to