Mike's law of capabilities

Any sufficiently popular computing environment contains an ad hoc, informally-specified, bug-ridden, slow implementation of capability based security.

In a recent Hacker News thread[1], I quoted from the source article

Continuing a legacy is an honorable task, except in programming.

This is the most important of the items in the list. The "upgrade or you're unclean" ethos has some very deep roots. It goes all the way down to the security model of our operating systems.

It was perfectly reasonable to assume that a user knew what they were doing with their own files back in the days when Unix was written. That wasn't assumed in the world of mainframes, which were designed to multiplex hardware across tens, hundreds, or even thousands of jobs. In mainframes, your job is explicitly given resources to use and a run time environment. No matter what went wrong, a job run for Acme Inc couldn't corrupt the files of Bob's Distributor.
We don't have that... we've been lead to believe that we just have to be pure enough, our code has to be perfect enough, and defect free, in order to have safety. We blame everything except the OS, mostly because we don't want to cast doubt on the wisdom of Linus, and the sanctity of Linux.
We recreate the mainframe model, over and over, in part, not in whole. It's like Greenspun's 10th rule[2].

Any sufficiently popular computing environment contains an ad hoc, informally-specified, bug-ridden, slow implementation of capability based security. That's why we have Virtual Machines, Containers, and now WASM... which I hope actually manages to fend off the stupidity of letting an application decide which files to access.

We need to make better choices. Legacies are a choice, lots of old stuff is tossed by kids all the time, the legacies are the good things kept from the past. Keeping legacies alive is a choice, let's chose wisely.

[1] https://news.ycombinator.com/item?id=32935466
[2] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule