- was designed with a lot of tight system integration foremost, sand boxing being secondary
- a ton of the sandbox enforcement where checks run in the same VM/code as the code they where supposed to sandbox, like you Java byte code decided if Java byte code should be able to access file IO etc.
- Java Applets are, at lest for somewhat more modern standard, a complete security nightmare _in their fundamental design_, not just practically due to a long history of failure.
- a lot of the security design was Java focused, but the bytecode wasn't limited to only representing possible Java code
- Java "sandboxing" targeted a very different use-case/context the "WASM replace containers" blog is speaking about, mainly the blog is about (maybe micro-) servies while Java sandboxing was a lot about desktop application. I.e. more comparable with flatpack and their sandboxing is also (sadly) more about compatibility then security (snap does that better, but has other issues).
And especially the last point one is one to really important as we are not speaking about WASM replacing sandboxing e.g. for dev tools and similar but sandboxing for deployment of micro services written with it in mind. In such context
1. you (should))always run semi trusted code, not untrusted code
2. when giving access to other resources (e.g. file system) it's often in a context where you normally don't need any form of dynamic access management (like you need on a desktop) which means _all the tech underlying to containers can be used with WASI_. Like there is no reason not to still use cgroups, dropping privileges and co integrated in your WASI VM in the same way docker and co uses them.
3. (I kinda thing) there is a (subtle/very slow) trend to not rely only on container isolation but e.g. have a firecracker micro vm run multiple closely coupled containers (a pod/side care container) but place not closely coupled containers in different micro VMs.
The true challenge isn't WASI, but that it's competing with docker->kubernets where docker is "one thing fit's all (badly)" solution which can not only run your services but can also run all kind of dev tooling, legacy applications etc. without requiring any changes to them and can (badly but often good enough) simulate your deployment locally with compose. Then to make the competition hard kubernets has been become somewhat of a "standard" interface to deployment, especially in the cloud, this might suck, but also mean you use OIC images both locally in in production. And that is what the WASI for service sandboxing use-case is competing with OIC images and software running them, nut just docker.
> - was designed with a lot of tight system integration foremost, sand boxing being secondary
> Java sandboxing was a lot about desktop application
I think this is a false history. Java was designed for interactive television. As in cable television set top boxes receiving apps broadcast over the cable and executing them.
Javas focus has shifted multiple times through history and at least starting with it becoming generally available hasn't really been a single purpose thing, so I don't think this is really making any difference in the argument.
But I could have formulated some thing better:
> sand boxing being secondary
sand boxing for _security_ being secondary, for compatibility it was primary (e.g. like flatpack) and even if it wasn't what was seen as acceptable security for the 90th isn't anywhere close to it for today in most cases
Also "tight system integration" was in context of "highly sandboxes" things, which isn't necessary quite the same. E.g. in context of "highly sandboxes" things rusts standard library and support for C-API libraries is tightly system integrated. But if you speaking in a context of e.g. windows you need to add the official bindings to the various MS specific system libraries to count as "tightly integrated" and even then you could argue it's not quite there due to not having first class COM support.
Anyway I think the most important takeaway form Java sandbox security is "never run the code enforcing your sandbox as part of the inside of your sandbox" because a huge amount of security issues can be traced back to that (followed by the way Java applets have been embedded in the browser wrt. "privileged" applets being really really bad designed in a ton of ways).
It's a similar but quite different solution.
Java
- was designed with a lot of tight system integration foremost, sand boxing being secondary
- a ton of the sandbox enforcement where checks run in the same VM/code as the code they where supposed to sandbox, like you Java byte code decided if Java byte code should be able to access file IO etc.
- Java Applets are, at lest for somewhat more modern standard, a complete security nightmare _in their fundamental design_, not just practically due to a long history of failure.
- a lot of the security design was Java focused, but the bytecode wasn't limited to only representing possible Java code
- Java "sandboxing" targeted a very different use-case/context the "WASM replace containers" blog is speaking about, mainly the blog is about (maybe micro-) servies while Java sandboxing was a lot about desktop application. I.e. more comparable with flatpack and their sandboxing is also (sadly) more about compatibility then security (snap does that better, but has other issues).
And especially the last point one is one to really important as we are not speaking about WASM replacing sandboxing e.g. for dev tools and similar but sandboxing for deployment of micro services written with it in mind. In such context
1. you (should))always run semi trusted code, not untrusted code
2. when giving access to other resources (e.g. file system) it's often in a context where you normally don't need any form of dynamic access management (like you need on a desktop) which means _all the tech underlying to containers can be used with WASI_. Like there is no reason not to still use cgroups, dropping privileges and co integrated in your WASI VM in the same way docker and co uses them.
3. (I kinda thing) there is a (subtle/very slow) trend to not rely only on container isolation but e.g. have a firecracker micro vm run multiple closely coupled containers (a pod/side care container) but place not closely coupled containers in different micro VMs.
The true challenge isn't WASI, but that it's competing with docker->kubernets where docker is "one thing fit's all (badly)" solution which can not only run your services but can also run all kind of dev tooling, legacy applications etc. without requiring any changes to them and can (badly but often good enough) simulate your deployment locally with compose. Then to make the competition hard kubernets has been become somewhat of a "standard" interface to deployment, especially in the cloud, this might suck, but also mean you use OIC images both locally in in production. And that is what the WASI for service sandboxing use-case is competing with OIC images and software running them, nut just docker.