From bf5a9500d9dbbf27de88cf6cc66dbbd309f4a675 Mon Sep 17 00:00:00 2001 From: Michael Zhang Date: Thu, 17 Jun 2021 15:22:12 -0500 Subject: [PATCH] rage --- content/posts/2021-06-17-tracking-links.md | 106 +++++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 content/posts/2021-06-17-tracking-links.md diff --git a/content/posts/2021-06-17-tracking-links.md b/content/posts/2021-06-17-tracking-links.md new file mode 100644 index 0000000..5b1b2b2 --- /dev/null +++ b/content/posts/2021-06-17-tracking-links.md @@ -0,0 +1,106 @@ ++++ +title = "email tracking links" +date = 2021-06-17 +draft = true + +[taxonomies] +tags = ["email", "computers", "things-that-are-bad", "privacy"] ++++ + +You probably get emails every day, and spend a lot of time reading them. And +whenever someone performs an action or does something in vast quantities, you +_bet_ the data people have figured out a way to capitalize on it. For many +years consumer privacy has basically gone unnoticed, and invasive tracking has +grown [viral][1]. + +Arguably, if you are someone who runs a business off of writing periodic +newsletters that are distributed via email, you might want some statistics on +how your newsletter is doing. Traditionally, this is achieved **actively** +through some kind of survey with some kind of incentive, like "tell us how +we're doing for a chance to win a water bottle" or something of the likes. + +Now emails are typically imbued with **passive** trackers either in the form of +[tracking pixels][3] (which informs the sender when the receipient opens the +email) and [tracking links][4] (which informs the sender when AND what links +receipients click). Tracking pixels are usually less relevant these days since +many web-based email clients will ask before loading images, and clients run by +mail servers with large amounts of users like Gmail ([and soon iOS][5]) may +proxy the pixels ahead of time so the senders only see the IPs and metadata of +the server. + +Tracking links, on the other hand, have become much more invasive, to the point +where it's impossible to avoid being tracked. You see it all over the web: +whenever you open a link, there's almost always some kind of `?ref=xxxxx` code +stuck onto the end that identifies _your_ particular instance of it. This way, +if you share the link with a friend, they just used the same code, and your +connection to your friend is traced by the website owner. + +> If this creeps you out, consider using a browser extension like +> [ClearURLs][6], which recognizes these URL parameters that do nothing but +> feed information to the website owners and removes it for you. +> +> TODO: talk about `Referer`? + +But email tracking links are even worse: they abuse redirects to obfuscate the +original URL entirely. For instance, you'd get links in your email that look +like: + +``` +https://some.mail.host/lWOrjb9FXYgMDS0DADOsxAZEFPB99gHzmRQTe6OHBws= +``` + +Where does it go? Wikipedia? Piratebay? There's only one way to find out: by +making a request to that server, thereby giving up information about the time, +place, client, OS, and all sorts of other information that greedy data +collection companies are waiting to snatch up. + +Of course, regular users notice nothing: these links are usually hidden behind +buttons, text, or even the original URL itself. Once they click it, the website +silently logs all the data it receives about the user, and then redirects the +user to the original destination. + +The senders usually aren't at fault either. Sending email is tricky, with all +the infrastructure set up to block out spam, so the majority of people who send +bulk mail (newsletters, websites that need to confirm your email, etc.) all go +through companies that handle this for them. Of course, being the middlemen who +actually get the mail out the door, they're free to replace the links with +whatever they want, and many of these companies advertise it as a feature to +get more "insight" into how your emails are doing. + +Even worse, the original senders aren't the only ones getting the info, either. +These middlemen companies could hold on to the data and there's no saying they +can't use it for other purposes or sell it. + +Unfortunately, sending email isn't really going to get any easier, partly +because of the way email fundamentally works: without all of the security +infrastructure in place, running your own email server could easily lead to +abuse. Most people (justifiably) would not go through all that effort +themselves. + +Another possible avenue of thinking is to do what companies did for tracking +pixels, where they would proxy the links, open them when they receive it, and +transparently replace the unfiltered link back into the email. But this raises +its own issues: for example, what if the act of opening the original link +performs some kind of action (e.g. click to subscribe, click to register, +etc.)? Also, this solution only works for email that is not end-to-end +encrypted. For end-to-end encrypted mail providers, there is no way to do this. + +The only real solution here is regulation via either advancement in +privacy-related open standards, or legislative bills. It's clear that without +any kind of regulation, companies will continue to act in the interests of +profit rather than the protection of their customers. + +> Devil's advocate afterthought: should this problem even be solved? Maybe +> there's a benefit to this whole tracking thing. My opinion on this is if you +> _really_ want to develop a community of readers, offer an easy way to give +> feedback (or even go back to the incentive surveys), and if people aren't +> giving feedback, then that itself is a reflection of the state of your +> readers. + +Thanks for reading. + +[1]: https://www.wired.com/story/how-email-open-tracking-quietly-took-over-the-web/ +[3]: https://en.wikipedia.org/wiki/Web_beacon +[4]: https://en.wikipedia.org/wiki/Click_tracking +[5]: https://www.apple.com/newsroom/2021/06/apple-advances-its-privacy-leadership-with-ios-15-ipados-15-macos-monterey-and-watchos-8 +[6]: https://gitlab.com/KevinRoebert/ClearUrls