[gaia e-mail] sanitizing web-bug images?
asutherland at asutherland.org
Thu Aug 16 02:22:11 UTC 2012
On 08/15/2012 06:40 PM, Ehsan Akhgari wrote:
> By visibility, do you mean visibility as perceived by humans or
> visibility as perceived by layout engines (determined by whether an
> element consumes a big enough box in the rendering)? Would the
> sanitization algorithm be able to detect the following test cases as
> web bugs?
> <img width=100 height=20 src=http://evil.com/webbug-transparent-1x1.png>
> <img width=100 height=20
I mainly meant that if they are going out of their way to make something
hidden as setting explicit width/height does, or positioning the actual
image offscreen, that can be known statically. If they don't set
explicit width/height for an actual 1x1 image, there's no psychic
heuristic that can tell us that in order to prevent loading the image.
We could, of course, have an analytical pass that runs on the images
after they are loaded and feeds that information forward to subsequent
e-mails from that sender or linking to that domain. But that's more of
the arms war thing.
I may have given the impression that I'm trying to fight the privacy
battle more than I am. Trying to distil the issue further, I think my
question is perhaps:
It's clear that 1x1 images are just web-bugs that are wasted network
traffic and a waste of screen real estate to prompt for. Is it worth
the immediate UX and network benefit now of just nuking these with the
knowledge that this could result in those senders making things worse
for the user by simply including a larger graphic as a web bug?
Note: It also could make things slightly better if they just use all of
the other images they link to as web-bugs instead.
The answer to the slightly different question of whether it's a good
idea to fight tracking when the user reads an email is that it's not a
good idea and an arms war is expected to ensue, at least if adopted at a
wide scale. And then I might presume the answer is that nuking the
1x1's (if adopted at a wide-scale) is also most likely to just cause
explicit 1x1's to disappear, thereby increasing network traffic because
it's more likely for people to use larger tracker images than improve
their image serving apparatus that is used for the non-tracking bit of
> If not, I don't think this battle is worth fighting. :/
If we were going to fight the privacy battle, it would probably best be
fought by porting collusion to/writing something similar for
Thunderbird, possibly with a more heuristic driven approach. So the
infobar could say "This e-mail contains an image that only seems to
exist to track when you read the e-mail." or "The image links in this
e-mail appear to contain unique information that will let the sender
know that you are viewing this message."
More information about the tb-planning