Performance isolation for srcdoc iframes (a la Origin-Agent-Cluster)

[josephrocca]

Is there currently a way to performance-isolate a srcdoc iframe? The header-specified isolation approach (i.e. Origin-Agent-Cluster) doesn't seem to support this use case.

I'd like to essentially use a srcdoc iframe as a "rendered" webworker. So it has the performance isolation aspect of webworkers, and the ability to dynamically launch arbitrary code, and (importantly) it also has the ability render fully-interactive HTML.

If the parent frame freezes for whatever reason, the child srcdoc frame will remain interactive, and vice versa - as is the case with Origin-Agent-Cluster-isolated frames.

[domenic]

Not explicitly.

The first issue is that srcdoc iframes are same-origin by default. Anything that's same-origin is impossible to performance-isolate, because the two iframes have synchronous access to each other.

OK, but you can make them cross-origin by using sandbox="". Then will it be performance-isolated?

Well, in theory, it can be. And you don't need any new header to do so; there's no synchronous access between them possible, so browsers can performance-isolate them into their own process at will.

In practice, I know that Chromium at least has not implemented out-of-process iframes (OOPIFs) for sandbox="". I believe it's on the backlog, and I'll see if I can get any Chromium engineers to chime in here with more-specific pointers.

Similarly, maybe @annevk has info on whether Firefox's OOPIF implementation considers sandboxed iframes able to be moved out of process.

[josephrocca]

Thank you! So currently not possible, but it sounds like it's something we might see in the future if there's enough interest from developers and implementers. Very interested in hearing from annevk and Chromium engineers on this. Ideally it'd end up being as simple as adding a token to the sandbox attribute, or something like that.

[annevk]

Firefox currently doesn't do that because of concerns about memory usage. I don't think adding a token would help as attackers would set that token. We need to figure out a strategy that doesn't make it overtly expensive. One thing I discussed with @mystor is that we'd at most use 2x the amount of processes. E.g., you'd have a process for origin A, and you'd have a process for "origin" A, sandboxed (this is technically an opaque origin, but for process isolation purposes you'd keep the initial origin around).

That's still not ideal of course, but it's an improvement and hopefully over time we can do more work to make processes cheaper (or wait long enough for magical hardware to be there).

[domenic]

I was pointed to https://bugs.chromium.org/p/chromium/issues/detail?id=510122 on the Chrome side.