Virtualization, then Containers, and now WASM are all stages in completing the implementation of capability based security started long ago with the separation of root and users back in Unix.
While it is reasonable to trust users with their own files, it is unreasonable that the only model of computing offered to those users requires that they then give all of their privileges to every piece of code they run.
It is possible to run code from anywhere without having to trust it, thanks to this new model of computing.
>Capability security is almost as old as access control lists.
Yes, but it's never been fully implemented. Separating superuser/root from normal users was a good first approximation. However, in the modern era of persistent internet and mobile code, we need to finish the job.
Theoretically, you could start a new process having previously created a new UID and having turned off access to all files in the ACL on the root, but can a user do that? Easily? Can you explain it to someone's mom?
Money in a wallet is capability based, and people have managed that model since the beginning.
I'm fine with ACLs for managing overall access to file structures on a per account basis, they don't work for a per execution instance basis.
It's a good thing there aren't any known classes of architectural attacks exploiting the interaction of speculative execution and caches to exfiltrate sensitive data, nor are there classes of attacks which exploit the physical properties of DRAM to evade memory protection.
Yes indeed; running untrusted code blobs on my home computers and cloud servers alike is truly and finally solved by running them in a VM.
I agree that we have big problem with defective CPUs and DRAM in the industry. Those chips and modules shouldn't have made it out the factory door, nor should they have passed quality control at the receiving desk.
We also seem to have the same issue with SSD modules and SYNC commands.
You can't fix broken hardware in software without taking a huge performance it, if it is possible at all.
Yes, we all like to point out corner cases here, don't we?
Malicious attacks aren't always the vector of concern.
There are many software packages that confine themselves to what is legal. They often want to ingest and upload everything they can about the user. But if they are locked down to a narrow set of user data, they won't risk the liability of attacking the protections themselves.
It's also rather harder to exfiltrate data via rowhammer or meltdown than via, say, unrestricted filesystem access so even if it's technically possible, it will be less prevalent.
The second part of the talk is close to what I want, but they're missing a few parts.
I want to set up a DNS-like system, where I have some pub/private key pair to control which servers you can find me at. My friend Tom sets his up, too.
Then I want to tell the Service Host she's talking about, "Here's my friend Tom's public key. Please look him up in the DNS system, and find out how to reach one of his hosts. Let this new Service X, talk to Tom. Use something like Wire Guard to establish a connection directly from this wasm Service X that I'm running, to a similar wasm service X that Tom is running. We're going to send proto messages (not streams!) back and forth to each other, and you're in charge of connectivity."
Give me that, and the ability to talk to, I dunno, Redis, SQLite, MongoDB, and/or maybe Firebase, and I think people could make some really amazing federated or P2P social apps with a very, very small amount of code.
I picture writing a Front-end UI on Flutter that talks to a Back-end like I describe.
PS maybe someone could make a WASM-first (no Dart) version of Flutter?
Most of this is feasible today using Opportunistic IPSec. What's missing is the high-level (Redis, SQLite, MongoDB, etc) application interfaces you're hinting at. Opportunistic IPSec operates at the IP layer, below all of that. There are BSD socket API controls for IPSec, but Opportunistic IPSec was mostly intended to be passive except for an application (optionally) requesting or verifying that a data stream is protected.
Unfortunately, Opportunistic IPSec failed miserably at widespread adoption. The same fate is almost certainly waiting for any similar all-encompassing approach. Wireguard doesn't really help as the vast majority of the complexity and pain exists above the level of the basic stream encryption. (Supporting schemes like Opportunistic IPSec is one reason why IPSec permits direct IP-to-IP encryption without tunneling or layering. One of Wireguard's simplifying assumptions was that it would be used to create VPNs and tunnels; TLS had won the day as a solution for direct, end-to-end encryption.)
I kind of feel like you and I are talking past each other a bit. (And the fact that I don't know any of the technical terminology doesn't help me at all, here.)
I want this Host program she's talking about to be trivial to install for some random end user. And then that user can pick my App from some App Store interface, similar to the Demo in sandstorm.io, and then add Contacts, and then give my App permission to talk to some of their Contacts.
So, the Host program is super sandboxed, and capability-model based...
And I'm also asking for the Contact Management DNS Connectivity system, which I imagine feels roughly like setting up a public/private key pair with PGP, and then feels roughly like setting up a Dynamic DNS.
I don't actually care about specific ports, and how they're actually encrypted, etc. It could connect over WebRTC for all I care. Yes, TLS might work. I hear NAT traversal is a problem to connect peer-to-peer, and I barely know what I'm talking about. I want the Host / DNS / some minimal central servers to take care of that for me.
I feel like the DB interfaces are slightly higher level than the stream level access she was talking about, and would make it slightly easier to do some of the cool stuff I envision. But I feel like providing DB Capabilities is a pretty low bar - it should be relatively easy to do, right?
I'm working on a proof of concept React-ish UI lib powered by WASM. My goal was to make it truly cross platform, for example it should generate ui markups on a headless server as well
Maybe it's by design, but my biggest sticking point with WASM is the inability to modify the code at runtime, at least to my knowledge. This makes it a bad target for dynamic languages where the source -> executable mapping isn't wholly known ahead of time, especially Lisps but also any looking to JIT compile things.
Speaking of Lisp and WASM, IchigoLisp [0] is a remarkably faithful implementation of LISP 1.5 in WAT. Extraordinarily impressive, and inspires even more awe for the original system from the 60s.
Well, that functionality is not included by default, but you can certainly add it yourself. Add a function to your host system (be it a browser, a CLI interpreter, etc) which accepts a wasm module you dynamically create, instantates it, and gives you acces to some function it exports. I don't think any WASM implementations provide such a function by default, but that can be changed easily and is not an insurmountable limitation of WASM.
I was also reminded of Java when it delved into "you don't even know you have a file, it's just a stream". The stream abstraction of course predates Java. But Java is where (IMO) developers really started embracing programming to these kinds of abstract interfaces en masse.
Yes, because most WebAssembly advocacy knowingly ignores the past to sell their agenda.
It isn't only Java, bytecode as execution format goes all the way back to late 1950's, Gosling quite clearly asserts the work that Java builds upon, contrary to the WebAssembly folks.
"Back when I was a grad student at Carnegie Mellon, I had this problem where I needed to have some kind of an architecture-neutral distribution format. We had a bunch of workstations called PERQ machines. The folks who built them were a bunch of hardware guys who didn’t want to do software. The only compiler that they could get for free was UCSD (University of California San Diego) Pascal. So they made the hardware interpret UCSD Pascal p-codes.
My thesis advisor, Raj Reddy, asked me to spend the summer trying to figure out how to get the software from these PERQ machines to run on our VAXs.
I started out writing a little hardware emulator, just to understand the p-codes. Then I realized I could actually write a code-generating program that translated from Pascal p-codes to VAX assembly code.
So I wrote a hardware emulator for the PERQ machine that did hardware emulation by translating, and I spent a bunch of time trying to figure out why it was that the translation actually worked. One of the things that I noticed was that the code that I was getting at was actually better than the code that was coming out of the C compiler. I was quite floored by how well it worked, and I spent a bunch of time thinking about what it was about p-code that actually made it work, versus trying to do this for some other instruction set.
Then fast-forward a bunch of years, when I was trying to do the project that Java came out of. I had to do this architecture-neutral distribution format, and then I just went ka-ching! You know, this p-code translator thing would actually just drop in there."
As another example of hidden agenda, most WebAssembly sales also ignore PNaCL and CrossBridge, only mentioning asmjs as previous art.
Nobody ever claimed it was new. It wasn't new when Java tried it.
And the actual Web-Assembly developers don't ignore that stuff. And even if they did so what? Re-inventing the wheel is common and sometimes something good and new comes out of it.
And it's not like Java is in the browser and WebAssembly is trying to reimplement something that's already available. Java got kicked to the curb and for a reason. If it's such a superior solution go ahead and put it back and show all the people working on WebAssembly what a waste of time it is.
Nah, I appreciate the wonderfull work of those WebAssembly people that allowed me to have Java applets, Flash and Silverligh running again in the browser.
Please show me text by actual core developers that claim something is 100% new that isn't. And I'm not talking about some random articles you find with googling.
So really you have no evidece at all, you are just generally angry at everybody who is involved with WebAssembly because they don't site your work and that makes you bitter. Got it.
> Guess what? Lots of people don't want to write Java.
It's funny that some of the most popular languages these days are Go (crippled Java 1.4) and Rust (Java for frontend web developers who need to be tricked into it) so it seems like lots of people really do want to write Java.
Case in comparison, bpf or ebpf. In that they are both a type of radically different approach on solving the old problem. Bpf being kernel programmability for app developer, wasm being portable execution environment.
While it is reasonable to trust users with their own files, it is unreasonable that the only model of computing offered to those users requires that they then give all of their privileges to every piece of code they run.
It is possible to run code from anywhere without having to trust it, thanks to this new model of computing.