[cap-talk] A petname toolbar for Firefox

[Tyler Close]

On Feb 22, 2005, at 2:52 PM, Ka-Ping Yee wrote:

> I think the distinction between naming and trusting is an important
> distinction being missed here.  What you refer to as "untrusted sites"
> are really un*named* sites.  Whether or not i have named a particular
> entity is orthogonal to whether i trust it to do a particular thing.
> (To be sure, when i name something, the name mapping itself should be
> trustworthy, but trust in the mapping is not the same issue as trust
> in the named entity.)  When i name something, that does not imply
> that i trust it.  The name also can be useful to me as an indicator of
> untrustworthiness.

We have a fundamental disagreement over what a petname is.

A petname is a mnemonic for a trust relationship. A petname is *not* a 
mnemonic for an entity. There is no need for you to name the entity. It 
already has a name, a nickname. There is a need for you to name the 
trust relationship, since it enables communication between the user and 
the browser about the trust relationship. That's our purpose here.

When the user is deciding how to evaluate information or actions 
presented by a web page, only the trust relationship is relevant. In 
fact, the user should actively ignore the site's identity. The key 
question is whether or not the user has built up enough trust to 
authorize the site's use of a given personal detail.

The situation is analogous to the way a capability OS implements access 
control. When deciding whether or not to grant a request, a capability 
OS does not consider the identity of the requestor, only whether or not 
the requestor possesses the required capabilities. Similarly, when 
deciding how to react to a web page, the user should not consider the 
identity of the website, only whether or not the trust relationship 
warrants the action. Think of a trust relationship as being like a 
C-list. A petname refers to a trust relationship in the user's brain in 
the same way as a pointer refers to a C-list in the kernel's RAM.

The goal of the petname toolbar is to get the user to start thinking 
about his trust relationships and making effective use of them. To this 
end, we want the user to tell the browser about his trust 
relationships, so that the browser can remind the user about them as 
appropriate. For these reminders to be most effective, untrusted sites 
must not have an associated petname. The absence of a petname makes it 
clear that there is no trust between the user and the website.

The goal is not to make a new namespace for websites. Websites already 
have a namespace and reproducing it is pointless busywork. Presented 
web pages will declare the website's nickname in multiple ways. The 
absence of a petname does not mean that the site is unnamed. It just 
means that there is no associated trust relationship.

I suspect the problem is that you have misunderstood Zooko's Triangle. 
Zooko's Triangle says that no name can have all three of the listed 
properties, but that all of the listed properties can be achieved by 
using a combination of different kinds of names. Zooko's Triangle does 
*not* say that all three kinds of name are names for the same thing. In 
fact, each of the three kinds of name is a name for a different thing. 
The point of Zooko's triangle is that in different scenarios, different 
aspects of identity are relevant, so we can deal with them in 
isolation, without needing to provide all three properties at once. For 
example, when searching Google, only the shared nomenclature is 
relevant. Your trust relationship with the searched for entity is 
irrelevant to Google. When pointing someone to a website, only the 
cryptographic identity of the website is relevant. There's no need for 
a shared nomenclature. Also, the recipient of the pointer will consider 
his own trust relationship with the website, not yours.

The problem we face is that the current PKI conflates all these aspects 
of identity, and kinds of name, into a single name and notion of 
identity. The result of this confusion is phishing. You still don't 
seem to understand this point:

> You're right -- an older version of the warning message did look like
> that, in an article i was writing at the time.  I ended up thinking
> about a variety of possible ways to word the message.  On the whole
> i believe we both agree that the message should not be a command (e.g.
> "You should assign a petname now.") but a statement of fact (e.g. "This
> site is a stranger.")

Your original admonition text was not flawed because of a GUI principle 
of proactive versus reactive interfaces. It was flawed because it 
suffered from name conflation in exactly the same way as the URL 
address bar does and therefore aids phishing just as the address bar 
does. Your original admonition was: "The current site is not one that 
you have named. The name chosen by its owner is PAYPAI.COM." Why should 
displaying the domain name in an admonition be significantly less 
confusing than displaying it in the address bar? Moreover, why is the 
site's chosen nickname even relevant to whether or not the user should 
trust the website?

I made this point to you when reviewing your article, but you never 
responded and it seems the point didn't fully stick. Petnames are not 
about naming websites. Petnames are about remembering and applying 
trust relationships.

Tyler

---
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/