I'm glad to see a big player in the JS eco-system address supply chain security head on. https://obsidian.md/blog/less-is-safer

Seems to me that what we really need is a way to run libraries with minimal privileges as a matter of course. Perhaps WASM will let us do this. I think WASM has enough virtues that it will become the dominant way to deploy business logic in the nearish future.

Running libraries with distinct privileges implies a security-relevant boundary around the library. That's something that traditional PL-based libraries don't have. In Unix-like architectures, such boundaries are available only for processes. Does WASM change that?

I believe wasm permits assigning privileges on a per module basis.

Too bad the only people who seemed to be working on this problem all got swept up in the crypto craze.

You can do plugins with limited privileges by running everything in an iframe, or by running in quickjs, but the 'standardized' improvement of this (realms) has been super slow to standardize

Came here to say the same thing - my friend who uses Obsidian plugins was pointing out that those can receive malicious upstream updates and pwn your filesystem. I'd be worried about supply chain attacks on plugin maintainers, yeah.

That seems to be a frequent issue with plugin architectures. Are there any that sandbox their plugins by default? Browser extensions are restricted by the browser (including for the security of Google's ad revenues), but I can't remember any other example.

figma's kind of the leading example of a web app architecture with sandboxing - they botched it the first time ( https://www.figma.com/blog/an-update-on-plugin-security/ ) but pivoted to quickjs + iframe as their abstraction layer. observable runs untrusted code in an iframe with postMessage as an untrusted channel

Sandboxing and supply chain considerations are orthogonal, right? @Tom MacWright What is the definition of 'untrusted' above? The example in my head is: You can have a zone with clearly demarcated privileges that are nonetheless abused after an update to software that runs within that zone.

I don't think they're orthogonal - in the world of applications with plugins, they're pretty tightly related (you essentially have to assume that plugins are malicious). For applications without plugin architectures, there's still a degree to which, say, Deno's permissions structure allows you to identify supply chain issues because third-party code doesn't automatically get all abilities.

I wish sandboxing was used more even in places without plugins 😄 If you could give restricted permissions to a library you could be much more relaxed about updates to it. But that requires much tighter control over the sheer number of dependencies you take on.

yeah, it's also be cool if an object capability language caught on - really seems like that'd help at least in theory. but the most used is hack afaict