Potential there for a DOS attack isn't there?

"hey look this server blindly downloads images".. Sends a million emails with a bunch of tiffs.

I don't really see this as a major problem. Just grab a reasonable number of bytes and disconnect. If a user does end up wanting to view the full TIFF, just say "this server is probably stealing your private information and you will also go over your storage quota by loading this image". If the user is OK with that, then download the image again.

99% of the time, the image is just a company logo in someone's email signature and takes essentially zero storage space or bandwidth to retrieve at receive time. For the special cases, just warn the user about the implications of downloading the image, and go do it if they ask.

This is basically the plan. There are some other concerns, notably bandwidth/space and, given it's untrusted input, thinking through all the other ways it could be abused. There will certainly be a byte limit.

Not only would the server need to download the image, it would need to store it in perpetuity because the server would then be responsible for serving them to you (if your client makes any direct request you'll leak when you viewed the email, the trackers don't only track the first request). This is not something that is easy to implement.

A Google security engineer confirmed to me that Google toyed with this idea but ultimately decided not to do it due to various partners not wishing to lose the ability to perform read receipt tracking.

There are no unsolved technical reasons preventing this from being enabled in Gmail, only political reasons.

Huh, I was under the impression that Google started doing this years ago and didn't stop, and even tied it into spam analysis... Did your contact elaborate on the extent of their "toying" and any timelines? I guess I'll have to revisit some of my arguments -- a few years ago I successfully fought against adding a tracking pixel to an email template on the basis of read receipt hits not being valid hits a lot of the time (let alone never getting a hit despite being read due to images being off) due to providers like gmail pre-loading them (sometimes more than once at random times), so we should just use click-through metrics on links when the request comes with an authentication cookie.

Google proxies and caches all external assets in emails through their own servers to hide your IP address, but they only do this on-read instead of on-delivery, which enables read receipt tracking.

> Yet they still don't support read receipt privacy when you enable loading images by default for unencrypted email.

I think those two things put together create a very, very niche use case. If I'm concerned about privacy, I don't turn on loading images by default. I'd be really curious to see the overlap in users who do.

> If I'm concerned about privacy, I don't turn on loading images by default

The point is that you shouldn't have to do this, and can be afforded the same privacy while improving your user experience.

It can’t though. Whenever the image is loaded, by default or otherwise, the image itself can act as a read receipt. That’s how most email services track opens. If the server downloads the image for you, then the server has to store the image to prevent you from accessing it directly from the host. That creates cache time discussions, storage quote discussions, etc.

Even if the image itself is proxied through a CDN, the time the image is accessed is still exposed.

> That creates cache time discussions, storage quote discussions, etc.

why cache time discussions, after initial download there is no need to download it again, email is not the browser, there is no expectation that the image in email will be the actual at the time of opening, the expectation is that the image is actual at the time of sending. and for storage you can use hash to not store duplicates, and probably save bandwith with optimization.

True. I was mostly thinking of Proton as a browser based service. Browser cache would cover the same case.

They do have the Bridge now to use it on the desktop.

> Even if the image itself is proxied through a CDN, the time the image is accessed is still exposed.

So have the mail server download the image immediately upon getting the message, so that the timestamps (and boolean of being accessed) means nothing?

plus those who "need" to embed visible images (e.g. marketing insisting on the company logo in the footer) could use svg data uris now, so they're not really in conflict with blocking 3rd part content.

Doing some sort of image proxy download in a safe and efficient way (which is not entirely trivial) is certainly part of the plan.