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
