Investigate embedding Partytown via a cross-origin iframe about partytown

[emilisb]

Hi @adamdbradley @steve8708 , I started working on this feature. I made a quick and hacky POC to get it work (both SW and Atomics). I moved the service worker and the web worker to a cross-origin iframe which communicates with the main thread via postMessage and then passes all messages to web worker/service worker. Now I am trying to use a MessageChannel instead, that way we would avoid an additional message hop and performance should stay more or less the same as it is now. Atomics also work with this approach as long as both the main document and the new iframe satisfy crossOriginIsolated requirements.

I can finish it and open a PR, but I have a few questions:

1. Would you take a PR for this? Do you have any specific requirements for this feature, such as make this new communication mechanism opt-in?
2. Why does SW sandbox currently run inside an iframe? I cannot understand how it improves the isolation.

We can discuss this on Discord if that is more convenient for you, I left a message in partytown-general channel.

[adamdbradley]

I see what you mean, in that you purposely do not want the scripts to even run on the same domain to specifically not allow access to indexedDB? You're right, in that right now between the sandbox iframe and the main window there isn't a postMessage, so doing so would add one more communication hop.

I think before we dig too far into that I'd be curious to investigate Atomics further. Right now I don't know enough what the implementation will look like, and don't want to go too far down this path just to find out we scrap it later. I'll leave this issue open and will revisit, but would love to keep discussing ideas here. Thanks

[adamdbradley]

Put some more thought into this and certainly makes a lot of sense, especially if we want to sandbox and isolate even further. So step one, like you said, would be to the iframe sandbox to only communicate via postMessage.

Next I think the iframe hosted under a different origin, which might be harder for a default setup. So maybe the default continues to work under /~partytown/, but if it was moved to a different subdomain, it'd still just work, but more of an opt-in to ensure it's fully sandboxed. Thoughts?

[steve8708]

Wonder if using sandboxed iframes would accomplish the same goals without having to have another domain to host the iframe on. May be able to easily create a sandboxed iframe inline using srcdoc

[steve8708]

Ah tho I see why we would need Atomics to use inline sandboxes iframes as I’m not sure how it would work with the service worker approach. Ignore me 😄

[lawnsea]

Thanks for the interest in this suggestion, @adamdbradley!

Next I think the iframe hosted under a different origin, which might be harder for a default setup. So maybe the default continues to work under /~partytown/, but if it was moved to a different subdomain, it'd still just work,

I like this idea. It would simplify the documentation and make it easy for folks to opt into stronger isolation.

It's a bummer to impose the overhead of an additional postMessage hop for users that don't care about stronger isolation, though, so I hope we can make the iframe wrapper optional.

[lawnsea]

@steve8708, I agree that Atomics plus a sandbox iframe without the allow-same-origin permission would be simpler and faster. Unfortunately, it doesn't look like it's possible to use a service worker with such an iframe: w3c/ServiceWorker#1390.

One consequence of this situation to note is that the service worker implementation provides an opportunity for stronger isolation, as the SW controls network requests from the web worker. For that reason, I hope we can support the Atomics implementation with the cross-origin iframe setup as well.