Live data from Hacker News

Gmail blows up e-mail marketing by caching all images on Google servers

arstechnica.com

261–270 of 322 posts

Re: Gmail blows up e-mail marketing by caching all images on Google servers

#261

Earlier quoted context omitted.

I'm fairly sure sending an email is more expensive than sending a GET, so it should be more effective for an attacker to make the requests directly than trying to use this to get google to proxy an attack. I also strongly suspect that google's crawling infrastructure is more than capable of fetching a bunch of images for every single message gmail receives. But even if I'm wrong about the above, google is perfectly c…

In reality, I'd be less worried for Google and more worried for whoever is hosting moderately large images that get linkjacked in numerous variations ( http://www.example.com/largeimg.png?randomnumber=72435 ). Google can't tell, a priori, whether or not a series of similar e-mails sent to many thousands of people with Google Mail addresses and containing similar but different image links like the above is a genuine m…

Why involve Google? Aren't sites on basic, low-volume hosting plans easy to knock over, without resorting to DDoS tactics? And if you're trying to knock over bigger sites, it doesn't seem like Google would make a very good DDoS platform in any case, since the requests would be originating from a relatively small range of IPs that a bigger site could just ban. Presumably the only reason they wouldn't want to ban the requests is if they're actually the ones sending the emails in the first place, so the problem sort of solves itself.

Re: Gmail blows up e-mail marketing by caching all images on Google servers

#263

Earlier quoted context omitted.

But if Google always fetches the images, then there's no way for the marketers to know if the email was actually opened or not.

Apparently Google does not always fetch the images. But even if they did, this is still more information leakage than the old default (don't load images). Spammers who email via botnets and the like, with false return addresses, doesn't get bouncebacks to clean their lists. But if you (or Google, on your behalf) give them a hand by reliably loading their tracking image, that flags your email as a valid one. If you we…

An alternative could be to let the user decide if Gmail should prefetch images from a sender or not.

Email from familiar senders would have images prefetched (thus avoiding leaks of user data).

And DDOSing concerns would be reduced because those emails would not be from a familiar source.

Re: Gmail blows up e-mail marketing by caching all images on Google servers

#265
post #44

Earlier quoted context omitted.

Google could retrieve and cache a random sample of the images and hash them. Then they could note which image links go to the same images. And they could identify image links by noting that a bunch of emails have the same structure except for one image link that's different for every recipient. So I think they actually could take a pretty good stab a deduping images with unique tracking URLs. It might not be perfect,…

Easy: Make the "Dear " part of the email an image. Boom, deduplication fooled. (Also, they don't currently seem to do anything like you're suggesting.)

Although I'm sure it's possible to fool their image hashing algorithm, I doubt this will. Image hashing algorithms are designed to be resistant to small changes in the image and more advanced ones can generate hashes that determine how similar one image is to another. I haven't tried this, but you can probably see a proof of this using google image search. Add some text to an image, and see if Google image search can find the original.

Re: Gmail blows up e-mail marketing by caching all images on Google servers

#266
post #198

Excellent, I've always wanted e-mail clients to do it this way. You send me a mail - you've no business being able to track if/when/how I open the envelope, unless I explicitly wish to inform you.

I think it's the opposite. With Google's change, the sender can more accurately find out if you've opened the email, since a request to download the image will be made as soon as you open the email. However, what the sender doesn't get now is IP, location, and browser data.

Well, an appropriate solution would be to 'open, package and store' the email at the time of receipt, not reading - that may cost some resources of extra bandwidth and storage, but would provide a better functionality and permanence in case of opening that email two years later when the sending company and their servers may be out of business.
Post reply on HN