4 ms·

> The fundamental problem with npm is that any package you install has full access to do whatever it wants on your computer. Let me try to answer more concisel

> The fundamental problem with npm is that any package you install has full access to do whatever it wants on your computer. Let me try to answer more concisely at a higher level: Due to JS being a very dynamic language, it is at this time not possible to give different packages inside of the same JS runtime a different set of permissions or capabilities securely. Because of this, the best we can do for sandboxing right now is permissions / capabilities that are set per JS runtime, rather than per dependency / module. This is what Deno does. It allows you to set capabilites for the set of your code and all of it's dependencies at once. If you want to run a certain module with lesser permissions, you need to move it into a seperate JS runtime, either by running it on a seperate thread with a web worker, or in a seperate Deno process. Both web workers and subprocesses can have different (lesser) permissions to their parent.

paulmd 5y ago
it's been fascinating watching the JS people reinvent the concept of an OS from scratch. Today it's the security model, yesterday it's the task scheduling, etc. Interesting little bit of outsider art, "what if front-end people designed an OS" and all, and it's going about as well as you'd expect with that. I mostly wouldn't mind, but there's certain thresholds that I think are noxious or dangerous as a user. WebGL strikes me as much more dangerous than most people anticipate, GPU drivers are not really hardened against hostile shaders very well, it's quite likely that various escapes and data-leaks exist imo. Someone I know who worked on implementing that and said that out of all the graphics vendors, none of them liked it but the blue one's engineers had genuine fear in their eyes when the functionality was laid out to them. I am also not really looking forward to when javascript realizes the need for persistent services... but thankfully I think web architecture mostly means that's somebody else's computer.
- ratww 5y ago
  This comment displays a lot of ignorance and prejudice. "JS people" have not been reinventing much at all. Operating Systems aren't even close to offering what "JS people" needs at the granularity they would benefit from. By that measure, the same complaint can be made about the Java or .NET virtual machine, for example. If anything, what the "JS people" of today is trying is to fix are all those "dangerous parts" that were added there with abandon by browser makers and OS people and will probably never be fixed in our lifetime. > I am also not really looking forward to when javascript realizes the need for persistent services It might surprise you, but Node.js works in the backend from day zero, and Service Workers have been working in the frontend for several years now. You're more than a decade behind the times.

paulmd 5y ago

it's been fascinating watching the JS people reinvent the concept of an OS from scratch. Today it's the security model, yesterday it's the task scheduling, etc. Interesting little bit of outsider art, "what if front-end people designed an OS" and all, and it's going about as well as you'd expect with that. I mostly wouldn't mind, but there's certain thresholds that I think are noxious or dangerous as a user. WebGL strikes me as much more dangerous than most people anticipate, GPU drivers are not really hardened against hostile shaders very well, it's quite likely that various escapes and data-leaks exist imo. Someone I know who worked on implementing that and said that out of all the graphics vendors, none of them liked it but the blue one's engineers had genuine fear in their eyes when the functionality was laid out to them. I am also not really looking forward to when javascript realizes the need for persistent services... but thankfully I think web architecture mostly means that's somebody else's computer.

ratww 5y ago
This comment displays a lot of ignorance and prejudice. "JS people" have not been reinventing much at all. Operating Systems aren't even close to offering what "JS people" needs at the granularity they would benefit from. By that measure, the same complaint can be made about the Java or .NET virtual machine, for example. If anything, what the "JS people" of today is trying is to fix are all those "dangerous parts" that were added there with abandon by browser makers and OS people and will probably never be fixed in our lifetime. > I am also not really looking forward to when javascript realizes the need for persistent services It might surprise you, but Node.js works in the backend from day zero, and Service Workers have been working in the frontend for several years now. You're more than a decade behind the times.