←back to thread

72 points _vvhw | 4 comments | | HN request time: 0.2s | source
1. floatboth ◴[] No.21070425[source]
Wait, how exactly does iframe sandbox not solve everything? Emails definitely should be shown in them, even with client side decryption, you can create an iframe from a data: URI. iframe sandbox is the strongest sandbox possible. Unique origin, no JS execution…
replies(3): >>21070498 #>>21071390 #>>21073009 #
2. _vvhw ◴[] No.21070498[source]
I used to think the same, except iframe sandboxes:

1. Don't resize dynamically to fit the email content, not unless you enable unique origin JS execution and do message passing to the parent window. But if you do that then you open the door to crypto-mining, tracking, spectre variants, and browser zero-days.

2. Don't play well with keyboard shortcuts since they steal keyboard events from the parent window when focused. Proxying keyboard events to the parent is even more dangerous since an attacker could then spoof keyboard events to control the parent.

3. Don't let you whitelist allowed HTML tags, attributes and CSS properties, which means there's no way to block email tracking.

And that's just for viewing email content. How would you sanitize and whitelist unsafe email content when replying/forwarding?

DOMPurify combined with CSP is safer and stricter. And if you wanted to, there's nothing to prevent you from putting the result in a sandboxed iframe once sanitized anyway. But it needs to be sanitized.

3. jcranmer ◴[] No.21071390[source]
What you need is something like https://bugzilla.mozilla.org/show_bug.cgi?id=80713 that lets you make the <iframe> act more like an autosizing <div> than a fixed-size frame. https://github.com/w3c/csswg-drafts/issues/1771 is a suggestion for adding this sizing into CSS, but there's concern about the ability to leak information through the size of the container.
4. ◴[] No.21073009[source]