(no title)
naugtur | 5 months ago
Also, together with a bunch of great folks at TC39 we're trying to get enough building blocks for the same-realm isolation primitives into the language.
see hardenedjs.org too
I'm doing the rounds promoting the project today because at this point all we need to eliminate certain types of malware is get LavaMoat a lot more adoption in the ecosystem.
( and that'll give me bug reports and maybe even contributions? :) )
hn92726819|5 months ago
I think that's why they made the comment.
naugtur|5 months ago
btown|5 months ago
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|5 months ago
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.