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

Andrew Sutherland asutherland at asutherland.org
Thu Aug 16 01:57:27 UTC 2012

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:

Particularly interesting is Henri Sivonen's response, given that he 
works on the HTML parser and cleaned up the tree sanitizer:

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.

I agree that it's worth trying to get standardized first-class support 
for the use-case, but I think a big point is that we are creating a lot 
of new Web API's for Boot 2 Gecko, and that it's probably more important 
to try and get those standardized first, at least for the API's that 
would fight for WHATWG HTML bandwidth.

It is worth noting that iframe sandboxes have not yet landed, although 
review appears pretty much done: 

> 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.

Nefarious may be overstating it.  If an email is going to contain 
images, there are upsides to storing the images on the server rather 
than embedding them in the e-mail.  It's just the information leakage 
byproduct doesn't have a clear benefit to the user and does have 
potential sinister tracking undertones, especially if the web-server 
does something like claim the cache lifetime is such that the image 
should be re-validated every time the user looks at the email.

My primary issue with a 1x1 image is that it's wasted network traffic 
and B2G e-mail's initial target is phones using relatively expensive 
mobile data plans.  Newsletter/advertising e-mails will frequently 
include many external image references (large ones) and then also go on 
to include a 1x1 web bug, presumably because infrastructure reasons 
separate their actual image delivery from their tracking mechanism (and 
therefore may use a different domain, thereby requiring an additional 
DNS lookup, etc.).

For example, thinkgeek's newsletter uses www.thinkgeek.com for serving 
all images, but the (explicitly sized using width and height attributes) 
1x1 unique url web-bug uses click.email.thinkgeek.com, which is also 
what all clickable unique url links get sent through.

In contrast, gymboree uses a non-explicitly sized 1x1 unique url image 
served from open.mkt2170.com, but then still goes on to serve all images 
from content.mkt2170.com with unique-looking url's, and links via 
links.mkt2170.com with unique-looking url's.

> 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.

We are using white-list sanitization, per the discussion linked to 
above.  Right now the sanitization takes whatever we are provided and 
crams it into an innerHTML on a div which discards most of the stuff in 
the "head" tag, but some of that stuff may then fall out of the "head" 
to be part of the body.  This was a stop-gap measure and I do hope to 
support stuff in the head, especially if it stops MS Word-composed 
e-mails from spamming the body with tons of redundant "style" tags.

The actual sanitization engine is bleach.js (whose defaults are *not* 
used by us):

Our whitelist and processing logic is here:

The CSS whitelist is particularly limited since I did not have 
nsTreeSanitizer's lead to follow; I basically just skimmed MDN's list of 
css attributes for things that seemed important and not dangerous or 

> 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?]

The src tags get transformed onto a custom attribute which we reinstate 
only on user request.  We treat cid: links (embedded images) and http 
links differently.

svg gets completely stripped right now because it introduces various 
edge cases, as you say, that will take more work to handle correctly.  
And no one uses it right now.

> 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.

So, right now I just forbid all css style directives that can include a 
url(), or at least I think I am doing so (please let me know if I 
screwed up!).  This means no 'background', but the specific 
'background-color' directives are supported.  This does not seem to be 
an uncommon approach.

It is a goal to just know which attributes can include url() references 
and then add sufficient parsing logic to handle them like we handle img 
"src" tags.

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

Three main reasons, in order of increasing importance:

1) It seems advantageous to treat e-mail messages as static content for 
the benefit of the human being reading the message.  Do we really want 
to wait for messages to fade-in after an interstitial, or have an a big 
"read this on our website instead!" div float over the content obscuring 
it after a few seconds?  This also makes automated filtering/processing 
of the messages easier because there is less need to try and figure out 
what the intended steady-state of a message is.

2) No one seems to do it right now anyways.

3) Power consumption/device responsiveness.  The primary target is a 
mobile device with a battery, limited memory, and limited CPU. 
Animation/transitions can burn CPU, GPU, and memory (of both) resources 
thereby affecting battery life and responsiveness of the e-mail app 
itself, as well as starving out other background processes.

#3 is the dominant reason, with #2 being an important input to the decision.


More information about the tb-planning mailing list