5 ms·

Looks like OP is one of the contributors to LavaMoat

naugtur 1y ago
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 1y ago
  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 1y ago
    Yup, and thanks - I should have made the comment myself but got distracted.
    - EasyMark 1y ago
      You're forgiven. Thanks to you (and any other contribs) for the excellent project
- btown 1y ago
  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 1y ago
    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 1y ago
      so to answer the actual question. if something expects too much browser/dom access to work, it won't?

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 1y ago
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 1y ago
  Yup, and thanks - I should have made the comment myself but got distracted.
  - EasyMark 1y ago
    You're forgiven. Thanks to you (and any other contribs) for the excellent project
btown 1y ago
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 1y ago
  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 1y ago
    so to answer the actual question. if something expects too much browser/dom access to work, it won't?