[cap-talk] Firefox and identifiability, small steps or large

[Ian G]

(BTW, apologies, there is a dodgy email CC that
came from my emails.  Amir's correct current
email may be herzbea at mac.biu.ca.il but I am not
sure as yet.)

marcs wrote:

>>OK, let me drift here into why logos are better
>>than pet names.  It's easiest to say from these
>>words:  TV, movies, brands, fashion, marketing.
>>    
>>
>
>Just so you know, in general when I use the term "pet name" I mean a 3-name
>system that implements Zooko's Triangle,
>

Well, this seems to be an issue that should
be cleared up.  Pet name to me means a
2-name mapping.

I have reverse engineered my view from
the doc [PNML] [ZT].  But I'd have to say that
neither of these documents fully lay out the
requirements or rules for a pet name.

Here's what I know so far.  A pet name is:

1.  chosen by the user, as
      - highly individualised,
      - relatively brief,
      - indicative of the resource
2.  mapped to an asset or resource,
3.  information that never leaves the agent+user space,
4.  displayed by agent to user in a context where the
     asset is indicated,
5.  unique one-to-one with a resource,
      - for every pet name there is only one resource,
      - for every resource there is only one pet name,
6.  only changed by the user

Now, PNML raises the notion that pet names can be
transitioned via resource names in communication.
I'm unclear whether that is best or a nickname is
better.

Secondly, I'm unclear on how you then stop the user
typing in her pet name in the clear in some other
context.  This is only an issue for security.  But, see
PNML for the curious aspects of how pet names can
be communicated and you should get my drift.

Now, getting back to your above comments, what is
the third name?  Where is this written up?


>and whether the pet name is textual
>or graphical is a different level of detail (though, at that closer level of
>detail, I ambiguously refer to pet names versus pet icons :-). I'm a fan of
>graphics for this purpose, they're a highlight of CapDesk :-) 
>  
>

I know of no documentation that speaks of the notion
that pet names expands to include logos and/or icons.
Can you point me at it?

This is a potentially serious issue of academic reference
import.

I've asked this question before, and got no answer.  I
suspect what is happening here is that the pet name
concept is more of shared knowledge than of written
knowledge.  If so, oh well.  But if there are write ups
explaining the pet name concept in more definitional
terms, please let me know.

FTR, I'm currently aware (and using as a reference)
these documents:

http://www.erights.org/elib/capability/pnml.html
http://zooko.com/distnames.html


>The question is, who are you getting your purposeful trust for the graphic
>from? In the url you sent earlier with the logos in Mozilla, should the
>second logo be a graphic representing Versign, which gives you no info about
>purposeful trust, or should it be Bob, from whom you got the reference (in
>which case it follows pet name logic), who gave it to you for a specific
>reason, a reason that you have a better chance of remembering if you are
>reminded that Bob is the one who gave it to you? Or should there be only the
>single graphic for the entity itself, which is also reasonable when using a
>pet name architecture?
>  
>

The thing that is a little bit complex about the
TrustBar arrangement is that there two parallel
logo tracks.  One is the site logo, which is chosen
by the user.  The other is the CA logo.

Now, I don't know how A&A did it, but I imagine
the CA logo to be centrally provided.  The reason
for this is that the CA root certs - which are what
that logo represents (is signed by) - are already
provided by the browser.  So, in ZT, we are in
the secure, centralised space.  In which case we
may as well use the same mechanism to deliver
a secure/centralised logo.

I haven't explored the possibility of having user-
selectable CA logos.  The reason for that is that
the use of centralised logos also gives us the
possibility of creating brand.  Once CAs are
branded, they then have something to defend,
and they can then defend their space.  This
carves up the CA-signed cert space into CA
fiefdoms, which are defensible to a much greater
extent than the current CA/PKI (which suffers
from the all-CAs-are-equal bug).  I wrote this
aspect up here:

http://iang.org/ssl/VeriCola.html

This might have a bearing on the CA thread
that you intimated you had written on somewhere.


iang

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