Looks like OP is one of the contributors to LavaMoat

Yes, I am. I came up with the first successful attempt at integrating the Principle of Least Authority software in LavaMoat with Webpack and wrote the LavaMoat Webpack Plugin.

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 3 days ago | parent | next [-]

I think most people are fine with promoting a cool project you work on, but it's best practice to disclose that in the article. Even something like "If your project was set up with LavaMoat (a project I've been working on), ..." would be enough.

I think that's why they made the comment.

▲

naugtur 3 days ago | parent [-]

Yup, and thanks - I should have made the comment myself but got distracted.

	▲	EasyMark 3 days ago \| parent [-]
		You're forgiven. Thanks to you (and any other contribs) for the excellent project

▲

btown 3 days ago | parent | prev [-]

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 3 days ago | parent [-]

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 3 days ago \| parent [-]
		so to answer the actual question. if something expects too much browser/dom access to work, it won't?