example: send an image to Mary and tell her not to send it to anyone else. She inevitably sends it to someone else, but the image magically changes to another image that says a message, maybe it says "DAMN IT MARY, I SAID DON'T SEND IT TO ANYONE ELSE!"
Fun hack! I feel like there should be some clever practical applications but I'm drawing a blank.
I wouldn't want to maintain any clever practical applications that break any time one of these web services subtly change the way they mangle HTML.
You could maybe make some sort of email analytics where you could guess the email client of the readers. Use a different background 1x1 gif image for each one then check your logs.
Maybe - this solution would help in figuring out who the leakers are!
If it worked on all email clients.
This article is full of examples that are obviously bugs. And worst - it's all neither documented nor standardised.
Sure, html email is annoying, but let there be a flag or option for the user to decide to display it or not.
What do you mean? That's the point of iframe, so the email content cannot break email. We have object urls, and it's really not super hard to put emails into a different url to simply iframe src="" it.
Also, I am not saying that this was the only way to mitigate this risk (Apple Mail seems to pretty much use an iframe in their client, whereas other email clients still munge the HTML (Outlook, Eudora, Lotus, etc). But it is the way that many did choose, and I can understand why whether or not I agree with how they did it.
The child can reach up to the parent via JS, too, but you'd want to sanitize any JS in an email anyways.
But the rub is always the propensity for users to forward on those same emails. If they do, then the second recipient gets control of the first recipient's account, and that's rarely the intention of the first recipient/forwarder.
I haven't had a chance to dive in enough, but I wonder if a technique like this could effectively swap tokenized links with generic links (even if you're just swapping 'display' rules) when a message is forwarded. You might have to use different message style/markup output depending on which service you're sending the message to, but my read of this article is that it's not a ridiculous thought.
When the sandbox attribute is present, and it will:
* treat the content as being from a unique origin
* block form submission
* block script execution
* disable APIs
* prevent links from targeting other browsing contexts
* prevent content from using plugins (through <embed>, <object>, <applet>, or other)
* prevent the content to navigate its top-level browsing context
* block automatically triggered features (such as automatically playing a video or automatically focusing a form control)
You could use an injected JS (postMessage with the iframe window height) and update the iframe height from the outside. And for the content you should just strip any script tags so you can safely allow scripting.
You should strip script tags in any case so that someone cannot use an API call which outputs raw comments as a delivery vector.
Also, you're putting users without sandbox attribute support on risk of being exploited... so you'd have to switch between two paths for display.
An evil part of me considers that a feature, not a bug.
And as for stripping script tags, I'm always reminded of this story:
I love things that exploit the oddities of the landscape to do artsy/funky things; far more interesting than finding yet another way to trick someone into installing a password stealer.
Make a link per identifiable client, show only the one for the current client, and give each link a post/get parameter identifying the client. Quite easy to do, but a lot of work to have broad client support.
Tada! I now know you read your email on your [obscure and bugged client], which is susceptible to [this and that exploit].