31–40 of 81 posts
I often think the best way to defeat email open tracking would be for a mainstream email client to prefetch every image when a non-spam email is received and cache it for 72 hours or so. Every email gets flagged as “opened,” so the flag is meaningless, and recipients can see the images without triggering a tracker.
Too bad CORS doesn't fix this. It would be awesome to be able to sandbox a page completely.
Content-Security-Policy: img-src 'self';Probably any unknown element attribute pair should be stripped by default. And that's still not considering different "namespaces" such as SVG and MathML that you need to be careful with.
Earlier quoted context omitted.
I worked for a short time for an American company. They had periodic phishing test from Mitnick. The links in those emails was not to be clicked as it would trigger a mandatory training. The emails also had a header saying they were a phishing test, so I deleted all those emails in a filter. The company also ran a mail filter called Baracuda or something similar that followed links in emails to see if they were malic…
Did everyone get flagged then thanks to Barracuda? You’d think they’d realize there’s a problem if there’s a 100% fail rate. Edit: also, to be fair, you basically told them you had opted out of the test, so it’s not completely ridiculous for them to ask you to do the training instead.
Earlier quoted context omitted.
Some of the big providers already do this, notably Apple and Gmail: https://www.litmus.com/blog/gmail-prefetching-images
Gmails prefetch is terrible for privacy because it honors http cache headers, which means tracking companies simply use a "no-cache, must-revalidate" header to defeat it.
I often think the best way to defeat email open tracking would be for a mainstream email client to prefetch every image when a non-spam email is received and cache it for 72 hours or so. Every email gets flagged as “opened,” so the flag is meaningless, and recipients can see the images without triggering a tracker.
That is still signal that the email address is valid. I'd prefer something like the server immediately sending a SMTP 550 5.1.1 (unknown recipient error), for anything that's immediately recognized as spam (or marked as spam in the past by the user). That gives no signal at all and might even persuade some scammers to remove your email address from their list.
A better approach is to follow all links always (even to non-existent recipients) if you must play this game.
That reminds me: I should make sure all my mail clients are still set to plain text rendering.
I often think the best way to defeat email open tracking would be for a mainstream email client to prefetch every image when a non-spam email is received and cache it for 72 hours or so. Every email gets flagged as “opened,” so the flag is meaningless, and recipients can see the images without triggering a tracker.
You disclosed this the day roundcube was patched. Isn’t it usual to give us time to deploy updates before disclosing details?!
I often think the best way to defeat email open tracking would be for a mainstream email client to prefetch every image when a non-spam email is received and cache it for 72 hours or so. Every email gets flagged as “opened,” so the flag is meaningless, and recipients can see the images without triggering a tracker.
I made an attempt to enumerate them[1], and whilst I catch this issue with feImage over a decade ago by simply observing that xlink:href attributes can appear anywhere, Roundcube also misses srcset="" and probably other ways, so if the server "prefetched every image" it knew about using the Roundcube algorithm the one in srcset would still act as a beacon.
I feel like the bigger issue is the W3 (nee Google). The new HTML Sanitizer[2] interface does nothing, but some VP is somewhere patting themselves on the back for this. We don't need an object-oriented way to edit HTML, we need the database of changes we want to make.
What I would like to see is the ability to put a that would allow the document to replace requests for url with the embedded data, support what we can, then just turn off networking for things we can't. If networking is enabled, just ignore the pre-cache tags. No mixing means no XSS. Networking disabled means "failures" in the sanitizer is that the page just doesn't "look" right, instead of a leak.
Until then, the HTML4-era solution was a whitelist (instead of trying to blacklist/block things) is best. That's also easier in a lot of ways, but harder to maintain since gmail, outlook, etc are a moving target in _their_ whitelists...
[1]: https://github.com/geocar/firewall.js
[2]: https://developer.mozilla.org/en-US/docs/Web/API/HTML_Saniti...
I often think the best way to defeat email open tracking would be for a mainstream email client to prefetch every image when a non-spam email is received and cache it for 72 hours or so. Every email gets flagged as “opened,” so the flag is meaningless, and recipients can see the images without triggering a tracker.
I think the problem is what is an image? I made an attempt to enumerate them[1], and whilst I catch this issue with feImage over a decade ago by simply observing that xlink:href attributes can appear anywhere, Roundcube also misses srcset="" and probably other ways, so if the server "prefetched every image" it knew about using the Roundcube algorithm the one in srcset would still act as a beacon. I feel like the bigg…