[gaia e-mail] sanitizing web-bug images?
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
> 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
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
> 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