[gaia e-mail] sanitizing web-bug images?

Mark Banner mbanner at mozilla.com
Thu Aug 16 09:18:44 UTC 2012

On 16/08/2012 02:57, Andrew Sutherland wrote:
> On 08/15/2012 01:42 PM, Joshua Cranmer wrote:
>> Having to do manual sanitization sounds bad in the long term, since 
>> it means we constantly have to watch new features to know if they 
>> need to be added to a blacklist or a whitelist. What needs to be 
>> sanitized that sandboxed iframes can't do? It's probably worth 
>> bringing these up in WHATWG.
> There was a discussion about strategy here:
> https://groups.google.com/d/topic/mozilla.dev.webapi/wDFM_T9v7Tc/discussion 
> Particularly interesting is Henri Sivonen's response, given that he 
> works on the HTML parser and cleaned up the tree sanitizer:
> https://groups.google.com/d/msg/mozilla.dev.webapi/wDFM_T9v7Tc/Nr9Df4FUwuwJ 
> The short answer is that iframe sandboxes aren't really intended to 
> prevent information leakage like forbidding remote images from being 
> displayed or otherwise filtering content (including nested iframes, I 
> think?).  They do pretty well on a lot of other fronts though, as they 
> can prevent scripts, prevent forms, and prevent top-level navigation 
> of their iframe.  If they gain more CSP-like features, they will be 
> even better, and they can always gain other directives.
This probably wouldn't cover everything, but have you also looked at 
setting the allow* options on the docShell? That would give you some 
pretty-big blocks via content policy like features, although not all of 
those would necessarily be suited to what you need (e.g. allowImages 
would obviously disable local and remote images).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4123 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120816/10bf685f/attachment.p7s>

More information about the tb-planning mailing list