[btown]

I'm often curious about how effective runtime quasi-sandboxing is in practice (at least until support at the TC39 level lands).

My understanding is that if you can run with a CSP that prevents unsafe-eval, and you lock a utility package down to not be able to access the `window` object, you can prevent it from messing with, say, window.fetch.

But what about a package that does assume the existence of window or globalThis? Say, a great many packages bridging non-React components into the React ecosystem. Once a package needs even read-only access to `window`, how do you protect against supply-chain attacks on that package? Even if you read-only proxy that object, for instance, can you ensure that nothing in `window` itself holds a reference to the non-proxied `window`?

Don't get me wrong - this project is tremendously useful as defense-in-depth. But curious about how much of a barrier it creates in practice against a determined attacker.

[naugtur]

It's based on HardenedJS.org

The sandbox itself is tight, there's a bug bounty even.

The same technology is behind metamask snaps - plugins in a browser extension.

And Moddable has their own implementation

The biggest problem is endowing too powerful capabilities.

We've got ambitious plans for isolating DOM, but that already failed once before.

[1oooqooq]

so to answer the actual question. if something expects too much browser/dom access to work, it won't?