If you’ve been keeping up with WASM development then you’ll probably notice most of this isn’t new information. These companies have been working on these technologies (CraneLift (previously names Cretonne), Wasmtime, Lucet, & WAMR) for months or in some cases years and they’re coming along nicely. This is definitely a nice recap of the work that has been done and I for one am excited to see if there is a next big step that these companies will take now that they’re explicitly working together.
The cynicism in this thread is pretty stunning. Described here is a plan to design and implement a fine-grained, library-level capability-based security system for a platform that’s seeing massive adoption. While this isn’t novel from a research perspective, it’s, as far as I can tell, the first time this stuff is making it down from the ivory tower into a platform that’ll be broadly available for application developers.
Lots of folks seem pretty scornful about the amount of stuff in current browsers, even though non-browser use cases are explicitly highlighted in this piece. There’s an implication that this is a reinvention of things in BSD, even though this approach is explicitly contrasted with OS process-level isolation, in this piece. There’s the proposed alternative of simply only using highly trusted, low-granularity dependencies, which is fair, but I think that ship has sailed, and additionally it seems like avoiding the problem instead of solving it.
I’m a bit disappointed here that the reaction to set of tools and standards that might allow us developers to write much safer code in the near future has garnered this kind of reaction based on what I see as a cursory and uncharitable read of this piece.
I believe “avoiding” here was meant rather as “closing eyes to [the problem]”, than the more virtuous “removing the existence of [the problem]”.
In a world where even SQLite was found to have vulnerabilities, I believe any alternative solution based on some handwaved “highly trusted huge libraries” is a pipe dream. Please note, that in actual high trust systems, AFAIK limiting the permissions given to subsystems is one of the basic tools of the trade, with which you go and actually build them. A.k.a. “limiting the Trusted Computing Base”, i.e. trying to maximally reduce the amount of code that has access to anything important, isolating it as much as possible from interference, and then verifying it (which is being made easier by the amount of it needing verification being reduced through the previous step).
If you’re intrested in recent projects trying to break into mainstream with the capabilities-based approach, such as suggested in the OP IIUC, see e.g.: seL4, GenodeOS, Fuchsia, Pony language.
That said, I’m not an expert. I very much wonder what’s the @nickpsecurity’s take on the OP!
Been pulling long shifts so initially no reply. Actually, I agree with some that this looks like a marketing fluff piece rather than a technical write-up. I’d have ignored it anyway. Ok, since you asked… I’d like to start with a bottom-up picture of what security means in this situation:
Multicore CPU with shared, internal state; RAM; firmware. Isolated programs sharing these can have leaks, esp cache-based. More attacks on the way here. If SMP, process-level separation can put untrusted processes on their own CPU and even DIMM’s. The browsers won’t likely be doing that, though. We’ve seen a few attacks on RAM appear that start with malicious code running on the machine, too. These kinds of vulnerabilities are mostly found by researchers, though.
OS kernel. Attacked indirectly via browser functionality. No different than current Javascript risk. Most attacks aren’t of this nature.
Browser attack. High risk. Hard to say how WebAssembly or capability-based security would make it different given the payload is still there hitting the browser.
Isolation mechanisms within the Javascript engine trying to control access to browser features and/or interactions between Javascript components. Bytecode Alliance sounds like that for WebAssembly. Note this has been tried before: ADsafe and Caja. I think one got bypassed. Bigger problem was wide adoption by actual users.
So, the real benefits seem to be all in 4 leaving open 1-3. Most of the attacks on systems have been in 3. Protecting in 4 might stop some attacks on users of web pages that bring in 3rd-party content. Having run NoScript and uBlock Origin, they do argue that a lot of mess could be isolated at JS/WA level. Stuff does slip through often due to being required to run the sites.
You see, most admins running those sites don’t seem to care that much. In many cases, they could avoid the 3rd-party risks but bring them in anyway. The attack opening could come in the form of stuff from them that the user allowed which interacts with malicious stuff. Would capability-secure, WA bytecode help? Idk.
Honestly, all I can do is illustrate where and how the attacks come in. We can’t know what this can actually do in practice until we see the design, the implementation, a list of all the attack classes, and cross-reference them against each other. It’s how you evaluate all of these things. I’d like to see a demo blocking example attacks with sploit developers getting bounties and fame for bypasses. That would inspire more confidence.
WASM is nice and has lots of potential. A lot of people when first seeing the spec also thought, “cool that’ll run on the server too over time”. There are use cases where it is interesting. I use it in my projects here and there.
But come on, grand plans of secure micro-services and nano-services made from woven carbon fiber nano-tubes, and a grandious name BytecodeAlliance. It’s like a conversation from the basement of numerous stoner parties. I’m pretty sure a lot of people here have been writing p-code ever since, well, p-code.
I don’t want to undermine the effort of course, and all things that improve tooling or foster creativity are greatly appreciated.
They should down the rhetoric and maybe work with the WASMR folk. Leaping out with a .org after your name comes with a great deal of responsibility.
There are lots more to do with WASM that needs doing than simply slapping it in a server binary and claiming it is a gift from heaven, when the actual gift from heaven was the Turing Machine.
All that said, please keep it up. The excitement of new generations for abstract machines is required, meaningful and part of the process.
Almost every programming language and set of tools uses third-party dependencies to some extent these days. There are clear benefits and increasingly clear costs to this practice, with both contingent on tooling and ecosystem. I agree that the node.js model of a sprawling number of tiny dependencies is a quite poor equilibrium; the Rust world seems to be taking this to heart by rolling things back into the standard library and avoiding the same kind of sprawl.
Regardless, third-party dependencies from heterogenous sources will continue to be used indefinitely, and having tools to make them safer and more predictable to use will probably bring significant benefits. This kind of tool could even be useful for structuring first-party code to mitigate the effects of unintentional security vulnerabilities or insider threats.
Saying “just avoid doing it” is a lot like abstinence-only sex ed: people are almost certainly still going to do it, so instead we should focus on harm reduction and a broad understanding of risks.
I’ve given this some more thought, and I think the reason this raises my eyebrows is a combination. It’s a long article on a PR-heavy site that tries to give the impression that this very young technology (WASM) is the only way of solving this problem, it doesn’t mention prior art or previous working attempts (try this on the JVM), and it doesn’t acknowledge what this doesn’t solve and the implications of this model (now you can’t trust any data that comes back from your dependencies, even if they’re well-behaved in the eyes of the Alliance).
Every new thing in security necessarily gets a certain amount of cynicism and scrutiny.
How lightweight it is. The overhead of loading the v8 runtime is tiny by comparison to the JVM (on my machine, it takes less than 30ms to run a ‘hello world’ node process).
That it has been designed for embedding in other programs. Embedding a JVM in a non-java project is nontrivial at best; embedding a working wasm runtime in a c project is only slightly harder than, say, lua.
True, true. I was thinking something like an experiment to demonstrate how nanoprocess-ifying known vulnerable or malicious dependencies (within the JVM runtime) solves a security issue.
Web is gonna Web, so we all know how this will work out.
“Web standards experts” continuously add stuff, and then the next decades is spent plugging the holes they opened, because once it’s added “we can’t break the web”.
If they were supposed to design a toothbrush, people would die.
I’m really excited about using this to decouple databases from their query languages. The database could expose tables and indices via a wasm api and the client could compile whatever query language it likes into a wasm template and install it. It would finally open up the narrow waist of SQL to competition.
An Ordered Key-Value store that can send wasm to the data could expose a solid SQL interface client-side. Most worst-case optimal join algorithms only need ordered indexes.
The trivial solution, of not using so many dependencies or of not shoehorning so much shit into browsers, is of course not really discussed.
Something must be done, this is something, so this must be done.
EDIT:
With wasm, we can replace microservices with nanoprocesses and get the same security and language independence benefits. It gives us the composability of microservices without the weight. This means we can use a microservices-style architecture and the language interoperability that provides, but with a finer-grained approach to defining the component services.
The trivial solution, of not using so many dependencies <…>, is of course not really discussed.
Do we really believe that the toothpaste can so trivially be put back in the tube? I can’t sell “this next project is going to take 3-10x as long as the last one because we’re going to roll our own everything instead of using rubygems/npm/cocoapods/crates.io/whatever, in order to somewhat reduce our exposure to supply chain attacks”.
People do not want to pay that much more for security, however much they claim to value it. Recognizing the reality that business pressures demand maintaining current velocities, and finding ways to mitigate the risks, strikes me as a lot more productive than just sticking our heads in the sand and insisting that everyone everywhere should do a lot more, a lot more slowly.
There’s a difference between ‘no dependencies’ and ‘no randomly grabbing whatever sounds good today’.
I recently needed a drag-and-drop implementation.
I quickly reviewed the source to the most popular four options. Each purports to support a multitude of use-cases, one of which I needed. Each was 500-1000 lines of javascript. In each, I found an obvious ‘not a serious bug but clearly wrong’ within a few minutes.
Implementing just the part I needed took ~60 lines of typescript, and about an hour.
On average, this approach is much faster than npm install drag-and-drop, since I didn’t have to interpret outdated documentation which refers to since-removed behavior, or investigate obscure bug reports caused by upstream oddities (eg double-firing events, requiring polyfills which aren’t installed etc).
You’d be hard-pressed to find somebody more receptive to the money funnel argument (biz over dev) than me, at least in commercial endeavors!
That said, I can’t agree with you that this current state of affairs was done because the business folks wanted it that way.
It’s a hell of a lot easier to mitigate risks when you have less code, and a hell of a lot easier to maintain velocity when you control your own stack and can make sweeping changes when the business needs it.
Now, there’s certainly an argument to be made that we have dependencies on things like React and Jquery because historically browser vendors/W3C were slow to act and mostly didn’t pay attention to things that matter for line-of-business developers–however, that’s a problem that we could’ve addressed without resorting to dependencies.
I think that’s an uncharitable, cynical reaction. Even when we don’t go crazy with dependencies a la npm, for the dependencies that we inevitably do have, there’s great value in having a portable, non-proprietary standard with strong (capability-based) security.
There are some dependencies that are just too complex yet essential to just crank out some code yourself instead. I used to work at a tiny cash-strapped company, and we rarely shelled out for a commercial software library, but sometimes we needed a component that would have been way out of my depth to write myself and didn’t have a good open-source implementation. These included various speech synthesizers and an OCR engine. I would have loved it if we could have had these commercial components in a portable form rather than as Windows DLLs. WebAssembly could actually achieve this while not sacrificing performance. The security aspect of it just makes it even better. With the rise of non-browser-based WebAssembly runtimes and this Bytecode Alliance, I’m hoping that within a few years, some of these vendors will offer WebAssembly versions of their components. That’s what excites me about this announcement.
As for the interface between nanoprocesses, I hope we end up with something more like COM (the in-process good parts) than HTTP. If that’s why you sighed at the comparison to microservices, then I’m with you.
Your point would have been much better served if you explained your siiiigh. At this point almost all usages of sigh are trite and patronizing. It distracts greatly from the discussion.
Good point, and thanks for pointing that out–I just get exasperated with a lot of the stuff happening in the browser/web space sometimes.
With wasm, we can replace microservices with nanoprocesses and get the same security and language independence benefits.
“Nanoprocesses” as explained in the writeup seem like some weird combination of BSD pledge, fibers, and marketing. None of this appears to be as beneficial to web developers as it does to web platform researchers.
It gives us the composability of microservices without the weight.
One of the big theoretical microservice benefits is how lightweight they were supposed to be–hence the “micro” prefix.
This means we can use a microservices-style architecture and the language interoperability that provides, but with a finer-grained approach to defining the component services.
What does a “microservice-style” architecture even mean for a web page? Why is it desirable? Why is a finer-grained approach to defining component services needed? What exactly are component services, anyways?
Context: I’m the sole developer on a fairly large website which has existed for over a decade.
The list of npm dependencies on this thing is huge (I’m slowly shrinking it, when possible). Being able to compile them to wasm and whitelist their access to browser features would help my confidence when I need to upgrade something to a new version (see e.g. the variety of malicious package upgrades published to npm).
I am much more excited at the prospect of precompiling native code for the server to run at native (or close enough) speed. Look at (eg) the endless install bugs with nokogiri in the ruby world - imagine if the nokogiri authors could ship a precompiled webassembly version (and have it natively supported by the ruby runtime) without end users needing the right system libraries / compiler toolchains installed.
Being near native speed, it’s also valuable for game modding / application plugins, where it improves security (via sandboxing) and performance (vs eg lua for most game modding).
While the terminology is new, I think goals of the group are aligned with where you would like the industry to go.
The focus is on least privilege, capability based containment at a module level. The module will be the service boundary, the goal is to get interop cost down to something comparable to a function call. An analogous approach is something akin to the multiprocess model of Postfix [1], where an application is broken into a bunch of service and failure domains. Both on the server and in client, we should be able to consume dependencies w/o having that dependency now initiate bank transfers or do click stuffing.
A nanoprocess is like an Erlang process, or should have that in mind.
Instead of inventing the word nanoprocess, the word container would’ve been considerably more apt; a nanoprocess appears to consist of more than one actual process?
Yeah, it wasn’t a particularly insightful comment as I couldn’t quite articulate why this didn’t sit right with me. I’ll give myself more percolation time in the future.
It’s okay, others have posted that before. I think pledge + WASM would be great, with pledge providing the process-level sandbox, enforced by the kernel and WASM the fine grained sandboxes.
If you’ve been keeping up with WASM development then you’ll probably notice most of this isn’t new information. These companies have been working on these technologies (CraneLift (previously names Cretonne), Wasmtime, Lucet, & WAMR) for months or in some cases years and they’re coming along nicely. This is definitely a nice recap of the work that has been done and I for one am excited to see if there is a next big step that these companies will take now that they’re explicitly working together.
The cynicism in this thread is pretty stunning. Described here is a plan to design and implement a fine-grained, library-level capability-based security system for a platform that’s seeing massive adoption. While this isn’t novel from a research perspective, it’s, as far as I can tell, the first time this stuff is making it down from the ivory tower into a platform that’ll be broadly available for application developers.
Lots of folks seem pretty scornful about the amount of stuff in current browsers, even though non-browser use cases are explicitly highlighted in this piece. There’s an implication that this is a reinvention of things in BSD, even though this approach is explicitly contrasted with OS process-level isolation, in this piece. There’s the proposed alternative of simply only using highly trusted, low-granularity dependencies, which is fair, but I think that ship has sailed, and additionally it seems like avoiding the problem instead of solving it.
I’m a bit disappointed here that the reaction to set of tools and standards that might allow us developers to write much safer code in the near future has garnered this kind of reaction based on what I see as a cursory and uncharitable read of this piece.
Avoiding a problem is the best category of solution. Why expend resources to fix problems you can avoid in the first place?
I believe “avoiding” here was meant rather as “closing eyes to [the problem]”, than the more virtuous “removing the existence of [the problem]”.
In a world where even SQLite was found to have vulnerabilities, I believe any alternative solution based on some handwaved “highly trusted huge libraries” is a pipe dream. Please note, that in actual high trust systems, AFAIK limiting the permissions given to subsystems is one of the basic tools of the trade, with which you go and actually build them. A.k.a. “limiting the Trusted Computing Base”, i.e. trying to maximally reduce the amount of code that has access to anything important, isolating it as much as possible from interference, and then verifying it (which is being made easier by the amount of it needing verification being reduced through the previous step).
If you’re intrested in recent projects trying to break into mainstream with the capabilities-based approach, such as suggested in the OP IIUC, see e.g.: seL4, GenodeOS, Fuchsia, Pony language.
That said, I’m not an expert. I very much wonder what’s the @nickpsecurity’s take on the OP!
Been pulling long shifts so initially no reply. Actually, I agree with some that this looks like a marketing fluff piece rather than a technical write-up. I’d have ignored it anyway. Ok, since you asked… I’d like to start with a bottom-up picture of what security means in this situation:
Multicore CPU with shared, internal state; RAM; firmware. Isolated programs sharing these can have leaks, esp cache-based. More attacks on the way here. If SMP, process-level separation can put untrusted processes on their own CPU and even DIMM’s. The browsers won’t likely be doing that, though. We’ve seen a few attacks on RAM appear that start with malicious code running on the machine, too. These kinds of vulnerabilities are mostly found by researchers, though.
OS kernel. Attacked indirectly via browser functionality. No different than current Javascript risk. Most attacks aren’t of this nature.
Browser attack. High risk. Hard to say how WebAssembly or capability-based security would make it different given the payload is still there hitting the browser.
Isolation mechanisms within the Javascript engine trying to control access to browser features and/or interactions between Javascript components. Bytecode Alliance sounds like that for WebAssembly. Note this has been tried before: ADsafe and Caja. I think one got bypassed. Bigger problem was wide adoption by actual users.
So, the real benefits seem to be all in 4 leaving open 1-3. Most of the attacks on systems have been in 3. Protecting in 4 might stop some attacks on users of web pages that bring in 3rd-party content. Having run NoScript and uBlock Origin, they do argue that a lot of mess could be isolated at JS/WA level. Stuff does slip through often due to being required to run the sites.
You see, most admins running those sites don’t seem to care that much. In many cases, they could avoid the 3rd-party risks but bring them in anyway. The attack opening could come in the form of stuff from them that the user allowed which interacts with malicious stuff. Would capability-secure, WA bytecode help? Idk.
Honestly, all I can do is illustrate where and how the attacks come in. We can’t know what this can actually do in practice until we see the design, the implementation, a list of all the attack classes, and cross-reference them against each other. It’s how you evaluate all of these things. I’d like to see a demo blocking example attacks with sploit developers getting bounties and fame for bypasses. That would inspire more confidence.
Agreed, this is no silver bullet.
WASM is nice and has lots of potential. A lot of people when first seeing the spec also thought, “cool that’ll run on the server too over time”. There are use cases where it is interesting. I use it in my projects here and there.
But come on, grand plans of secure micro-services and nano-services made from woven carbon fiber nano-tubes, and a grandious name BytecodeAlliance. It’s like a conversation from the basement of numerous stoner parties. I’m pretty sure a lot of people here have been writing p-code ever since, well, p-code.
I don’t want to undermine the effort of course, and all things that improve tooling or foster creativity are greatly appreciated.
They should down the rhetoric and maybe work with the WASMR folk. Leaping out with a .org after your name comes with a great deal of responsibility.
There are lots more to do with WASM that needs doing than simply slapping it in a server binary and claiming it is a gift from heaven, when the actual gift from heaven was the Turing Machine.
All that said, please keep it up. The excitement of new generations for abstract machines is required, meaningful and part of the process.
Almost every programming language and set of tools uses third-party dependencies to some extent these days. There are clear benefits and increasingly clear costs to this practice, with both contingent on tooling and ecosystem. I agree that the node.js model of a sprawling number of tiny dependencies is a quite poor equilibrium; the Rust world seems to be taking this to heart by rolling things back into the standard library and avoiding the same kind of sprawl.
Regardless, third-party dependencies from heterogenous sources will continue to be used indefinitely, and having tools to make them safer and more predictable to use will probably bring significant benefits. This kind of tool could even be useful for structuring first-party code to mitigate the effects of unintentional security vulnerabilities or insider threats.
Saying “just avoid doing it” is a lot like abstinence-only sex ed: people are almost certainly still going to do it, so instead we should focus on harm reduction and a broad understanding of risks.
[Comment removed by author]
but that ship has sailed remember
I’ve given this some more thought, and I think the reason this raises my eyebrows is a combination. It’s a long article on a PR-heavy site that tries to give the impression that this very young technology (WASM) is the only way of solving this problem, it doesn’t mention prior art or previous working attempts (try this on the JVM), and it doesn’t acknowledge what this doesn’t solve and the implications of this model (now you can’t trust any data that comes back from your dependencies, even if they’re well-behaved in the eyes of the Alliance).
Every new thing in security necessarily gets a certain amount of cynicism and scrutiny.
So, drawing a comparison to the JVM is fair.
IMO, the key differences are:
True, true. I was thinking something like an experiment to demonstrate how nanoprocess-ifying known vulnerable or malicious dependencies (within the JVM runtime) solves a security issue.
We are at the mocking level of acceptance! This means that it will be a thing, a real thing in just a matter of months!
Web is gonna Web, so we all know how this will work out.
“Web standards experts” continuously add stuff, and then the next decades is spent plugging the holes they opened, because once it’s added “we can’t break the web”.
If they were supposed to design a toothbrush, people would die.
I’m really excited about using this to decouple databases from their query languages. The database could expose tables and indices via a wasm api and the client could compile whatever query language it likes into a wasm template and install it. It would finally open up the narrow waist of SQL to competition.
This is a good use case for wasm. Even if I believe the future of databases is Ordered Key-Value Stores (OKVS).
An Ordered Key-Value store that can send wasm to the data could expose a solid SQL interface client-side. Most worst-case optimal join algorithms only need ordered indexes.
The trivial solution, of not using so many dependencies or of not shoehorning so much shit into browsers, is of course not really discussed.
Something must be done, this is something, so this must be done.
EDIT:
Siiiiiiigh.
Do we really believe that the toothpaste can so trivially be put back in the tube? I can’t sell “this next project is going to take 3-10x as long as the last one because we’re going to roll our own everything instead of using rubygems/npm/cocoapods/crates.io/whatever, in order to somewhat reduce our exposure to supply chain attacks”.
People do not want to pay that much more for security, however much they claim to value it. Recognizing the reality that business pressures demand maintaining current velocities, and finding ways to mitigate the risks, strikes me as a lot more productive than just sticking our heads in the sand and insisting that everyone everywhere should do a lot more, a lot more slowly.
There’s a difference between ‘no dependencies’ and ‘no randomly grabbing whatever sounds good today’.
I recently needed a drag-and-drop implementation.
I quickly reviewed the source to the most popular four options. Each purports to support a multitude of use-cases, one of which I needed. Each was 500-1000 lines of javascript. In each, I found an obvious ‘not a serious bug but clearly wrong’ within a few minutes.
Implementing just the part I needed took ~60 lines of typescript, and about an hour.
On average, this approach is much faster than
npm install drag-and-drop, since I didn’t have to interpret outdated documentation which refers to since-removed behavior, or investigate obscure bug reports caused by upstream oddities (eg double-firing events, requiring polyfills which aren’t installed etc).You’d be hard-pressed to find somebody more receptive to the money funnel argument (biz over dev) than me, at least in commercial endeavors!
That said, I can’t agree with you that this current state of affairs was done because the business folks wanted it that way.
It’s a hell of a lot easier to mitigate risks when you have less code, and a hell of a lot easier to maintain velocity when you control your own stack and can make sweeping changes when the business needs it.
Now, there’s certainly an argument to be made that we have dependencies on things like React and Jquery because historically browser vendors/W3C were slow to act and mostly didn’t pay attention to things that matter for line-of-business developers–however, that’s a problem that we could’ve addressed without resorting to dependencies.
I think that’s an uncharitable, cynical reaction. Even when we don’t go crazy with dependencies a la npm, for the dependencies that we inevitably do have, there’s great value in having a portable, non-proprietary standard with strong (capability-based) security.
There are some dependencies that are just too complex yet essential to just crank out some code yourself instead. I used to work at a tiny cash-strapped company, and we rarely shelled out for a commercial software library, but sometimes we needed a component that would have been way out of my depth to write myself and didn’t have a good open-source implementation. These included various speech synthesizers and an OCR engine. I would have loved it if we could have had these commercial components in a portable form rather than as Windows DLLs. WebAssembly could actually achieve this while not sacrificing performance. The security aspect of it just makes it even better. With the rise of non-browser-based WebAssembly runtimes and this Bytecode Alliance, I’m hoping that within a few years, some of these vendors will offer WebAssembly versions of their components. That’s what excites me about this announcement.
As for the interface between nanoprocesses, I hope we end up with something more like COM (the in-process good parts) than HTTP. If that’s why you sighed at the comparison to microservices, then I’m with you.
Your point would have been much better served if you explained your siiiigh. At this point almost all usages of sigh are trite and patronizing. It distracts greatly from the discussion.
Good point, and thanks for pointing that out–I just get exasperated with a lot of the stuff happening in the browser/web space sometimes.
“Nanoprocesses” as explained in the writeup seem like some weird combination of BSD
pledge, fibers, and marketing. None of this appears to be as beneficial to web developers as it does to web platform researchers.One of the big theoretical microservice benefits is how lightweight they were supposed to be–hence the “micro” prefix.
What does a “microservice-style” architecture even mean for a web page? Why is it desirable? Why is a finer-grained approach to defining component services needed? What exactly are component services, anyways?
Context: I’m the sole developer on a fairly large website which has existed for over a decade.
The list of npm dependencies on this thing is huge (I’m slowly shrinking it, when possible). Being able to compile them to wasm and whitelist their access to browser features would help my confidence when I need to upgrade something to a new version (see e.g. the variety of malicious package upgrades published to npm).
I am much more excited at the prospect of precompiling native code for the server to run at native (or close enough) speed. Look at (eg) the endless install bugs with
nokogiriin the ruby world - imagine if the nokogiri authors could ship a precompiled webassembly version (and have it natively supported by the ruby runtime) without end users needing the right system libraries / compiler toolchains installed.Being near native speed, it’s also valuable for game modding / application plugins, where it improves security (via sandboxing) and performance (vs eg lua for most game modding).
While the terminology is new, I think goals of the group are aligned with where you would like the industry to go.
The focus is on least privilege, capability based containment at a module level. The module will be the service boundary, the goal is to get interop cost down to something comparable to a function call. An analogous approach is something akin to the multiprocess model of Postfix [1], where an application is broken into a bunch of service and failure domains. Both on the server and in client, we should be able to consume dependencies w/o having that dependency now initiate bank transfers or do click stuffing.
A nanoprocess is like an Erlang process, or should have that in mind.
[1] http://www.postfix.org/OVERVIEW.html
GPT-2 has gotten really impressive.
Instead of inventing the word nanoprocess, the word container would’ve been considerably more apt; a nanoprocess appears to consist of more than one actual process?
This excites me, I think it’s great. Can’t wait to learn more.
What, no
pledge?It’s the year of BSD in the Browser
This comes up in every WASM thread, but confuses me massively. pledge is useful and good, but it is nothing like WASM.
Yeah, it wasn’t a particularly insightful comment as I couldn’t quite articulate why this didn’t sit right with me. I’ll give myself more percolation time in the future.
It’s okay, others have posted that before. I think
pledge + WASMwould be great, with pledge providing the process-level sandbox, enforced by the kernel and WASM the fine grained sandboxes.