I understand why in 1979 and perhaps until mid 1990s capability OS architecture might have been irrelevant and excessive. But after that, it sounds like the only architecture suitable for the internet age, where you can download and run anything from anywhere. Instead, we're stuck with legacy systems, which now contain layers of layers of abstractions and security measures. User rights, anti-virus software, vetting (signatures, hashes, app-store verification) - all become obsolete or near-obsolete in a capability-based system where a program simply doesn't have access to anything by default. Part of the appeal of virtualization is also due to the fact that it isolates programs (for instance, I only run npm inside Docker container these days, because chances are some package will contain malware at some point).

Part of it is inertia, but part of it is ignorance. Enthusiasts spend tons of money and effort building another GPU enabled terminal or safe programming languages - and maybe that's fine, but I wonder what we could've accomplished if people were simply aware what a well-designed capability OS could be like, because this is literally the only OS paradigm in existence (that I know of) that's even worth any serious effort.

None of those things become obsolete with capabilities.

You still need code signing because users need to be able to grant privileges in a way that sticks across upgrades. The object they want to privilege isn't a set of files on disk but a logical app as defined by (more or less) a brand name+app name even as it changes over time.

You still need antivirus software because users can be tricked into giving capabilities to programs that appear legit but are actually malicious.

Modern operating systems (iOS, Android) are capability oriented operating systems to the extent that makes sense. For some reason there's a meme that says capabilities are a magic wand that solves all security problems, but it's not the case.

If you go through old CS OS texts on the matter, they really didn't have the same understanding of capabilities then as the later object-capabilities (ocap) model would introduce. Typically they would show an access control matrix, note that acls were rows and capabilities columns and note that they are duals of one another. They're the same, acls are easier to manage, done.

OP is arguably the first paper that introduces ocaps. Some of the issues are discussed in "Capability Myths Demolished" https://papers.agoric.com/assets/pdf/papers/capability-myths...

> it sounds like the only architecture suitable for the internet age, where you can download and run anything from anywhere

Wasn’t that the reason why Microsoft went allout against Java? Write once, run anywhere. JVM was a “trojan horse” and theoretically could have dominated the world.

Why do signatures/hashes/app-store verification become obsolete with a capability-based system?

If a binary has the capability to withdraw money from my account, I don't want that capability given to just any binary.

The Market has spoken, and people use standard consumer CPU/GPU-bodge architecture in cloud data centers. Sure there are a few quality of life features different from budget retail products, but we abandoned what Sun solved with a simple encrypted mmu decades ago.

The paper adds little to TCSEC/"Orange Book"/FOLDOC publications. Yet the poster doesn't deserve all the negative karma.

On a consumer CPU/GPU/NPU, software just isn't going to be enough to fix legacy design defects. Have a great day. =3

It looks like you you may be interested in Qubes OS, security oriented operating system relying on strong, hardware-assisted virtualization: https://qubes-os.org. My daily driver, can't recommend it enough.