[cap-talk] A petname toolbar for Firefox - big issues still outstanding?

[Jed Donnelley]

At 09:25 AM 2/23/2005, David Hopwood wrote:
>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....
>
>I agree 100%.

I also agree with the above (just another data point).

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

I agree, though for my own money (time) I think I would tend to use
Petnames only for organizations that I am developing some sort of trust
relationship with.  For organization with no such trust relationship I have
no particular reason to both to assign a Petname.

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

Agreed.

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

That sounds right to me, though as per the recent change I would
replace "web site" with "web organization" or the like - subject to
agreement on the Organization (O) binding.

>Jed Donnelley wrote:
>>...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 agree.  I withdraw my suggestion of having a distinct "unknown" in
addition to "untrusted".

Instead I suggest changing the current "untrusted" to "unnamed".

I believe that would help a little in making clear this distinction that
we seem to be coming (mostly?) to about clearly separating the
binding that the Petname can do for us from the trust relationships
that we must develop on our own.

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

I agree - as I noted above by withdrawing that suggestion.  However,
I would like comment on the distinction between the current
"untrusted" default vs. the "unnamed" default that I suggest.

>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 could accept that as well.  I just think "untrusted" makes it a bit
loaded - e.g. suggesting that any named site is "trusted", which
as we have noted may not be the case.

>>I understand that I'm fiddling with UI niceties here
>
>The UI niceties are important.

I agree.  I just wanted to make clear that I believe there is a base
value being provided by the Petnames that will likely show through
even if the UI tuning isn't "perfect" - whatever that means.

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

That's a matter of interpretation perhaps, but it certainly did seem to
stir up a lot of this discussion about the Petname mechanism
being a pretender for providing help developing trust relationships.
That's the aspect I was referring to when I mentioned an "overarching"
value.

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

The only thing I was trying to clarify is the fact that the only help the 
Petname
provides is to provide confidence that an organization previously visited is
the same organization when visited in the future.  Either is fine.  Now 
with the
distinction between Web "site" and Web "organization" your version might read:
________________________________________________________________
A petname toolbar records and displays the relationships between a user
and an organization on the Web. This indication enables user detection of
web spoofing attacks, e.g. "phishing."  A domain name display fails to
communicate this information, leaving the user vulnerable to a spoofing 
attacks.
_________________________________________________________________

Are there any big picture disagreements still out there?

--Jed http://www.webstart.com/jed/