True Names and TCP

Vernor Vinge made the point that true names are an instrument of government oppression. If the government can associate your true name with your actions, it can punish you for those actions. If it can find the true names associated with a transaction, it is a lot easier to tax that transaction.

Recently there have been moves to make your cell phone into a wallet. A big problem with this is that cell phone cryptography is broken. Another problem is that cell phones are not necessarily associated with true names, and as soon as the government hears that they might control money, it starts insisting that cell phones are associated with true names. The phone companies don't like this, for if money is transferred from true name to true name, rather than cell phone to cell phone, it will make them a servant of the banking cartel, and the bankers will suck up all the gravy, but once people start stealing money through flaws in the encryption, they will be depressingly grateful that the government can track account holders down and punish them - except, of course, the government probably will not be much good at doing so.

TCP is all about creating connections.  It creates connections between network addresses, but network adresses correspond to the way networks are organized, not the way people are organized, so on top of networks we have domain names. 

TCP therefore establishes a connection to a domain name rather than a mere network address - but there is no concept of the connection coming from anywhere humanly meaningfull. 

Urns are “uniform resource names”, and uris are “uniform resource identifiers” and urls are “uniform resource locators”, and that is what the web is built out of. 

There are several big problems with urls:

  1. They are uniform: Everyone is supposed to agree on one domain name for one entity, but of course they don't.  There is honest and reasonable disagreement as to which jim is the “real” jim, becaŭse in truth there is no one real jim, and there is fraŭd, as in lots of people pretending to be Paypal or the Bank of America, in order to steal your money.

  2. They are resources: Each refers to only a single interaction, but of course relationships are built out of many interactions.  There is no concept of a connection continuing throughout many pages, no concept of logon.  In building urls on top of TCP, we lost the concept of a connection.  And becaŭse urls are built out of TCP there is no concept of the content depending on both ends of the connection – that a page at the Bank might be different for Bob than it is for Carol - that it does in reality depend on who is connected is a kluge that breaks the architecture. 

    Becaŭse security (ssl, https) is constructed below the level of a connection, becaŭse it lacks a concept of connection extending beyond a single page or a single url, a multitude of insecurities result. We want https and ssl to secure a connection, but https and ssl do not know there are such things as logons and connections.

That domain names and hence urls presuppose agreement, agreement which can never exist, we get cybersquatting and phishing and suchlike. 

That connections and logons exist, but are not explicitly addressed by the protocol leads to such attacks as cross site scripting and session fixation. 

A proposed fix for this problem is yurls, which apply Zooko's triangle to the web: One adds to the domain name a hash of a rule for validating the public key, making it into Zooko's globally unique identifier.  The nickname (non unique global identifier) is the web page title, and the petname (locally unique identifier) is the title under which it appears in your bookmark list, or the link text under which it appears in a web page. 

This, however, breaks normal form.  The public key is an attribute of the domain, while the nickname and petnames are attributes of particular web pages - a breach of normal form related to the loss of the concept of connection - a breach of normal form reflecting the fact that that urls provide no concept of a logon, a connection, or a user.  

OK, so much for “uniform”.  Instead of uniform identifiers, we should have zooko identifiers, and zooko identifiers organized in normal form.  But what about “resource”, for “resource” also breaks normal form. 

Instead of “resources”, we should have “capabilities”.  A resource corresponds to a special case of a capability, a resource is a capability that that resembles a read only file handle. But what exactly are “capabilities”? 

Since people with different concepts about what is best for computer security tend to disagree passionately and at considerable length about what the word “capability” means, I shall now coin a new word: “kapability”: 

A “kapability” is an object that represents one end of a communication channel, or information that enables an entity to obtain such a channel, or the user interface representation of such a channel, or such a potential channel. The channel enables to possessor of the kapability to do stuff to something, or get something.  Kapabilities are usually obtained by being passed along the communication channel. Kapabilities are usually obtained from kapabilities, or inherited by a running instance of a program when the program is created, or read from storage after originally being obtained by means of another kapability. 

This definition leaves out the issue of security - to provide security, kapabilities need to be unforgeable or difficult to guess.  Capabilities are usually defined with the security characteristics central to them, but I am defining kapabilities so that what is central is connections and managing lots of potential connection.  Sometimes security and limiting access is a very important part of management, and sometimes it is not.

A file handle could be an example of a kapability - it is a communication channel between a process and the file management system.  Suppose we are focussing on security and access managemnet to files: A file handle could be used to control and manage permissions if a program that has the privilege to access certain files could pass an unforgeable file handle to one of those files to a program that lacks such access, and this is the only way the less privileged program could get at those files.  If used in this way, if passed around to manage security and control access, such a file handle would be a kapability, and also a capability. 

Often the server wants to make sure that the client at one end of a connection is the user it thinks it is, which fits exactly into the usual definitions of capabilities.  But more often, the server does not care who the client is, but the client wants to make sure that the server at the other end of the connection is the server he thinks it is, which, since it is the client that initiates the connection, does not fit well into existing definitions of security by capabilities.  Hence the need for a new definiton and a new word, a word that covers all cases, that the server cares or does not care, and that the client cares or does not care. 

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