Re: [w3c/ServiceWorker] Registering service workers for unique origins? (#1437)

I'm in a similar position as mjbvz. I have same-origin, yet untrusted code, which I voluntarily sandbox. I would like the content to be controlled by my service worker. Additionally, I would like global key combinations such as Ctrl+S to work even when one of those iFrames has focus.

I have thought about serving the content from a different origin, then using allow-same-origin and two nested iFrames to set up the service worker and key event listeners, as described in more detail by mjbvz. However, my application is currently purely static, without any server-side infrastructure requirements, thus serving the content form (multiple) different origins would be an unfortunate new requirement.

I got the following idea to solve this: maybe opaque origins are too harsh, in that they fail same-origin checks even with themselves. If we had the ability to create unique origins from JS that pass same-origin checks with themselves, we could use the nested iFrames approach without any server-side infrastructure.

This could e.g. be a new value for the sandbox attribute on iFrames:

```HTML
<iframe sandbox="allow-scripts">
    <!-- Semantics unchanged, the content is placed into an opaque origin
         that fails same-origin checks even with itself. -->
</iframe>

<iframe sandbox="allow-scripts allow-unique-origin">
    <!-- The new option, which places the content into a unique origin,
         which is capable of passing same-origin checks with itself. -->
</iframe>

<iframe sandbox="allow-scripts allow-same-origin">
    <!-- Semantics unchanged, the content keeps its origin. -->
</iframe>
```

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

Message ID: <w3c/ServiceWorker/issues/1437/1165366600@github.com>