All these scientist types are talking about the “theory of evolution.” And they’re forcing it down our children’s throats, as if it were truth. But it’s just a theory! It says so in the name. Well, we have our own theory; why can’t that be taught just as well?

See the problem with that argument? It’s actually a fairly subtle problem, specifically that “theory” means something very different when a scientist says it vs. when a layperson says it. The entire argument is based on a misinterpretation of that one word.

Your argument has the same problem. When crypto experts discuss “trust”, they mean something completely different than the layperson’s definition of trust, and far closer to your goal. The entire trust model of PKI is the following:

• Users (AKA “Relying parties”) trust the CA to verify the identity of the certificate issuee.
• The CA may also, at their discretion, delegate their ability to verify the identity of other parties to the issuee. (i.e., issue more certificates, possibly subject to some limitations).

If you don’t see how that’s different from saying “A valid certificate implies that the site that uses it is trustworthy”, read it again. Heck, if you didn’t notice that every time that paragraph used the word “trust”, it always applied to one party performing one particular action.

Now suppose that Verisign hands you a certificate saying “The one who holds this certificate owns sworddance.com”. Does this mean that I should trust the information that I obtain on sworddance.com to be correct? No. Heck, unless I trust Verisign to verify identities, I have no reason to even believe sworddance.com is yours.

That said, you do have a good point. The threat model (which has nothing to do with “trust”, by the way) for applications is hopelessly outdated. It came from the early 60′s, when the only way for a program to appear on a computer was for your computer manufacturer to send out the Field Circus to put it there, or for you to put it there yourself. Then came the ARPANET, which begat the Internet. Now, we need a very different threat model, but AFAIK, we haven’t figured out what that threat model is.

Once we figure that out, capabilities (the mechanism that you’re suggesting) may in fact be the right solution. But you can’t even start thinking about solutions until you know what the problem is.

On a tangential note, Linux actually does implement capabilities. Not to the full extent that you are looking for, but enough of it that you can implement the rest in userspace. Interestingly, they aren’t actually used that much, because they are far too complicated to use. The UI is too unweildy, and when I sit down in front of my computer, my goal is not usually to figure out how to give some process least privilege. My goal is to get something done, and if the security system gets in the way, well, security be damned. (footnote: I actually spent two days trying to figure out how to delegate the authority to administer the network to a qemu process I was running, without giving it blanket filesystem access or anything. Two days. In the end, I could not get the damned thing to work, so the QEMU process had to run as root.).

Also, note that, even if all applications use conditional trust (aka capabilities), there’s one application that, by definition, has to be given blanket trust: your OS (or rather, whatever bit of your OS handles the security model). Put differently, you have to have permissions in order to delegate them.

So, no. Trust is not the problem. Fighting against trust will get you nowhere, because we’ve already learned that blanket trust is bad (except where it’s absolutely necessary). Instead, you should be fighting against outdated threat models, and the fact that all of our security UI is not the problem.

ah the righteous indignation, “how dare you have to pay for those lazy Coloradoans?”

You really should buy from Canada or some place overseas. Of course be sure to never buy anything local to avoid having to pay local sales tax.

You could always go Galt and refuse to work – thus avoiding all taxes.