Rendering untrusted HTML email, safely (2021)
11 points by juliethefoxcoon
11 points by juliethefoxcoon
I feel like either blocking or proxying remote images is table stakes for modern email clients. tracking pixels are everywhere and sending notifications every time you open an email is really creepy. I think blocking could be achieved with adding img-src and friends to CSP?
Proxying remote images won't block "has opened" tracking pixels - they'll obscure your IP and user agent, but the fact that the image was proxied is enough to tell that it was opened.
I should probably do a write-up on this at some point, but always interesting to hear how others handle this issue.
We recently moved from allow-same-origin to an opaque origin with srcdoc due to limitations with Webkit and disallowing scripts. So now we're doing sanitization, then an opaque origin iframe, with our own small script to communicate above over a message channel for things like size, focus, and keybinds.
What an odd way to deal with untrusted HTML... I think you want both, sanitization and a restricted rendering content (eg serving the content with a CSP sandbox flag)
Yeah, I found their logic for not using html sanitization libraries to be.. shaky.
HTML sanitization libraries often rely on parsing HTML with regex
Pretty much all of the html santization libraries I can think of(DOMpurify, for one) don't really use regex and use actual parsers