The nanoprocess concept seems like a big deal.
I remember reading about a vulnerability in the unix utility "strings". The code is incredibly simple at first glance, but it had a dependency to detect the filetype, and that dependency was not safe on untrusted input.
At that moment I realized that unix security was fundamentally flawed. A utility that does nothing but read its input and write the output shouldn't have permission to do anything else.
This seems like a positive development. I have two items on my wish list:
- tail recursion elimination. There's a draft proposal but only one engine implements it at the moment which is blocking further progress.
- RISC-V backend for Cranelift (TBH, I'm sure someone will do it eventually).
See here for discussion on Wasmtime team moving from Mozilla to Fastly: https://news.ycombinator.com/item?id=24897641
The focus on building a capabilities based API is so good.
Most platform apis let you just do stuff. Open /home/user/my-image.png. Ok.
The capabilities model re-orientes operations like this. The app starts with some kind of handle to a starting directory. Maybe it's to /, the root, maybe it's to /home/user, the user directory. Whoever has a reference to that directory handle can use it to open files / other directories inside that directory, but can not go upwards!
So if you have a file-saving middleware, you can be sure, whatever libraries that middleeware uses, that it will never write to anything other than the directory you give it.
This is a subtle & small change, with massive impact. Most OS have a parallel system-call that works similarly, openat(2), which is built around this idea of directory handles.