Live data from Hacker News

Privacy implications of email tracking [pdf]

senglehardt.com

41–50 of 74 posts

Re: Privacy implications of email tracking [pdf]

#41
post #29

This is why I still love and use mutt (NeoMutt, technically) even after all these years. I occasionally do fire up Thunderbird but only for those extremely rare cases where I actually do need to be able to read an HTML e-mail.

Surely there's a way to pipe an html email to $BROWSER from [neo]mutt?

Put this in your ~/.mailcap (all on one line)

text/html; elinks -no-connect -dump -dump-charset UTF-8 -dump-width 140 -default-mime-type text/html %s; needsterminal; copiousoutput;

Re: Privacy implications of email tracking [pdf]

#42

Folks, every email client and service has an option to not auto-download images. Plenty have it on by default (MS Outlook, notably). All of them ought to (IMO), but it's better than nothing. I warmly recommend you turn it on. There is no need to switch to text-only email clients just because of tracking.

That doesn't work for all clients. It usually will, but I have seen some make HEAD requests for inline images to try read the expected download size to display this to the user - if this happens then the server obviously gets the full URL including tracking codes so has a fair idea the mail hit a valid mailbox.

Re: Privacy implications of email tracking [pdf]

#43

We still have a serious problem with mail client behavior. There is so much that clients could still do to add basic security, even though E-mail protocols are terrible. For instance, why do we not see in every client a big warning at the top saying something like: “NOTE: YOU HAVE NEVER RECEIVED E-MAIL FROM THIS INTERNET LOCATION BEFORE.”? Heck, such messages should even be auto-quarantined to specific folders. It wo…

Have never really thought about this, but it's a great point. At the very least, mail clients should have options to enable this kind of behavior.

Re: Privacy implications of email tracking [pdf]

#44

We still have a serious problem with mail client behavior. There is so much that clients could still do to add basic security, even though E-mail protocols are terrible. For instance, why do we not see in every client a big warning at the top saying something like: “NOTE: YOU HAVE NEVER RECEIVED E-MAIL FROM THIS INTERNET LOCATION BEFORE.”? Heck, such messages should even be auto-quarantined to specific folders. It wo…

> For instance, why do we not see in every client a big warning at the top saying something like: “NOTE: YOU HAVE NEVER RECEIVED E-MAIL FROM THIS INTERNET LOCATION BEFORE.”?

Because that is way too dangerous a policy. Recently, I moved, and in creating online accounts for online bill pay, I got confirmation emails from each of my utilities. Saying that they're spam just because you've never received email from them would cause most people to be unable to find these confirmation messages.

> And, why by default do they insist on making everything look “simple” and “clean” at the expense of helping users to do even the most basic validation? They show senders as short names like “Facebook” when CLEARLY the message is coming from facebook.spammer.com or whatever when you do even the slightest digging into the original message.

Uh, my email client doesn't do that. If the email address isn't priorly known, it shows the email address instead of the display name.

> Why are “rules” so complex, since damn near everybody needs them for basic sanity? There ought to be a button in every message saying something like “Mark Every Future Message From This Sender as Junk”, and similar short-cuts.

Most spammers don't reuse the same email addresses. You end up with a lot of useless rules. Bayesian spam filtering is much more effective, for example, and requires very little user action.

Re: Privacy implications of email tracking [pdf]

#45
post #12

Doesn't Google immediately download any external images/assets in an email and cache them to prevent exactly this?

Gmail's image proxying actually won't help much with this style of tracking. In the paper we found email addresses (or hashes of them) leaking to third parties via a query string parameter in the request URL. So the proxied URL still contains your email address and the third parties can still learn you opened and read the email. As another commenter mentions, we found these requests to occur the moment you first open the email in the Gmail web interface. Since the request URL is unique to you, it can still be used to serve you targeted content. See: https://web.archive.org/web/20170922213846/https://support.l...

Actually I suspect image proxying will also interfere with request blockers like ABP or uBlock Origin, which may have otherwise blocked all requests to that third-party domain.

Re: Privacy implications of email tracking [pdf]

#46
post #40
post #33

Earlier quoted context omitted.

The gmail app on the iPhone does not

Even if it did block them in the app, we have no way of knowing if tracking pixels links are followed by Google when it scans/sorts you mail server-side.

You could test the principle by including a graphic in an email, send it to an account with images turned off, and then see if any HTTP requests come in, perhaps.

Re: Privacy implications of email tracking [pdf]

#47
post #38

https://gmelius.com seems to block email trackers in Gmail.

Similarly, I've used the PixelBlock Chrome Extension and it works well. Very much a "set it and forget it" kind of tool.

I'm surprised there isn't an equivalent for Firefox. At least no obvious one I can find so quickly.

Re: Privacy implications of email tracking [pdf]

#49
post #12

Doesn't Google immediately download any external images/assets in an email and cache them to prevent exactly this?

Gmail's image proxying actually won't help much with this style of tracking. In the paper we found email addresses (or hashes of them) leaking to third parties via a query string parameter in the request URL. So the proxied URL still contains your email address and the third parties can still learn you opened and read the email. As another commenter mentions, we found these requests to occur the moment you first open…

This is particularly annoying, because if they just cached the image immediately upon receiving the e-mail, there would be no privacy impact AND you would get to see the image. (Yes, it might still send your e-mail address to third parties, but someone who has your e-mail address is free to send it to anyone they want without your help; there is no way to stop that.)

I guess we didn't need further evidence that Google cares more about third party marketers than users' privacy.

Re: Privacy implications of email tracking [pdf]

#50

Folks, every email client and service has an option to not auto-download images. Plenty have it on by default (MS Outlook, notably). All of them ought to (IMO), but it's better than nothing. I warmly recommend you turn it on. There is no need to switch to text-only email clients just because of tracking.

That doesn't work for all clients. It usually will, but I have seen some make HEAD requests for inline images to try read the expected download size to display this to the user - if this happens then the server obviously gets the full URL including tracking codes so has a fair idea the mail hit a valid mailbox.

Similarly, Gmail screws up its UX (as usual). If you ever make the mistake of clicking "Always display images from ", there is no turning back for that sender, as far as I can see at least. No "block images from this sender" button, no list in settings of all approved email senders that you can change your mind about, nothing.

The only option at that point is using the PixelBlock extension:

https://chrome.google.com/webstore/detail/pixelblock/jmpmfcj...

Post reply on HN