> E-mail marketers will no longer be able to get any information from images—they will see a single request from Google, which will then be used to send the image out to all Gmail users. Unless you click on a link, marketers will have no idea the e-mail has been seen.
Absurdly wrong, marketers already use a unique image URL for each email recipient, and Google has no way to know that all of those point to the same image. So they won't see "a single request from Google", they'll see one request from Google per successful delivery to an inbox.
Now, an open question is if Google will make that request when the email is actually opened, which would allow marketers to determine if and when the email was read by the user, or if Google will make the request as soon as the email is received. The latter would enhance users' privacy at the cost of bandwidth for Google, but early tests indicate that they don't actually do that, waiting for the user to click the email to make the request.
I'd like to add that there's no possibility the Gmail team is stupid enough to not have considered this. They must know full well what they're doing, and marketing this as a privacy enhancement when it's actually detrimental to privacy is willfully dishonest.
> Now, an open question is if Google will make that request when the email is actually opened, which would allow marketers to determine if and when the email was read by the user, or if Google will make the request as soon as the email is received. The latter would enhance users' privacy at the cost of bandwidth for Google, but early tests indicate that they don't actually do that, waiting for the user to click the email to make the request.
I've just tested this.
The image was retrieved when I viewed the email in Gmail.
The tracking info basically comes back as "anonymous" and viewed from an unknown location.
The image was retrieved twice even though I only viewed the email once.
Currently I'd say that seeing the image being viewed is still valuable. I'm sure Google could move to proactively fetching the images in future destroying even that value.
The image is cached (via browser headers), but isn't aggressively cached (via reverse proxy). Fresh views on different browsers or a later session would still result in a request for the image back to the source server... registering the view again.
My personal view on all of this is that this is a bit Microsoft... you know, convenience and features over security and privacy.
For me, this "feature" leaks data about what I view to 3rd parties where today I block all images and do not leak that info.
Wait, do I understand you correctly that Google fetched the image even before you requested that images be displayed in the email? That seems like a boon to marketers, not a bane.
The alternative to "OK" is "Settings," with a link that just dumps you into the main settings view… leaving you to find the Images section to change it back. Quite an opt-in.
Now google has the data, and they almost defaulted the option for everyone. That gives them a big boost in data receives which they could use for marketing "(hey guys you remember you got × amount of image loads, we made your images get loaded by × more users now if you want the data we got it right here for the right price.)"
If you go to the trouble to figure out how to disable the "auto-load images" setting, then they're just as blocked as before.
If you accept the new default, it's far easier for them to track you, because Google will kindly be loading their tracking images on your behalf when you open the email, every time.
> I suspect this is a UX anti-pattern. I've gone back into my settings and changed it back
Gmail has done this enough times around already for to me become a UX anti-pattern in itself.
It's weird to look back to the days people were begging for invites and Gmail was the best game in town. These days the few times I'm forced to use GMail it almost makes me rage.
The "normal users" I know which are forced to cope with Gmail are constantly and consistenly confused, asking me where things they used to know have gone, and why Google is ruining Gmail.
Glad I migrated to something better, somewhere where I know for a fact that I am the customer, not the product.
I moved to fastmail which I found wildly refreshing. In the same sense I found Gmail refreshing when it first was launched.
Once you try using fastmail, you will be surprised by how incredibly lightweight it is. When you first get used to that, trying to use Gmail feels like wrestling a horribly bloated pig. The UX has just become terrible.
As for fastmail or other options... I was very keen on being able to host things 100% myself, preferably using FOSS, because of privacy concerns and being in control of my own data.
After trying out various FOSS (and non-FOSS) solutions I decided none of them were good enough/polished enough for my needs.
In that regard fastmail is a compromise for me compared to what I ultimately want, but it's a compromise I'm more than happy with.
According to the announcement, if you've already selected the option to ask before displaying external content, when this feature rolls out to your account it will also default to set the new setting to ask before displaying external images.
The way I read the comment, I think you are correct about it being a boon and not a bane. However, it is because the request was timed at the same time as the message read, not the other way around.
It seems the commenter functionally tested an external URL being requested by Gmail, and found that the request was coincident with when the commenter opened the email. This essentially "leaks" that you've opened the email as the image URL could be unique to your email message.
This is correct. This makes unique open counts much more reliable as it guarantees that the tracking image will be fetched. Before this change, one could never be certain how many people actually opened their email in gmail because some percentage of recipients would block images which naturally blocks loading the tracking image. Typically the tracking image is unique to each individual email sent.
There is no advantage of prefetching images from familiar senders. It's not about faster image loading.
The ideal thing would be to just prefetch all the images sent to existing and non existing accounts. This way there is absolutely no way for a spammer to tell whether an email is existing or not.
Sorry, I wasn't precise. I was responding to the suggestion to only proxy for familiar senders. But, assuming that you can correctly identify who is familiar and who's not (there is scam detection as well), the benefit is minimal.
There is bigger benefit of doing this proxy for non-familiar emails.
Google could prevent leaking if email address is valid by simply prefetching images even when email is sent on non existent accounts.
Sounds like a great way to verify an email address to me. Send an email with a tracking image and if you get a hit, presuming they pre-fetch, you know it's a valid email.
> Convenience and features over security and privacy
I don't understand. It probably has to do with the Zeitgeist.
The images were originally blocked because of security and privacy concerns.
Rendering of images is potentially insecure because of bugs in the browsers. By proxying the images, Google as an webmail provider, screens you from your browser bugs. Solved.
Rendering of images is a privacy concern because of tracking.
By fetching the images from another place, the attacker cannot know your location, your OS, language setting, etc... Solved.
Rendering the image allow checking when and if the email is ever opened, which can be useful in marketing^Wspam primarily because they can understand whether an email is active/exists or not. Not Solved.
The latter however is a general problem. There are many other ways to know whether an email account exists or not. Many mail servers respond with bounce emails anyway. They won't bounce on detected spam, but that's not the point; this feature is an additional barrier for image tracking for content that has passed through the spam filter already.
1. Google may cache all images in all emails sent to gmail.com instantly and regardless of the existence of the address. This would remove the possibility for marketers to check user timestamp, remove user data from request and hide user email existence.
2. Google does _not_ need to save each image from each unique URL separately, all they need to do is fetch each image and check against an already existing (mega)array of images they've fetched. This greatly reduces storage needed, but doesn't do much for the bandwidth requirement, but they won't care about bandwidth in all their Googleness.
3. The single most important aspect of this change has been omitted in the article, and in your comment: This change completely eliminates the risk of CSRF attacks by spammers and the likes. CSRF attacks are still number 8 on OWASPs list of top 10 attacks.
I thought that 99% of the images included in emails for tracking purposes are single pixel transparent GIFs - so no biggie in working out which ones those are...
In the e-mail campaigns we send every image is a tracking image. It all just goes into our log files an is then post-processed, so the additional cost of processing every image is minimal compared to the rest of the cost of the send.
Using a separate tracking pixel is pointless unless you for some reason want to let some third party track the opens (which some people might, e.g. to prove certain open rates)
As someone who co-invented email image bugs with a million other programmers over 15 years ago, you are absolutely correct. (for the curious, my reason for coming up with it was to tell when a customer who requested a car insurance quote from the company I worked at read their email which instantly initiated an outbound call to them).
The entire article is just plain wrong. For instance:
This move will allow Google to automatically display images, killing the "display all images" button in Gmail.
Go ahead and do that, Google and you'll bring Web bugs back completely. How about this:
1. Marketer embeds a "jpg" file whose filename consists of a GUID that matches back to a user.
2. When you load that "jpg" file, it gives you an image unique to that user - maybe an MD5 hash of their GUID filename or some other thing unique to them that holds no value.
This would uniquely identify that a user reads their email. How would Google stop this? They can't cache it for multiple users. Both the filename and contents are unique to the user. If you think they could otherwise detect it for this particular situation, I could think of 100 other ways to do this that would not be able to be tracked in the same way.
There's no way Google or any other email provider can legitimately automatically load email images and not open the door to web bugs. No way.
There is ONE way: fetch every single image right away regardless of whether the email is even valid. And then don't store the cached version if there is no valid email. Otherwise store it and display to the user.
Since every result will be a positive - false or not - no information is revealed to the marketer AND the images are displayed.
There is ONE way: fetch every single image right away regardless of whether the email is even valid. And then don't store the cached version if there is no valid email. Otherwise store it and display to the user.
Sure, in theory that works. In practice, you make an easy may to do a Denial of Service attack against Google or innocent third parties so it in actuality would never work.
Send a million emails to Gmail accounts that each have fifty links to 1 MB JPG files hosted all over the Internet. The size of the file you send to Google in the email is what - 1k? The size you are making Google download is 50 MB. This is a 50,000:1 attack ratio. You could take Google down with a 56k modem.
You could also launch a denial of service attack against any other target, courtesy of Google. Send a million emails to Gmail users that downloads JPGs on a target web server. You can even make up the JPG names to be non-existent. Again, figure your email is costing you 1k in transmission and Google is putting tremendous strain on the target server downloading 404 error messages.
Google does SPAM filtering and has no obligation to deliver those messages. It can throttle its acceptance of messages from the same IP block. How is this different than any other (distributed) DNS attack mitigation?
It can throttle its acceptance of messages from the same IP block
There are literally tens of millions of computers infected with malware making them part of a botnet (ex: http://www.csmonitor.com/USA/2011/0629/Biggest-ever-criminal...). The cost to hire 1 million of these computers (all with unique IP addresses) to send emails out is trivial. You'd be shocked how cheap it is.
Now here's the thing... SPAM is pretty easy to spot because someone is trying to sell something. In this case, you're not trying to sell anything. You just need Google to download things. So you send an email with "Vacation Pics" in it. Sure, Google could filter them out but they're all from unique IP addresses from home computers across the country/world and they aren't trying to sell anything. They probably could filter out some of them at the cost of filtering out a lot of false positive legitimate mail.
Internet security is complex - you seem to think otherwise.
Snowshoe spam is pretty common now, with a lot of the larger networks mixing in spammers with legitimate traffic (lookin' at you, ovh.com).
As it is right now, spam is just mostly a drain on network and human resources.
This attack would also target storage. Google has enormous amounts of storage, so I've no idea whether it would be effective against them or not. But, it would be very effective against any smaller service providers that tried to do the same image caching thing (which so far seems to be a roundly bad idea, IMO).
It would also open up the possibility of using Google as an attacker to take down other sites. If Google's servers immediately requested the image for caching, then just send out a few million messages to Google addresses, each one with a unique URL pointing to some big image file on some site you want to take down. Most sites will accept a query string after an image URL, so ... bob's yer uncle. As it is now, this isn't an effective attack because you need to get people to actually open up the email message and then click "Display images", all within a short period of time.
Nope; still the same filtering; they are not going to cache things detected as SPAM; so an attacker would have to fool the anti-spam algorithm first... good luck with that!
Gmail has probably the best spam filtering in the world, but you seem to think it's flawless, and it's not. I just now signed into my old Gmail account for the first time in ages. There's spam in there, and recent too. Roughly one per day by the looks of it -- messages that aren't newsletters, or from previous contacts, or anything that I signed up for.
And spammers aren't even that smart, they're just numerous and financially motivated.
If somebody wanted to annoy someone else with this, they could.
And, again, even if this doesn't work against Google directly, it certainly would work against other service providers who decide to follow Google's lead.
Heck, just look at the recent popularity of the WhatsApp spam that spread malware to tons of people (including Cryptolocker in some cases), or the "Secure Document" phish that made the rounds in Gmail in September.
Ok I see your point; but I want to add that one of the reasons your old account has spam is because you don't use it; I don't know what algorithm they are using but it certainly relies on usability data; I don't know exactly but could be: what language you usually speak in; what hours of the day you receive and read important email, what subjects you read about, etc etc.
Yeah, that could be. I have to spend a significant part of my time now dealing with spam (sysadmin), and Gmail's handling of spam is years ahead of most of the tools I have available.
But this is Google. They already want and try to load every url in existence. DoS attacks based on flooding actual content are largely irrelevant to them.
Attacks on third parties are trickier, but you can do the same sort of thing today; how often is this tactic used already? And can't you download 404 messages yourself for cheaper than 1k?
Google could check if GUID_1.jpg is the exact same image as GUID_2.jpg.
If the same, just show a cached version. No more tracking.
(of course, email marketers would thwart this by making each image slightly different. google would respond by checking if the images are almost exactly the same. repeat. whack-a-mole ad infinitum).
Eh. When they fetch GUID_2.jpg to check its content, it's already too late at that point; the marketer has been notified that this particular user has opened the email.
Google might save themselves some storage space, but not anyone's privacy.
If Google changed their policy to fetch all images when the email is delivered, that basically delivers a false positive to all marketers/spammers/etc. -- which is better than more accurate info, but it's still worse than just not loading the images.
It's still a confirmation that the email address is valid, plus... who wants to give spammers (or marketers, for that matter) a false positive? The unsophisticated ones won't realize that it's a Google change; they'll just put you on the "interested" list and move on.
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, but even if it works 95% of the time they could still kill the profitability of the unique tracking image technique.
What if google just immediately fetches images for all received messages, regardless of deliverability? They can dedupe wherever possible, but the sender still ends up with no information about whether the message was delivered, much less read.
What if google just immediately fetches images for all received messages, regardless of deliverability?
I'm trying to work out whether this is more useful as a way to get Google to DoS themselves or as a way to get them to DoS arbitrary web sites of others. Either way, isn't this a gift to trouble-makers?
Of course Google would probably develop an automated defence against such attacks quickly if they happened in practice, but it seems any such defence would necessarily involve not caching all the images in advance, which would defeat the original point.
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 capable of throttling their fetching to mitigate. (The problem really ends up looking an awful lot like crawling the internet, which is an area that google seems to have a bit of experience)
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 mail going out to someone's list or a DDoS of www.example.com in which Google is about to become an unwitting participant.
By the time they've worked out whichever trick is being used this time (in the same way that they adapt to changing black hat SEO tactics, but probably only make major changes every few months) it's not hard to see a hostile party busting the bandwidth cap for anyone on a basic, low-volume hosting plan.
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.
This is an old problem with an old solution. If you have an expensive-to-generate resource that you don't want automatically retrieved en masse, you use robots.txt to deny access to it.
AND it could create a dis-incentive to load up an email with unique images since as soon as you send the email out all of those gmail addresses are coming right back at your server to request the images.
You can somewhat do this with the current system. I had no problems sending an email with 10 10mb images. Google happily fetched all 10 of the images off my server.
Not sure if they limit it at some point, but if a server accepts urls such as:
Google would fetch each separately. Send this out to a bunch of people, and it seems problematic. I'm going to be optimistic, and assume they built in some sort of limiting, but who knows.
We manage opt-in mailing lists for customers of restaurant chains, and for well timed, well-targeted campaigns they get open rates in the 30%-40% range with the majority of opens within 15-30 minutes of the send anyway. It takes more resources for us to handle the outbound mail load than to handle the inbound image requests, as for the image requests the url's contains enough info to do a trivial regexp based rewrite and fetch the images from a cache. I don't think handling a 100% open rate as soon as the mail was delivered would even remotely be a challenge.
With google's machine learning brain trust, I think they could still do a pretty good job deduping. Maybe not perfect, but I'd bet on them to win an arms race.
Edit: ah, codeflo and EGreg are right. I was just thinking about the task of determining that the images serve the same role in each message (which I'm sure google could do a good job of). But (as they point out) in the "Dear <user>" case they'll still have to show the right image to the right user. Although, as Nacraile and jaxn say, if they load all those images eagerly they'll remove the value of those unique tracking images, and impose a cost on the sender.
There's a huge difference between something that they might do, in theory, at some point, using vaguely magic machine learning technology, and what that they are currently doing, right now, to address the privacy concerns over a change that they already rolled out to millions of users.
Are you saying Google will try to guess and reconstruct "Dear Marge" in the same font as "Dear John" instead of requesting both from the origin server?
Scary enough to the average user it'd probably kill the the technique very quickly.
I'm not sure about that. It's nothing that desktop clients such as Thunderbird haven't been doing for years. I don't see any remote images in any e-mail until I click to say load them, and this works in much the same way that plug-in elements like Flash and Java are now click-to-show in various browsers. Numerous marketers and mailing list services still use the technique to track an approximation of reader numbers, though.
Nah, nobody pays attention to warnings attached to Gmail messages after having seen so many of them.
A particular example of crying wolf that comes to mind is the yellow box that says, "HEY! THIS SENDER ISN'T WHO THEY SAY THEY ARE!", which usually means that someone just forwards their .edu address to Gmail.
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.
Procedurally generated fractal backgrounds with random seed, that might work?
Anyway, I think it would be perfectly fine if Google matched up emails with similar content and where there was one image that was unique for everybody just remove it, maybe with a note to the user in that case.
Do NOT have a "click to load images" button. If users can't ever see them then it completely destroys spammers' ability to use them even for a rough sampling.
I would love to see spam as an advertising method be completely destroyed. It won't be, because even without tracking it is still easy and useful to spam out lots of ads, but this would help.
Yup. Though I suspect my university's alumni newsletter also has tracking images in it. I haven't checked, but if I were them I'd use a tracking image.
E-mail marketing companies would make a fortune coming up with "image composition plugins" for their systems. E.g. manipulating background patterns; alter the positioning of image elements; change text positioning, size, fonts; change objects in the images.
If no actual http request between the email recipient and the sender happens, doesn't that also imply that the sender has less opportunity to do all the regular http user tracking stuff to associate the browsing session with that email address? That seems vaguely beneficial.
It doesn't even mask repeat opens: as buro9 found in the sister comment, the image does not get cached, Google's proxy will request it again each time it is viewed.
Google was already image caching external email images, IIRC. So as far as amount of raw information being leaked, I think today's feature launch represents a step backwards.
Yeah, I am not sure where the original claim is coming from. It isn't that hard for Google to simply follow the links and compare the files as part of the caching process. So unless marketers start customizing the images in addition to the links, there isn't any reason why Google can't cache the images together.
And even if marketers do start customizing images, hasn't Google gotten pretty good at comparing very similar files? Isn't that how Google Music works without having a copy of every single individual upload?
will work just fine. So, Google will follow the link and compare the files and... wait a second, the information we care about - that slg read my email - has already been transmitted.
They are unlikely to do that though: it would waste a lot of bandwidth requesting images that users are never doing to see because they'll delete the mail before opening it. Google may have bandwidth and server resources to cobble dogs with, but they are not going to waste it like that I assume. Also if they did you could easily perform a DoS attack (or just give someone a big bandwidth bill) by sending out a pile of email with an image tag pointing to a large object on a competitor's web servers.
I don't understand how that helps. If I send an email to user_x@gmail.com with an embedded image at http://example.com/my_spam_images/image_for_user_x.jpg and google makes a request to that, I know the mail has been delivered and the user in question exists and is seeing my ads, because a request for image_for_user_x.jpg showed up in my logs.
Now, when user_y also receives my spam and I get a request for image_for_user_y.jpg and I just serve the same file, Google is probably gonna deduplicate them on their cache or cdn or w/e, but only after they've sent me the request and confirmed that someone read my email.
I'm not trying to overload google's storage capability here (lol), I'm just interested in the information leak.
Similar to how they detect spam by comparing similar emails (eg, same sender, largely the same content, etc). So the first maybe 1,000 or so see the spam in their inbox, but after enough people report it, everybody else gets it in their spam folder.
So they could learn that for all these emails with largely the same content, this one image has a slightly different URL, but the image is always the same (or similar). So as with spam, the marketers might see the first few "opens", but once Google learns that they all similar anyway, the won't see any more.
Now, I don't know if that's what they are doing, but its certainly possible.
Here's the social workaround to that: Send a few e-mail campaign with "time sensitive offers" with a timer that starts on retrieval off the image with a "oh, by the way, please not that for Gmail users it starts on delivery as Gmail loads the image right away".
People love their e-mail offers. The type of users e-mail marketers want the most - namely the ones that responds to their offers very well - would be up in arms if Gmail makes them start missing out on offers.
And even if marketers do start customizing images, hasn't Google gotten pretty good at comparing very similar files?
For image tracking pixels, I'd just start returning PNGs of random dimensions with completely random pixel data. Ta-da, unique images that aren't similar at all (unless they wanna start doing wavelet transforms or something).
Succeeded in what, confirming that Google is still in operation? Please note that Google doesn't even have to confirm the receiving email address is valid in order to get the image.
I just checked and Google rejects an e-mail after the RCPT TO: stage if the recipient address doesn't exist so they would not receive the message content.
$ telnet gmail-smtp-in.l.google.com 25
Trying 74.125.142.26...
Connected to gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP nh2si25383829icc.26 - gsmtp
EHLO myhostname.mydomain.com
250-mx.google.com at your service, [my.ip.was.here]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 CHUNKING
MAIL FROM: <myusername@gmail.com>
250 2.1.0 OK nh2si25383829icc.26 - gsmtp
RCPT TO: <non-existant-address@gmail.com>
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 http://support.google.com/mail/bin/answer.py?answer=6596 nh2si25383829icc.26 - gsmtp
Easily is a bit of a stretch, because most users are on NAT setups and they would need to go into their router settings and know how to set them up to allow the external request to get through. So, yeah easily if (a big if) you know how to do that, or if (another big if) you are on a machine that is directly visible on teh interwebs.
Of course, if Google instantly downloaded every single image reference in every email accepted by their MX, there is no longer any useful information in that fact.
Waiy are you saying Google will try to guess and reconstruct "Dear Marge" in the same font as "Dear John" instead of requesting both from the origin server? What if the image they didn't download includes a picture of a baby instead?
Ok, but then Google's still making a request to, here, a user-specific URL. The spammer may not know where you are, but they now know that your address exists.
They don't normally get bounce requests, though -- a tracking image is easier.
You've probably noticed that most spam comes from "borrowed" email addresses, not ones the spammer actually controls. If anyone ever sends a ton of spam with your email address on it (this has happened to me) it really drives the point home.
Well of course it has a way. It can fetch the image. Then it will see it's the same - but now that means that the mail is 'reported' as delivered, possibly before the person receiving it has ever opened the message. This is an issue both for individuals (I don't want this information reported) and marketers (false positives).
De-duplication is already a "big deal" in lots of hosting situations, such as box.net, dropbox, etc. I doubt it's outside of the skillset of engineers at google to address the problem. Especially given that google already has the technology to do image searches based on other images.
I just did a quick test using Mailgun and recorded the results [1].
The TLDWatch is that Google does give you back the open event and they also give you the email address of the open since this data is encoded in the URL.
The data that is not accurate is what you would expect: IP address, geo-location and user-agent string.
We'll hopefully write a more extensive blog post shortly.
> The data that is not accurate is what you would expect: IP address, geo-location and user-agent string.
Also any cookies present in the user's local environment from other actions (images from the same ad network in other emails or from visiting web pages that use the same ad network) are not going to be sent, so tracking you between locations is going to be neutered somewhat.
Google gets huge benefits from it but I think in the end this helps advertisers as well as still being able to track via the image url and a unique url/id. Good deals usually help both parties with some give and take.
Pros:
- Since all images flow through google, phishing and other malware attacks could be subverted.
- Images will be hosted faster in many cases (possibly less cost to run newsletters).
- Less connections on your server/cdn from multiples sources but google singularly.
- Still able to identify users legitimately but new users and newsletters will have more trouble getting your information initially.
Cons:
- Re-views later will not be tracked if out of cache, it will come from google the second time if is hasn't been purged (re-views are not big on newsletters anyways)
- Google getting all this data as well as your company
> Now, an open question is if Google will make that request when the email is actually opened, which would allow marketers to determine if and when the email was read by the user, or if Google will make the request as soon as the email is received.
I reply to this question here. Sadly, a request is done each time and only when a user loads the image.
If google cached them as soon as they were received wouldn't they, in some cases, effectively perform a DoS attack on whatever was hosting the image? I.e. if a spammer sent out 1,000,000 emails w/ images they were hosting, they would immediately receive 1,000,000 requests for the image.
I think such a behavior is really easily spotted and filtered, if not already blocked by spam filters.
Google has the technology to do that, the question is whether they want to put in the investment of storage required to actually guarantee users privacy, of if they just want to spend the least amount they can get away with...
Are we sure they won't programmatically/statistically detect these tracking URLs and start skipping the request after the first dozen or so retrievals out of 10,000,000?
There is a simple way around that. You are saying that the fact that Google retrieves images means that the mail was delivered. But this is only true if Google retrieves images only from delivered mail.
If Google retrieves every image in every mail sent to @gmail.com, @googlemail.com etc, then the only thing the retrieve tells you is that you spelled "gmail.com" correctly - nothing about whether there is a mailbox there or whether it was delivered.
and presumably bounce it in other cases? I mean this could be a way of ensuring that certain addresses exist without needing to be able to receive the bounced mail if they don't. But how is that an interesting or useful vector?
If Google does this with every mail regardless of the inbox it goes to (spam etc) then it doesn't tell you any more information than you learn from not receiving a bounce. However, I could imagine a scenario where the bounce address is wrong anyway (spoof) - is this really that useful for anything?
I mean, presumably most combinations of common first and last name plus two digits go to a registered mailbox. How does being sure that it is registered (but knowing nothing else) without having to be in a position to receive the bounce, mean a compromise?
I'm open to the possibility that it does - but I'm not seeing it.
EDIT: another possible area of concern is that you can get Google to visit an address just by sending mail to johnsmith@gmail.com and calling the link an image. But can't you already do the same thing with the Google bot by including a link causing it to probably visit? This could be more instantaneous and hide the actual referring source of the visit behind an email, but I don't really see how this can be used for anything. For example if an extremely malformed server performs actions on the basis of a simple http GET then I guess you could craft that command into an image url, send it to any gmail address, and then Google will do your dirty work of actually visiting that link. But, really, is this a vector that is dangerous for anything? Don't URL's already get random Google traffic?
Google could technically do a similarity measure between images coming from similar links (or similarly worded emails) and then provide the cached version. But then advertisers could hide random information in the image (steganography), making two visually similar looking images but with dissimilar enough content, that Google will be have to up the ante. And so on and so forth.
But you are spot on them being "willfully dishonest". The way I look at it, they are at this point trying to push the barrier and see where users will protest enough that they need to roll-back.
> Absurdly wrong, marketers already use a unique image URL for each email recipient, and Google has no way to know that all of those point to the same image.
wrong.
you can of course do simple image processing and identify similar images. if the marketers only change the name(url) of the file and not the content one-bit, you can trivially compare the hash of the file... even if the marketers change content, assuming the marketer sent the image %90 same and 10% customized per person, you can borrow techniques from image compression domain to compress this humongous data very efficiently.
And how do you get the image to compare it? By requesting it, which means you have to ask for it from a server, thus identifying that the image has been loaded.
"In some cases, senders may be able to know whether an individual has opened a message with unique image links" suggests Google (at least for now) fetches the images upon opening of the email.
A few years back I shared office space with an "email marketer", and even then he would tell me that each image URL contained a hash as part of the file name. This hash is linked to the email address. How would they be able to prevent that? Even if Google pre-fetches it, it still would (possibly harmfully) confirm they had saw it. Even if they didn't.
> and Google has no way to know that all of those point to the same image.
They could do content hash-based caching rather than URL-based caching. It would be more private, as the email senders would have to generate a unique image for each recipient.
I think any email marketers who want to get around this easily can. Just change robots.txt to not give permission to Google fetching the images. Copyright will laws will prevent them from wilfully ignoring that, presumably.
They're just acting as an email client. Alice sends email to Bob, Bob is granted rights to fetch and view images. Bob uses gmail, so he passes the rights onto google to do part of that serverside.
He certainly passed on a significant portion of the rights or that server wouldn't be authorized to receive and permanently store the emails in the first place.
Do you think copyright law disallows running your desktop in the cloud?
I came here to say basically the same thing, so I'm going to chime in in support of what you're saying. If I'm a marketer and I send an email with a link to the image, and Google caches it in order to resend it for their own purposes (even if that's to shield their users from spam), how is that not a copyright violation? In this case, caching is no different than copying; and the kind of caching Google is doing in this instance is different than the caching an individual does via his browser, since the individual downloaded the image in the original instance.
I see where you're coming from, and IANAL etc, but this surely must be a solved problem? For at least the last 15 years (longer?) we've had web mail where mail you send doesn't go directly to the user but via some other servers. If there is an actual issue here it's going to be a hell of a legal battle.
Absurdly wrong, marketers already use a unique image URL for each email recipient, and Google has no way to know that all of those point to the same image. So they won't see "a single request from Google", they'll see one request from Google per successful delivery to an inbox.
Now, an open question is if Google will make that request when the email is actually opened, which would allow marketers to determine if and when the email was read by the user, or if Google will make the request as soon as the email is received. The latter would enhance users' privacy at the cost of bandwidth for Google, but early tests indicate that they don't actually do that, waiting for the user to click the email to make the request.
I'd like to add that there's no possibility the Gmail team is stupid enough to not have considered this. They must know full well what they're doing, and marketing this as a privacy enhancement when it's actually detrimental to privacy is willfully dishonest.