Zooko’s Triangle

Zooko's triangle is explained in several places

Zooko’s triangle is, among other things, a user interface concept for storing, managing, and communicating, cryptographic capabilities.

Zooko's triangle solves half the problem: provides a trusted path. If you trust Bob, and Bob trusts Carol, you can trust that Bob's introduction to Carol will in fact bring you to the correct Carol.

This, of course, assumes a browser is somehow able to use Zooko style links, rather than PKI links.

The problem then becomes having large number of trusted introduction - a map between human phrases, and documents containing information about globally unique identifiers that are relevant to that phrase: Something like Wikipedia, but without centralized authority forbidding "original research", aka any deviation from official government truth, and something like a search engine

To solve the problem of making Zooko style links useful, we have to solve the problem of providing global data that is not state dominated.

Past experience with cryptographic capabilities is that if users are expected to consciously and intentionally use them, they screw up, that even experts screw up, and that end users are not only reluctant to use them correctly, but find it profoundly difficult to use them at all that even expert users find them a pain, as for example the regular unpleasantness of installing a certificate on a web server so that it can do https.

Zooko’s triangle, correctly implemented, should hide from users that they are using cryptographic identifiers, or indeed any globally unique identirfier.

Because globally unique identifiers have become almost as ugly as cryptographic identifiers, we have already implemented interfaces that hide globally unique identifiers, for example the bookmarks folder, the buddy list, and the email contacts list. And since those identifiers are already hidden, they can be cryptographic, giving the user many benefits, and no extra grief.

We can do this with not one extra click for security, and indeed will have to do so, for experience has proven that if we ask the user for extra clicks for security, the user becomes frightened and confused, and even supposedly expert users do not provide those extra clicks.

In order that references to objects can be securely transmited across trust boundaries, they need to be cryptographic capabilities

You don't want people sending you spam pretending to be your webmaster, or your email host, or your employer, or your bank. You want to share files with certain people, but not always with the entire world, you want to give some people, but not others, the ability to edit particular files. When somone trusted recommends a bank, or a firm, you don't want some scammer connecting you to himself, instead of the bank you are trying to connect to.

IM buddies, email contacts, and important web pages should be cryptographic capabilities. When you click on a link, it should take you to the web page the author you are clicking on intended. When you receive a message that purports to be from an entity you have a relationship with, it should be from that entity, and when you receive a message from an entity you do not have a relationship with, it should be obvious you do not. All messages should have in the headers "Regarding .....", which refers to a particular capability to contact you - which usually is the particular capability to contact you contained in some previous outgoing message sent by you.

Further, if we had a way of routinely and easily handling cryptographic capabilities, lots of things that are now inconvenient and unsafe, such as web money, could be made considerably easier and safer.

These documents are licensed under the Creative Commons Attribution-Share Alike 3.0 License