4 ms·

I just tested out your iOS client on my iPhone with https://www.emailprivacytester.com https://www.emailprivacytester.com - You failed the "CSS content", "Image

I just tested out your iOS client on my iPhone with https://www.emailprivacytester.com https://www.emailprivacytester.com - You failed the "CSS content", "Image tag" and "CSS background-image" tests. Although you appear to be proxying requests as the IPs were in Amazons cloud. I don't see any option to disable remote resource loading, even though it should default to off. If I use your client, anybody who emails me will know if and when I read their email, and also the fact that I was using an iPhone whilst doing it (you keep the User-Agent). I think that's bad.

pimterry 6y ago
They actually have a tracker blocker as a core feature: https://missiveapp.com/features/auto-block-read-trackers 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.
- rafBM 6y ago
  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.
  - JoshTriplett 6y ago
    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.
    - calvinmorrison 6y ago
      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.
  - firstpartyt 6y ago
    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.
- d110af5ccf 6y ago
  > 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.
- mike-cardwell 6y ago
  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.

pimterry 6y ago

They actually have a tracker blocker as a core feature: https://missiveapp.com/features/auto-block-read-trackers 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.

rafBM 6y ago
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.
- JoshTriplett 6y ago
  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.
  - calvinmorrison 6y ago
    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.
- firstpartyt 6y ago
  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.
d110af5ccf 6y ago
> 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.
mike-cardwell 6y ago
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.