1. 4
  1. 2

    Not tested, but IIRC if tou do not use the sandbox attribute and instead use document.origin = document.origin you should get a cross-origin iframe environment that your service worker should be able to intercept…as it is in the same origin.

    …don’t ask how I know this ;-)

    1. 1

      The point is we have sensitive stuff like encryption keys in the outer context. So we need full separate process sandboxing to protect from Spectre et al.

    2. 2

      Get a domain and put it on the Public Suffix List. Generate fresh subdomains e.g. .domain.tld for your iframe. Different origin, different security context.

      If you want to opt in to be in a fully different process, you’ll need to look into Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy (COOP and COEP). Even then, you might not, depending on browser and underlying operating system.

      P.S: You may be able to cheat yourself into a separate process using https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Large-Allocation but that doesn’t work with iframes

      1. 1

        Hi @freddyb, thank you for the reply. We’re hoping to rely on OOPIF for isolation - my understanding is Firefox is planning on implementing that? We specifically don’t want to rely on the domain name system for a few reasons. We want to totally lock down the sandboxed code, so no web requests that aren’t intercepted by the service worker for example. This means we can prove that the apps can’t exfiltrate data. We decrypt everything locally and don’t want to expose that to code that is loaded from another server/domain, which you’d have to then trust.

        Other reasons we don’t want to rely on DNS are that we want to be able to work fully offline (including being connected to some local nodes over P2P), and we want self-hosters to not need to do anything to do with domain names (nor to trust us and our servers). We can currently run a localhost Peergos instance which does TLS 1.3 to other Peergos instances using IPFS’s P2P streams, where the address is the public key hash of the target so no need for DNS.

        I’d love to talk with you in more detail if your interested?

        1. 2

          OOPIF are mostly an implementation detail of chrome browser.

          What you need from a specification perspective is your own browsing context group. That’s what you’d get with COEP & COOP.

          1. 1

            I’ve set up an analogous example using COEP and COOP to sandbox the iframe as well as CSP, but it seems to have exactly the same problem. After loading the root document of the iframe from the service worker, any subsequent asset request fails to be intercepted by the service worker and thus 404s. In this case it’s for the image burritocat.jpg