Subgraph OS: Adversary resistant computing platform

That is true, but there might be a point where we have languages, securer-os, frameworks or libraries, where it is simpler than hardening existing software, and I think it will look similar to typed functional programming.

IMHO sandboxing is popular because OS have failed - or maybe it was just out of scope as we may have underestimated the big range of attack vectors - in isolating processes that may be "evil". Sandboxing at the moment is extremely low-level, if you are paranoid about security you probably sandbox full Linux in some hardened kernel-thing (sel4 and similar approaches - I am not even sure if sel4 is used in production), and that is far from trivial, as you have to bridge the "userspace-style" Linux to the HW, which Linux wants to talk do. If you want to secure Linux from the HW itself (or even provide a better alternative) you have to rewrite large parts of it (drivers) and they are mostly very specific to the Linux API.

Now less paranoid people can use something like Docker/Linux-Containers/... and maybe a combination of libraries and distributions (like Subgraph, etc.), but Docker's isolation security record is controversial. Sure if setup correctly it is probably more secure than plain processes/JVMs (this is also controversial), but it just feels hacky and feels like an afterthought that might not be able to guarantee the security it advocates (I hope I am wrong here).

As a programmer you often know many constraints about your software, that are extremely hard to communicate (currently), so you skip stating this constraints and your software has attack vectors that might be avoidable in the first place.

Genode is largely kernel agnostic, being an "Operating System Framework" -- you can run it on Linux, variants of L4, seL4, Muen, and more.

When you jail a UNIX process, you start from a model that gives you full access to everything, and gradually revoke access until you're convinced it's secure. There are all sorts of things you might overlook. For instance, if it's just a chroot, there's no network isolation; an app can connect to a server listening on localhost, and it looks like it's coming from localhost. It can connect to a server on the local network, and it looks like it's coming from the host (which is bad if you have, e.g., a corporate network that lets you access interesting data without logging in, or a home router with a default admin password, or many similar cases).

And if you introduce a new mechanism, the chroot probably gives you access to it. For instance, if the chrooted app is able to access my X11 session, it has a ton of powers; it can keylog everything I do, for instance. Even if I mark it "untrusted" a la ssh -X, it has complete powers over everything else that's "untrusted". You could imagine an X11 designed differently, but X11 was designed for trusted apps. Another important case is system calls; a chrooted process has access to every system call, including every vulnerability that might be present. (On some OSes you can restrict what system calls the process can run, but it's still pretty coarse-grained.)

The web starts from the ability to render formatted text with links, which is very close to zero. Everything else is—at least in theory—added from there when safe. Images are safe. Playing audio is pretty safe. Recording audio is probably not safe without permission. (A typical desktop API won't have an easy way to allow one but not the other, and certainly won't have a permission prompt.) Rendering graphics is fine. Rendering 3D graphics is potentially fine, hence WebGL. Rendering graphics on top of someone else's tab is a definite no. Moving your window around or removing its borders is also a definite no. Becoming full-screen requires notifying the user of what just happened. (Again, a typical desktop API won't distinguish these cases and won't give you an easy way to exit full-screen.)

In particular, the web does restrict an app's ability to access the web. An app can freely access its own origin, but it cannot freely access other sites. If http://wiki.internal/ has sensitive data that doesn't require login, a site on the public web cannot retrieve data from there, without the consent of that site. (And the web has already implemented a pretty robust and involved way of handling cross-origin resource sharing.)

If you stick all these things into a desktop API, fantastic! But the web platform is already there, with a number of competing implementations that are all pretty good.