[cap-talk] A petname toolbar for Firefox

[David Hopwood]

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.
> 
> In my opinion, the petname system's job is to maintain reliable name
> mappings for me, not to make assumptions about trust.  In general,
> software can provide me information (whether that consists of gathering
> external information or augmenting the reliability and capacity of my
> own memory) to help me decide who to trust, but it can't decide *for*
> me who i trust.

I agree 100%.

> Therefore, yes, interacting with an untrusted site will be a common task,
> and that is something we cannot (and should not try to) change.  But
> interacting with an unnamed site does not have to be a common task; in
> fact, in order to establish the name mapping system as a reliable and
> natural part of normal workflow, we should strive to make that uncommon.

Some users may want petnames to be assigned only to a small number
of commonly used sites, and others may want most sites to be named.
These are both reasonable ways to use a petname system, IMHO.

Either way, the distinction between "untrusted" and "unnamed" is essential.
A petname system is not in the business of keeping track of how far the
user trusts any site; only of which sites they have named. The user
interface should avoid giving any other impression.

Tyler Close wrote:
> 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.

I could be wrong, but I don't think the disagreement is fundamental.
A petname system keeps track of a 1-1 mapping between a user's petnames,
and the cryptographic identities of web sites. The user keeps track
of (remembers) a 1-1 mapping between petnames and trust assessments.
The system and user thereby cooperate to implement a 1-1 mapping
between cryptographic identities and trust assessments, which is what
the user needs in order to use the web securely.

> 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 user should certainly ignore the site's cryptographic identity.
However a trust assessment (in a user's memory) has "identity" in the
technical sense that we can model it as having a state that can change
over time, such that trust assessments of different web sites have
distinct states.

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

That's a use case that the petname system is intended to support, but
it supports it only by mapping between cryptographic identities and
petnames, leaving the user to do the rest. It would be completely
misguided (IMHO) for a computer system to attempt to model trust
assessments directly. To the extent that things like PGP and PPP
("Platform for Privacy Preferences") attempt to do that, they do it
badly.

Jed Donnelley wrote:
> Hmmm.  One thing about that, I agree with others that we don't want
> to make the Petname mechanism appear as a burden to be avoided.
> I'm quite content to wade into any new world of better name binding
> by starting to assign Petnames to sites that I've developed some
> amount of trust for (bank, broker, human resources, paypal perhaps,
> some shopping sites with a relationship) and use the Petnames
> to help assure myself that I'm not being mislead by phishing, but
> *not* to assign Petnames to the vast majority of sites that I interact
> with.
> 
> As I mentioned in my other email, I think it would help to distinguish
> between "unnamed" as you say and "untrusted" (an active designation)
> sites in addition to sites with assigned Petnames.

In discussions of the system, yes, but the system itself is not concerned
with which sites are trusted or untrusted (for any purpose).

> I also think
> help with name collisions would be useful - something along the
> lines of what I think Bill Frantz mentioned at one point.
> 
> For me (blue sky) a simple thing would be to allow the 'Petnames'
> "untrusted" and "unknown" to be overloaded and perhaps to make
> them more visible (e.g. Bold or red or something like) with "unknown"
> the default (no Petname in the database).

I disagree with there being any distinguished "untrusted" name.
There is no point to this; it would be like the "Restricted sites"
zone in Internet Explorer, in that a site can trivially avoid being
in that zone (e.g. by using a different key for every session).

The appearance of the petname field when no name has been assigned
should be neutral. It is not unusual or undesirable to interact with
an unnamed site. It would be quite sufficient for the petname field
to be blank in this case. E.g. for an assigned name:

         Petname: [ amazon     ]

and for an unassigned name:

   Enter petname: [            ]

> I understand that I'm fiddling with UI niceties here

The UI niceties are important.

> and that I'm convinced
> of the base value of Petnames - though perhaps not as overarching a value
> as some seem to think has been implied by the discussion and by the
> proposed "First point of consensus".

Actually I thought that the "first point of concensus" understated the
value of petnames.

> I'm not sure this will help, but how about if I throw some more
> words into the mix in an effort to push us more toward consensus:
> _________________________________________________________
> The Petname mechanism is a tool that allows users to associate a
> name (the "Petname") with a safe binding to a known Web site.
> Such a name binding can help users avoid "phishing" attacks.
> If a user sees a bound Petname in the toolbar they can have confidence
> the site they are communicating with is the same site that they gave
> the Petname to.

The previously suggested wording (taking into account my comment about
phishing vs web site spoofing, on which there seemed to be agreement), was:

| A petname toolbar records and displays the relationships between a user
| and a web site. This indication enables user detection of [web site
| spoofing attacks].  A domain name display fails to communicate this
| information, leaving the user vulnerable to a [web site spoofing attack].

Your suggestion seems to be mainly a wording variation; what do you see
as being the substantive difference?

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>