wallet/docs/names/true_names_and_TCP.md

---
lang: en
title: True Names and TCP
---
Vernor Vinge [made the point](http://www.amazon.com/True-Names-Opening-Cyberspace-Frontier/dp/0312862075) 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 addresses 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 meaningful.

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
   because 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.

   Because security (ssl, https) is constructed below the level of
   a connection, because 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”?

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, and will undoubtedly tell me I am a complete moron for using it in the manner that I intend to use it, but barging ahead anyway:

A “capability” 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 the
possessor of the capability to do stuff to something, or get
something.  Capabilities are usually obtained by being passed along
the communication channel. Capabilities are usually obtained from
capabilities, 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 capability.

This definition leaves out the issue of security – to provide security, capabilities need to be unforgeable or difficult to guess.  Capabilities are usually defined with the security characteristics central to them, but I am defining capabilities 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 capability – it is a
communication channel between a process and the file
management system.  Suppose we are focussing on security and
access management 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.

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 many existing definitions of security by capabilities.