We did our homework on the browser security model; content in iframes (with sandboxing attributes) shouldn’t be able to get login cookies/etc from the parent page. This is load-bearing for advertisements not stealing everything, so we do expect browsers to treat weaknesses in this as real security issues and fix them. When post HTML is retrieved through the API, you have to do some assembly to put the iframes in, so third party clients can’t be insecurely surprised by it.
As for whether sandboxed frames can crash the outer page or make the outer page slow, eg by doing into an infinite loop or running out of memory, the story is a bit more complicated (depends on browser, browser heuristics, and amount of system RAM); we decided it’s okay as long as it’s limited to an embed in a post crashing its own post page (as opposed to the front page or a link preview).
Most dangers I would associate with “inject arbitrary JS” are not possible here because of the sandboxing by the browser.
e.g. steal cookies, act on behalf of user, change UI that users trusts, …
Authors can write HTML and JavaScript that runs in a sandboxed iframe right in the document
If you look in the codebase you’ll find what amounts to <iframe sandbox="allow-scripts" srcdoc="Your arbitrary HTML here" />.
I can think of some things are definitely still possible:
phishing: trick you into thinking the iframe is part of LessWrong. e.g. trick you into thinking it’s Manifold Embed and asking you to login
tracking: like on any website; it can’t do stuff that it couldn’t also do on some personal website
From what I can see, as long as it’s not paired with allow-same-origin it should be safe enough. My thinking was more along the lines of what happens if e,g. there’s an exploit or such. It’s just not the kind of thing that I expect I need to be wary of from a LW post, that it may execute random unvetted code in my browser.
Yes, we spent a while investigating this and thinking about the security risks. Sandboxes srcdoc iframes effectively have no origin, so in theory ought to be safe, but do sometimes end up running within the same process (though this is also true of remote-origin iframes; the heuristics here are browser-specific and complicated). Effectively, this is a risk if someone discovers a vulnerability that allows breaking out of that security boundary, which would be a pretty big deal as far as browser exploits go.
We thought for a while about it. We currently think the way we are doing iFrames is not a big (additional) security risk beyond what we are already doing. It’s a kind of tricky question though and requires thinking about how much the Chrome/Safari/Firefox teams will prioritize security in iFrame sandboxes this way.
Everyone is going on about the LLM block, meanwhile I’m like “isn’t letting users inject arbitrary JS in their post kinda dangerous?”.
We did our homework on the browser security model; content in iframes (with sandboxing attributes) shouldn’t be able to get login cookies/etc from the parent page. This is load-bearing for advertisements not stealing everything, so we do expect browsers to treat weaknesses in this as real security issues and fix them. When post HTML is retrieved through the API, you have to do some assembly to put the iframes in, so third party clients can’t be insecurely surprised by it.
As for whether sandboxed frames can crash the outer page or make the outer page slow, eg by doing into an infinite loop or running out of memory, the story is a bit more complicated (depends on browser, browser heuristics, and amount of system RAM); we decided it’s okay as long as it’s limited to an embed in a post crashing its own post page (as opposed to the front page or a link preview).
What dangers are you thinking of?
Most dangers I would associate with “inject arbitrary JS” are not possible here because of the sandboxing by the browser. e.g. steal cookies, act on behalf of user, change UI that users trusts, …
If you look in the codebase you’ll find what amounts to
<iframe sandbox="allow-scripts" srcdoc="Your arbitrary HTML here" />.I can think of some things are definitely still possible:
phishing: trick you into thinking the iframe is part of LessWrong. e.g. trick you into thinking it’s Manifold Embed and asking you to login
tracking: like on any website; it can’t do stuff that it couldn’t also do on some personal website
From what I can see, as long as it’s not paired with allow-same-origin it should be safe enough. My thinking was more along the lines of what happens if e,g. there’s an exploit or such. It’s just not the kind of thing that I expect I need to be wary of from a LW post, that it may execute random unvetted code in my browser.
Yes, we spent a while investigating this and thinking about the security risks. Sandboxes srcdoc iframes effectively have no origin, so in theory ought to be safe, but do sometimes end up running within the same process (though this is also true of remote-origin iframes; the heuristics here are browser-specific and complicated). Effectively, this is a risk if someone discovers a vulnerability that allows breaking out of that security boundary, which would be a pretty big deal as far as browser exploits go.
We thought for a while about it. We currently think the way we are doing iFrames is not a big (additional) security risk beyond what we are already doing. It’s a kind of tricky question though and requires thinking about how much the Chrome/Safari/Firefox teams will prioritize security in iFrame sandboxes this way.