Hacker News Reader

Comment by pimterry | Hacker News Reader

They actually have a tracker blocker as a core feature: https://missiveapp.com/features/auto-block-read-trackers

Their approach works by blocking trackers specifically, similar to an ad blocker, rather than blocking all external resources completely. Hey.com take a similar approach I think. Although the images from that test service are allowed, trackers from all the popular email tracking services will be blocked (in theory at least).

It's not going to be 100% effective of course, but I suspect it's very close to that for most real-world email tracking, and the user experience is dramatically better (i.e. you can read emails that include images with no hassle and avoid being tracked all at the same time). And they do proxy all images through their own servers, so any missed trackers still get only limited info.

View on HN

CTO at Missive here. Thanks @pimterry for summing it up nicely. A note about the User-Agent: we do not forward it to the origin server as @mike-cardwell said. Our proxy always passes an iPhone User-Agent as a “lowest common denominator” to ensure CDNs won’t serve WebP images.

Blocking "known" trackers is always going to be a cat-and-mouse game, though. Blocking all 1x1 images and similar would help as well, if you're doing that. But I'd still be concerned about spam that's using remote images for "this email address exists and a human reads it" verification. I'd also be concerned about read-receipt services, especially those that might support self-hosting rather than using a central service that you can easily identify.

By the time you check if the image is 1x1, you've already downloaded it.

The alternative expensive solution is to download EVERY image a user receives and store it indefinitely. That way the trackers aren't any more useful than "was the email received".

In short, I'd love a better solution to " load all images " vs " load no images " but that's where I ended up talking to our frontend engineer at Fastmail. Obviously he had thought about the problem a lot more then me (I do operations not any frontend) and there's no easy solution.

Hi, I work in the tracking space, specifically first party trackers. This approach is not effective.

Here are the reasons: 1) rarely care what client the user views the email in; 2) any request to the server is enough information to identify the user, email, and open/received; 3) a tracking pixel is an antiquated form of tracking; 4) the list provided doesn’t include some big names (FB for one).

The only effective way to stop the tracking, that I’m aware of, is is to cache the result of the request. Even that doesn’t stop newer techniques. Instead what you need to do is to cache the request and then apply a model to determine if a similar request leads to a similar result for other users and serve that from the cache. To the best of my knowledge no one has built that yet, and could probably be circumvented.

> rather than blocking all external resources completely

> And they do proxy all images through their own servers, so any missed trackers still get only limited info.

IMO either all external resources should be completely blocked until explicitly requested or alternatively all should be immediately fetched and cached by the server the instant it receives the email. The second option does consume more resources for the server operator but it provides significantly better privacy for users by rendering trackers completely useless.

It sounds like their implementation prevents some wide-spread tracking, but that it doesn't prevent any targetted tracking. I know of at least one person that has suffered from targetting tracking of this variety, so I will say that this is still a bad setup for anybody that cares about privacy.

The only good solution is to automatically fetch all remote content for all incoming email as soon as it is received, regardless of whether or not the message is read.

Reply on news.ycombinator.com