Oh, but gmail also reveals to tracking services (i.e. virtual deliverability manager from aws ses) that you opened an email even when you disabled loading images.
No reasonable person would ever think that Google preserves their privacy. Perhaps Google preserves it enough so they can sell whatever information they're hiding, but that's about it.
It does, and as usual, Apple catched up a decade later. It was called Google Image Proxy for GMail (or something like that) when it was released, much to the chagrin of email marketers.
Since 2013, marketers haven’t known WHERE their readers are simply from users opening an email in Gmail.
But today, marketers don’t know IF their readers even open an email if users use Apple Mail.
Partial quote from the second article: “The issue is that the single most useful piece of information a sender gets from you[/the proxy] loading the image is that/when you read the email. And this is not mitigated at all by this system [b/c] when you open an email the server will see a request. Mix that with the ubiquitous uniquely-named images … and you get read notifications.”
(I want _neither_ to leak my IP _nor_ to have “Read Receipts” enabled when I get spam or whatever.)
You can literally ask any SMTP MX server if an email address is valid, and it'll tell you yes/no. Emails send to invalid addresses are in general not silently discarded.
> I've noticed that moving the goalposts is extremely prevalent on HN, which makes for pretty frustrating conversations (or just reading). And then sometimes it's a tag team[…]
Politicians are masters of this tactic of deflection. The nastier, the better they are at it.
Calling it out is the best one can do without getting trapped in a cycle of low-effort premises and high-effort responses.
Although, as usual in HN, the premises come from different accounts, so both are valid. And it probably reveals valid addresses when the image URL is unique for each email.
Definitely happens a lot on HN, but I think that's just the nature of a mix of different opinions. Better IMHO to just treat them as individual arguments and reply accordingly
I'm really not (honestly!) trying to invalidate anyone's point or win any argument - my post is more of a question-in-disguise: the GP post I was replying to concerns message-read tracking; whereas my post invokes the entirely separate matter of external actors being able to determine the validity or existence of a gmail address.
I'm not moving the goalposts; you guys are talking about the NFL game's goalposts; I'm talking about the FIFA world cup game goalposts.
> I'm not moving the goalposts; you guys are talking about the NFL game's goalposts; I'm talking about the FIFA world cup game goalposts.
Analogously, the issue would be out of bounds then, as the issues are distinct, and so a failure mode that discloses the existence of an email account is not a failure you can lay at the feet of any particular provider of email accounts, but is partly an implementation detail of how different email providers respond to emails to nonexistent addresses. That particular failure (disclosure of the existence of an email address) and any potential solution is considered out of the scope of the problem in the thread (disclosure of the opening of an HTML email due to loading tracking pixels).
Obviously if you're reading gmail on the web or in the official phone app, then of course every click is observable.
But you can read gmail in thunderbird or any other email client, and in that case gmail still doesn't know anything more than that your client performed a sync, which it might be doing periodically at all times and so isn't meaningful.
What platform (web, android, ios) did you test on, and how did you test? I used emailprivacytester.com on a few email services and gmail wasn't susceptible to any of the attacks.
I tested it by sending an email using ses and virtual deliverability manager to my gmail account which is configured to not load images automatically. Then I observed how the open is registered in the virtual deliverability manager’s dashboard.
