Tracking pixels in email should be worthless, because loading external images should be disabled by default in email clients.
Instead, all email clients I’ve ever seen default the other way. Maybe Apple would some day be willing to make its client more secure in the name of privacy by flipping the default. I’m sure they’d face a backlash, though.
I just recently saw a completely opposite suggestion that would also render tracking pixels (mostly) useless: the e-mail server could load, and cache, all the images when the e-mail is received, regardless of whether it's ever opened or not.
The email server does not need to load all the images at once. If it receives a billion emails, it can retrieve linked images a few per second per domain. Or on demand if the email is opened. The email server does not even need to completely drain the queue and load all the images, just images from enough emails to bollocks up the results is enough. The end result is the same, in that the sender does not know if the email was read by a human or not.
> just images from enough emails to bollocks up the results is enough.
A large enough proportion of opens either does not trigger an image retrieval or triggers one but the user won't read the message anyway, so open rates have always been approximate. The time of day, the news, the weather all distorts the data so much anyway that the only sensible use of the data is trends, so it'd take some effort to distort the data enough for it to be useless.
Your best suggestion I think would be to rate limit it, with the caveat that if you want to immediately deliver messages you'd need to also open on demand, and e-mail opens are extremely spiky so you might struggle to smooth out the opens entirely, but it might be enough to make it useless enough for people to ignore the data.
How? If you send an email with an image to 15k recipients in a mail server the image would be fetched once and the recipients would only get the cached version.
You need but one image, to craft an arbitrary number of unique urls using a querystring.
In theory one could also use all permutations of uppercase/lowercase letters in the path to the image. Most webservers are case insensitive so all will yield the same result but I believe the http standard considers the path to be case sensitive so all those urls would be unique.
As I said in another comment, crop all the parameters from the URL, and the problem solves itself. Path is case sensitive, the domain must be lowercased anyways, so no problem either.
So your solution is basically to throw various standards overboard so that spammers cannot generate more urls than there are images on a specific domain. Isn't this cure worse than the (at this point mostly hypothetical) disease?
Crop the parameters and you have no reason to assume it points at the same image. Good luck explaining to your customers what happens when someone finds a way to effectively poison your non-unique image cache with something offensive.
> Crop the parameters and you have no reason to assume it points at the same image.
Well, that is going to be a problem for the mailer. I'm totally fine with banning dynamic parameter dependent images.
> Good luck explaining to your customers what happens when someone finds a way to effectively poison your non-unique image cache with something offensive.
I would say it is the email marketer fault for using unsupported parameterized images. I cannot image a legit use for that, and many evil spammy ones.
> I would say it is the email marketer fault for using unsupported parameterized images.
The problem is this would not just happen to e-mail from email marketers, but also between regular users, and it would take just one particularly nasty exploit of cache poisoning of urls to some site with user-generated content before you suddenly have the press asking you why some innocent picture sent by someone underage to someone else underage was replaced by your site by hardcore porn - or worse.
I've run a webmail provider. I've seen the amount of abusive bullshit spammers and scammers do whether for profit or for fun or to get back at someone. It used to be my job to find these kind of issues before bad guys did, and one thing we learned very quickly was that every little thing like this would instantly have people probing it for ways to abuse it to cause grief for someone else. Or for us.
If you were going to ban images parameterized by URL parameters (and that would not ban parameterized images, just reduce the number of sites that could be attacked), the only viable choice is not load them at all. Just stripping the parameters would be an absolute disaster and wildly irresponsible.
> Just stripping the parameters would be an absolute disaster and wildly irresponsible.
It's not worse than allowing a randomly selected subset of HTML in the emails, and nobody is saying it is an "absolute disaster" or saying that google or Microsoft are "wildly irresponsible". The mailers and people will get used to it. As they always do.
What would be the difference from normal hotlinking in a standard email?
The vector in both cases would be being able to send a million emails; a reflection attack with spam emails as a vector would be just the same without provider servers doing anything special. MUA opening images would do the attack.
Actually a provider could cache the hotlinked resource and remove almost completely the reflection.
Using only plain-text emails solves the problem nicely.
Who'd even want to ever use HTML mail other than shady or clueless or annoying people?
Just use plain-text only and the problem is solved.
Yeah, the typical HN/usenet/ML solution to everything: just use plain text, it's good for everyone and nobody needs anything else. Newspapers and books always looked like an RFC document anyway, right?
This doesn't actually buy anything since with external images blocked the sender can just attach all required images to achieve the same effect without the receiving server having to parse HTML and speak an additional protocol.
It's bad for spam because spammer can recognize what address is alive. Possible solution is open all images including mails sent to non-exist users (wildcard)? Looks like much waste of resources.
Remote images are disabled by default in thunderbird, the Gmail webapp, the Gmail android app, the fastmail android app and the fastmail web app. Gmail makes an exemption for people manually added to your contacts, and they all have an option to load images by clicking a button which then gives an option to whitelist the sender for images.
The Gmail iOS app is the only example of an email client I have handy that doesn't do this by default and since that's signed into my work gapps I can't rule out that being something my employer has changed in the config.
> Instead, all email clients I’ve ever seen default the other way.
What E-Mail clients are those? Both I use (Outlook for work, Fastmail privately) do exactly that, and neither of those are small. The only one I know that’s different is GMail, but well, Google and Privacy.
As far as I know, GMail actually downloads the image as soon as the mail arrives on their servers, accomplishing the “making tracking useless” task in another way.
This is not correct. Gmail's cache certainly obfuscates some data, such as the IP, but email pixels will still tell you when an email was opened and by who.
I'm very sure thunderbird defaults to blocking external images (but there is button to download if you want), because I'm using it daily exactly for this reason. I also have my mail server from small local provider and it has several web mail clients available, each one of them is setup to not download external images.
Instead, all email clients I’ve ever seen default the other way. Maybe Apple would some day be willing to make its client more secure in the name of privacy by flipping the default. I’m sure they’d face a backlash, though.