If it’s prefetched, it doesn’t matter that you reveal that it’s been “opened,” as that doesn’t reveal anything about the recipient’s behavior, other than that the email was processed by the email server.
If by prefetch you mean the server grabs the images ahead of time vs the client, this does not happen, at least on amy major modern platform that I know of. They will cache once a client has opened, but unique URLs per recipient are how they track the open rates.
Cool, all of your images are getting fetched by the server as it receives and processes the emails. You have 100% open rate on all emails to that domain within 3 minutes of send.
What do you know about the user and their behavior? Nothing. The prefetch is not tied to their actions, therefore you cannot learn anything about their actions.
Personally speaking, I’ve never been a fan of this method because to the hosting web server it was still fetched. That might confirm that an email address exists or (mistakenly) confirm that the user did in fact follow the link (or load the resource).
I have ad and tracking blocked like crazy (using DNS) so I can’t follow most links in emails anyway. External assets aren’t loaded either, but this method basically circumvents that (which I hate).
This wouldn’t help, would it? How would you prefetch and cache:
site.com/base64u-to-niceware-word-array/image.gif
? It would look like a normal image URL in any article, but actually represent data.
Note: “niceware” is a way to convert binary or text data into a set of words like “cow-heart-running-something-etc”.
If it’s prefetched, it doesn’t matter that you reveal that it’s been “opened,” as that doesn’t reveal anything about the recipient’s behavior, other than that the email was processed by the email server.
If by prefetch you mean the server grabs the images ahead of time vs the client, this does not happen, at least on amy major modern platform that I know of. They will cache once a client has opened, but unique URLs per recipient are how they track the open rates.
Apple’s Mail Privacy Protection does this. See https://www.reddit.com/r/privacy/comments/pt9ycv/apples_mail_privacy_protection/ for a post from three years ago talking about it.
I don’t know if any other major providers take this approach but Apple / iCloud is definitely one of them.
But the path changes with every new data element. It’s never the same, so every “prefetch” is a whole new image in the system’s eyes.
Even with a unique link, if the behavior is that as soon as the email server receives it, it’s prefetched, what does that reveal about the user?
Server or client, every supposed prefetch would be unique. If I trick an LLM client into grabbing:
site.com/random-words-of-data/image.gif
Then:
site.com/more-random-data/image.gif
Those are two separate images to the cache engine. As the data refreshes, the URL changes, forcing a new grab each time.
For email, marketers do this by using a unique image URL for every recipient.
Cool, all of your images are getting fetched by the server as it receives and processes the emails. You have 100% open rate on all emails to that domain within 3 minutes of send.
What do you know about the user and their behavior? Nothing. The prefetch is not tied to their actions, therefore you cannot learn anything about their actions.
This post isn’t about email open rates, it’s about data exfiltration. But for email speficially, show me major providers that prefetch by default.
For data exfiltration, you’re right - this doesn’t help.
Personally speaking, I’ve never been a fan of this method because to the hosting web server it was still fetched. That might confirm that an email address exists or (mistakenly) confirm that the user did in fact follow the link (or load the resource).
I have ad and tracking blocked like crazy (using DNS) so I can’t follow most links in emails anyway. External assets aren’t loaded either, but this method basically circumvents that (which I hate).
an email for a receiver that doesn’t exist, more often than not, goes back to the sender after e.g. 72h. That’s by design.