The reasons we're "stuck" are multifaceted: sheer volume of code, unsafe languages, monolithic kernels, poor UX of security features, and inadequate automated testing (especially of kernel code).
seL4 solves the message-passing performance problem of microkernel designs and offers strict capabilities. One major gotcha in most microkernel designs is the need for multi-process side-effect locks, transactions, and rollbacks for mutating hardware state coherently.
MINIX 3 made some progress by implementing a NetBSD userland.
PS: It's a shame USB didn't include a write-protect tab by default.
It was easy to quantify your risk, as it only had write capabilities to the floppy disks without write-protect tabs.
That is what made it possible to just try anything, and not worry about it.
This is obviously only true of MS-DOS on purely floppy-based systems.
Years ago, it really saddened me to realize that a Dual Floppy IBM PC running MS-DOS was actually the high water mark of secure general purpose computing for the masses.
Capabilities is about associating the permission to do a thing with the handle you'd do it through; unrelated parts of the program don't know how to talk about the thing so can't do it.
I think the former is the system dialog that comes up when the app officially requests the capability, while the latter is an app dialog—which they pop up instead of officially requesting the capability because if you say "no", that setting is saved, and the app can't officially ask again.
This way, they get to bug you every single time until you say "yes".
I have seen applications that also say it in their own UI, but Apple does display a specific dialog telling you that it was blocked, and if you want to enable it, you need to go to the settings and do so.
And it is even document on official Apple pages, so I doubt this is application code: https://developer.apple.com/library/archive/documentation/La...
From https://developer.apple.com/library/archive/documentation/La...
Imagine instead, your text editor called the system to get a capability, which then opened the same dialog, and gave a capability (like a file handle) to the text editor for its use. If it got confused, or subverted, the only thing it could mess up would be that one file.
It will never happen. We’re simply not smart enough to create such a system that won’t be too much of an inconvenience for developers and users.
And the underlying cause is that “too much of an inconvenience” is any inconvenience at all.
Unix, and everything modeled on it assumes competent users running applications they wrote for their own use. Anything that follows this model can't ever be made secure without rendering it useless well before then.
Capability Based OSs can be just as easy to use as Unix, except for the core assumption that code is to be trusted. When I say capabilities, I mean fine grained ones, like access to a file, which could then even be filtered down to access to part of a file, or read-only, etc.. then passed on to other tasks that require it. It makes permission composable, like being able to make $16.23 from exact change, instead of handing your wallet to the cashier and hoping for the best.
Until Capability Based Security becomes the norm, no nodes on the internet are safe, and it will always be an excuse to clamp down on freedoms. If we are to have freedom, we have to migrate to Capability Based Systems, and then continue on to win the war for general purpose computation, which most people don't even realize is already in play.
If you're old enough, remember shareware and dual floppy drive PCs? You could try out anything, and not worry a bit, because you didn't risk everything to the code you picked up for $2 on a shareware disk, you could always return to a known state. Capability Based Security makes that possible, even with mobile code on the internet.