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

Joshua Cranmer pidgeot18 at gmail.com
Wed Aug 15 20:42:58 UTC 2012


On 8/15/2012 2:53 AM, Andrew Sutherland wrote:
> (I am posting to tb-planning as a proxy for the mozilla mailing list 
> relating to the e-mail problem domain)

Not mdat instead?
> The (gaia) e-mail client for Firefox OS sanitizes all HTML because it 
> can't use content policies to limit the capabilities of its iframe and 
> iframe sandbox directives.

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.
>
> context:  HTML e-mails sometimes contain "web bugs" which are intended 
> to notify the sender of the e-mail when you have read the email by 
> causing your mail reader to trigger some type of network access that 
> they can detect.  This is frequently done with 1x1 images.  Other 
> possible tricks have included background sounds, and (I'm not sure 
> whether anyone ever really used this) relying on DNS prefetches (to 
> their DNS server).
What do you mean when you say 1x1 images? How many different styles are 
present? A particularly nefarious way to test for the email read is to 
make the entire content dependent on remote images.
>
> Thunderbird blocks remote images and shows the "To protect your 
> privacy, Thunderbird has blocked remote content in this message." It 
> does this even in the case where the only images present are 1x1 web 
> bugs.
>
> The gaia e-mail client imminently does the same thing, but the cost of 
> showing the info-bar equivalent is much higher because screens on 
> mobile device are smaller.  Also, the network traffic is potentially 
> more expensive to the user.
>
> Since there is no real user benefit to the web bugs but definite 
> privacy costs (if loaded) and potential usability and network costs, 
> it seems reasonable to simply scrub the web-bugs from the HTML as part 
> of the sanitization process.  (Also, it saves storage costs since 
> sanitization occurs during synchronization.)
>
> The arguments against sanitizing the web bugs are (possible 
> interpretations of) user choice and game theory concerns that 
> sanitizing based on explicit sizing (width=1 height=1) could lead to 
> an arms war.  I don't view the arms war as particularly concerning as 
> e-mails can't run JS, transitions/animations are also sanitized, the 
> sanitizer has access to a layout engine enabling it to determine 
> visibility, and it is generally believed that most e-mail clients have 
> poor HTML support.

What are you specifically doing in terms of sanitization? In terms of 
perception of HTML support, there is Outlook which has (IIRC) roughly 
the same layout engine as IE 5.5 (so only very basic CSS works), and 
Gmail completely ignores any non-inline style, but most other clients do 
a passable job in rendering. As a list of things that cause concern that 
would need to be sanitized (IMHO):
1. Plugins and other embedded content.
2. Script and on* attributes
3. frames/iframes with remote sources
4. images/svg paint servers with remote sources [are the bgsound/midi 
stuff still supported in Gecko?]
5. Anything with url() in CSS that loads a non-cid source. I don't have 
a complete list on hand, but anywhere a CSS property takes <uri> is a 
candidate.

I'm curious as to why you sanitize transitions and animations...

-- 
Joshua Cranmer
News submodule owner
DXR coauthor




More information about the tb-planning mailing list