Unfortunately there are problems with running it on the web (and many problems with its design, and problems with implementations), as well as problems with nat

Unfortunately there are problems with running it on the web (and many problems with its design, and problems with implementations), as well as problems with native permission models of some systems, too. For example, it is not very good working for: command-line with pipes, non-Unicode character encodings, non-USB devices, non-HTTP(S) protocols, working local files without internet connection, interaction with other local programs in a good way, etc. Permissions need not be asking every time (if user will configure it to always allow or deny or other settings), and need not only be "allow"/"deny"; for example, if it requests the camera access then the user might enter a command to use instead, which might access the camera (possibly with filters such as fault simulation), or do something else such as returns a still picture (which you can use if you do not have a camera, for example), and this can be "wired" by the user configuration if not wanted to enter every time. Disk space is going to matter for any program that stores files, although one which is designed well will allow the end user to specify a disk quota for this program if desired, and will also allow specifying default disk quotas in the manifest, in order that you can use it without needing to know about these things and manually set them up, too. I had tried to make the specification of "VM3" which is meant to, among other things, solve these problems. A program can be install or just run, and all I/O must use extensions, which makes both extensible capabilities and highly user configurable capabilites. The same is true for program entries (e.g. command-line, GUI, etc). There are also some other minor things I had done differently due to I think being better than what some other designs are working.