Re: [w3c/ServiceWorker] `<iframe sandbox />` + SW (#1390)

justinfagnani left a comment (w3c/ServiceWorker#1390)

> One other alternative that came to my mind was to try and not shoehorn things onto sandboxed iframe but rather consider solution for loading sandboxed web applications with some networking capabilities. Which could possibly manifest something like:
> 
> <iframe sandbox srcworker="./service.js" />
> Idea being that sandbox could load all of it's content by fetching it from service worker provided by `./service.js`. That would allow embedder to fully control CSPs.

This would be a great start to solution to the use case that we have in projects like https://github.com/google/playground-elements (as used in https://lit.dev/playground)

Right now, in order to create a service worker controlled iframe with a separate origin from the embedding page we have to actually serve files from a different origin, which requires two servers and doesn't work offline.

The setup is pretty complicated too:

Assume we have origin A for the embedding page, and origin B for the iframe.

1. First we need an iframe that installs the service worker and can also communicate with the embedding page. This runs trusted code, but must be on origin B. Call this the proxy iframe. So a server on origin B serves a proxy.html file that installs the service worker (also served from origin B) and `message` event handlers to communicate with the embedding page.
2. The embedding page then sends an initiation message to the proxy iframe along with a MessagePort to receive new messages on
3. The proxy iframe then create a MessageChannel to enable communication between the embedding page and the service worker, and sends one port to the page and the other to the service worker
4. The page then sets up handlers to listen for messages from the service worker that request files - this essentially lets the page handle fetch events from the iframe.
5. Then the page creates a new iframe and sets the `src` attribute to a URL on origin B controlled by the service worker
6. The service worker receives a fetch event and posts a message to the port from step 4
7. The page receives a message on it's port from step 4 and sends file content to the service worker, which responds to the fetch event.

If we could instead explicitly install a service worker from origin A into a sandboxed iframe, and get a reference to it (maybe like `iframe.contentServiceWorker`?), then we could skip the second server and the second iframe and add `message` event handlers directly to the iframe's service worker from the embedding page.

The two-origin approach is particularly bad when trying to make reusable components that have embedder-controlled iframes like the Playground Elements, because a page can't just drop the element in and have it work (at least not safely). The page must serve the `proxy.html` and `service-worker.js` files from a separate origin, and point the components to them. It breaks teh self-containment of the component, and is harder to accommodate on simple static file servers like GitHub pages.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1390#issuecomment-3459151537
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1390/3459151537@github.com>