On 03/05/2014 01:52 AM, nsm.nik...@gmail.com wrote:
On Tuesday, March 4, 2014 1:26:15 AM UTC-8, somb...@gmail.com wrote:
While we have a defense-in-depth strategy (CSP and iframe sandbox should
be protecting us from the worst possible scenarios) and we're hopeful
that Service Workers will eventually let us provide
nsIContentPolicy-level protection, the quality of the HTML parser is of
course fairly important[1] to the operation of the HTML sanitizer.
Sorry to go off-topic, but how are ServiceWorkers different from normal Workers
here? I'm asking without context, so forgive me if I misunderstood.
Context in short: Thunderbird does not use an HTML sanitizer in the
default case when displaying HTML emails because it can turn off
JavaScript execution, network accesses, and other stuff via
nsIContentPolicy. iframe sandboxes let the Gaia email app which runs in
content turn off JavaScript but do nothing to stop remote image
fetches/etc. We want to be able to stop network fetches by for both
bandwidth reasons and privacy reasons.
I am referring to the dream of being able to skip sanitization and
instead just enforce greater control over the iframe through either use
of CSP or ServiceWorkers. ServiceWorker's onfetch capability doesn't
actually work for this purpose because of the origin restrictions, but
the mooted "allowConnectionsTo" CSP 1.1 API Alex Russell's blog post
http://infrequently.org/2013/05/use-case-zero/ (about CSP and an early
NavigationController/ServiceWorker proposal) would have been perfect.
In the event CSP grew an API like that again in the future, I assume
ServiceWorker is where it would end up. It doesn't seem super likely
since it seems like CSP 1.1 generally covers the required use-cases. If
we are (eventually) able to specify a more strict CSP on an iframe than
the CSP in which the e-mail app already lives, we may able to use
img-src/media-src/etc. for our fairly simple "stop this iframe from
accessing any resources" control purposes.
More context is available at the
https://groups.google.com/d/msg/mozilla.dev.webapi/wDFM_T9v7Tc/_yTofMrjBk4J
thread.
Andrew
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
