[cap-talk] Define petname

[Ian G]

Jed at Webstart wrote:

> At 09:10 AM 2/23/2005, Ian G wrote:
>
>> 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.
>>
>>
>>
>> Well!  And there was I thinking a petname was a
>> local and private name for a local and private
>> resource.
>
>
> From my perspective there's more fire and fury in
> this exchange than substance.


Maybe :-)

> You refer to a "local and private resource".  Can't
> that resource be a trust relationship?


Well, let's back away here a bit and think about it.

I'm thinking of it from the pov of a developer.  I want
to build it.  ("what other perspective is there?")  So
for me, a petname can only refer to a local defined
resource, because a) it has to be stored with the
petname to make any sense, and b) if it is not
defined it can't be tractably stored.  So, a key, a URL,
a domain, a hash are all starting points.

Tyler is thinking of it from the pov of a user.  ("what
other perspective is there?")  For the user, she sees
the petname and thinks of ... whatever she thinks of.
Which is the point, as she is concerned to map some
simple thing (a name, a logo) to something complex
("trust", a brand, a memory, a fear).

So when Tyler says the petname maps to trust, that's
from one perspective.  The problem is, as a builder,
I can't map that perspective to code.  All I can do is
map the petname to a local resource.

Now, if the user decides that mapping generates
trust then well and good.  But the user can decide
that the mapping generates some other thing, like
fear, brand, memories, reminders, etc etc.

Which then leaves open the question of whether
the petname *only* maps to trust.  I don't think it
can.  Even if we were to build it, it is up to the
user to map it to trust.

>> Could you define relationship, and define trust?
>
>
> I think dictionary definitions suffice:
>
> 1.  Relationship: a state involving mutual dealings between entities


So, relationship could be "a set of dealings between
two or more parties."

> 2.  Trust: Confidence based on past experience.


2.a  Experience:  a judgment over a relationship.

2.b  Judgement:  a compressed human opinion over
a dealing or set of dealings.

2.c  Trust:  an expectation that judgments over
future dealings will match Experience.


Which would lead me to suggest that while the
machine can deal with relationship, and it may
be able to record Judgement, it is less likely to
be able to deal with Experience, and even less
likely to be able to encompass Trust.

Ergo, if a petname points *only* at Trust, this is
all in the user's eye.

>> I for one generally try and eliminate trust from
>> serious conversations as it quickly slips into a
>> definition of "what I want it to mean" which then
>> means we've moved over to selling, not building.
>
>
> I don't know, it seems pretty simple to me and has
> nothing to do with selling.  Perhaps if you're concerned
> about how to develop such trust, but there again that
> isn't the business of the Petname but of the user.
> The user develops trust in the relationship, the
> Petname provides the best technical assurance
> that we can provide that the relationship remains
> fixed - i.e. the same one that we've developed the
> trust in.


Right.


>>> 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.
>>
>>
>> Well, maybe.  We want the petname to refer to that
>> relationship, but we cannot guaruntee that it does.
>> About all we can do is guaruntee that a petname
>> refers to a key, and a key has been used before.
>> And even that is challengable at the margin.
>
>
> I'm not sure what you're questioning.


I'm questioning whether a petname can only bind trust.

We are coming out of a decade where VeriSign said
that using its certs gave you trust.

They are two very similar statements, with very similar
shortfalls in usability.


> Are you questioning whether the binding with
> certificates signed for a given organization is adequate to assure 
> actual communication
> to that organization?  That is you're questioning whether the 
> technology of
> binding communication by what's in a certificate is technically adequate?
> In that case it seems to me we should either improve it or go with the
> best we have.  I believe this is a situation where if we can provide 
> better
> protection (e.g. from phishing) we should do so and get it out there.  
> It can
> always be improved at a later time.
>
>>> 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.
>>
>>
>> I don't see why the user can't type in "dodgy porn site"
>> as the petname?  This is the essence of relationship;
>> she has worked something out about that site in the
>> past, and may decide she's seen it a few times and wants
>> to set that 'trust' in negative form as well as positive form.
>
>
> That seems an entirely reasonable use of the Petname to me - though
> I'm not sure I would waste my time on that particular example.


Right, it just happens to be very apropos to phishing and
phishing-related frauds, and use cases like this need to
be considered if one is to make a dent in the real threat.

> On the other hand a site that claims to be Paypal like
> the original Schmoo example (which I notice they have changed
> somewhat) I might label as FAKE! or the like - though I'm sure other
> examples are possible and "untrusted" should suffice (though
> I still prefer to distinguish between "untrusted" and "unknown").


Right.  I think users will surprise us in how they
use these things when they finally get hold of them.

>>> 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.
>>
>>
>> Well, we all need to go back to class and learn again.
>> AFAICS, the system I'm working on now uses petnames,
>> and they are not totally for the purpose of trust.
>>
>> Can we get an objective definition of petname, one that
>> does not use the word 'trust', which lacks objectivity?
>
>
> I gave it another shot in a recent email and haven't yet gotten any 
> feedback:
> _________________________________________________________
> The Petname mechanism is a tool that allows users to associate a
> name (the "Petname") with a safe binding to a known organization
> on the Web.  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 organization that 
> they gave
> the Petname to.  The Petname tool can help users build up trust 
> relationships
> with organizations on the Web.
> __________________________________________________________
>
> Again too wordy, but does it capture a less controversial description of
> the value provided by the Petname mechanism?


Yes.  How about:

The Petname mechanism is a tool that allows users to associate a
name (the "Petname") with a safe binding to a known _resource._
This can help users avoid "phishing" attacks
_by safely binding a name to a known website._
If a user sees a bound Petname in the toolbar they can have confidence
the site they are communicating with is the same organization that they 
gave
the Petname to.  The Petname tool can help users build up relationships
_about/of trust_ with organizations on the Web.

My changes _emphasised_.

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/