The scrolling behavior you mentioned is actually a feature, we want to give people time to read the first message before filling up the console.
> The tradeoff is only some performance, there is no security risk. CheerpX used standard WebAssembly/JavaScript/HTML5, there is truly no difference between this and any other Web page you might visit.
I understand that the security model is more like a webpage than a local binary. What I don't understand is:
(1) what is the relative difficulty of escaping a full, local VM vs a local browser sandbox vs microVM container? That is, if you want to run an untrusted x86 binary locally, is CheerpX + browser sandbox really as safe as VirtualBox or firecracker? I suspect there's a speed/security tradeoff happening somewhere.
(2) how complete is the set of operating system APIs available to an x86 running in WASM via CheerpX vs running that same application locally? That is, what local functionality might I sacrifice to use the browser?
(3) what is the nature and magnitude of the performance hit? Obviously you have to load the binary over the network in this demo, but locally-hosted resources should be fine.
(2) We are implementing syscalls and devices as they are needed for the various use cases we are considering. In general even if something is not natively supported in the browser it can still be virtualized to various degrees. In particular CheerpX provides a virtualized FileSystem that does not map to your local files. The same would apply for the virtual disks in traditional VMs though.
(3) We plan to release benchmarks soon, but the level of performance is very promising. Consider that we have been using the Flash plugin as our main benchmark which is very demanding. For the REPL use case the limiting factor right now is I/O performance, but we are already working on this and we thing we will achieve much better results very soon. In general, all aspects of CheerpX performance will improve, we are really not done yet.