[cap-talk] pet names and sticky notes

Ian G iang at systemics.com
Fri Feb 17 14:02:16 EST 2006


Hi zooko,

Only coz you asked :)

zooko at zooko.com wrote:
> (The intended reader of this message is already familiar with the concept of
> pet names [1, 2, 3].)
> 
> 
> Dear cap-talk:
> 
> 
> part one: "sticky notes" are a better marketing term than "pet names"


1. (quibble) the term is petname rather than pet name,
one word.

That was chosen a while back on this list due to its
googlibility.

2. on the face of it I'd agree that sticky notes is
more evocative than petnames.  Beyond that, let's see!


> I've observed "marketing failure" when trying to persuade security engineers to
> use the petnames technique for securely identifying repeated peers.  Many
> engineers were averse to the idea for reasons that I didn't understand.  In
> fact, some people that I have talked to have heard of the idea but have never
> learned its meaning, which might indicate that the name itself -- "pet names"
> -- is discouraging people from learning more.
> 
> Recently I've had the experience of marketing successes with a closely related
> concept: "sticky notes".
> 
> A sticky note is a persistent record of the user's notes about a remote object,
> which is securely stored by the user's agent and securely linked to the remote
> object by the user's agent.  "Sticky notes" are currently in use in on-line
> poker sites (if one considers the central server to be considered the user's
> agent in this case).  The metaphor presented to the user by such sites is
> precisely that of a sticky note, attached to the other player, into which the
> user can type any data that they please.

3. If you are introducing sticky notes as notes, then
there may be a need to separate out a name from a note.

It may be that a name is simply the first element
in the note (however it is demarced).  But for
example if I have a long note about my counterparty
I'd like to see her name not her entire note pop up
every time she makes some remark at the poker table.

This may be just something of an implementation detail,
more on that below.

4.  I'm already sold by your above description.  I
shouldn't read on...


> part two: sticky notes are one element of a pet name system
> 
> A pet name system typically comprises lambda names (mapping a secure local
> label to a secure pointer) and sticky notes (mapping a secure pointer to a
> secure local label), and often also includes nicknames (suggested values for
> newly created secure local labels) and linked local namespaces a.k.a.
> path-based names [4].  It may be useful to have a term to refer specifically to
> the sticky note element of a full naming system.

5.

  "bob"
/|\   |
  |    |
  |    |
  |   \|/
ref:abc123

Are you saying that the lambda name is the mapping
on the right, going down, and the sticky note is the
line on the left, going up?

Conceptually I had thought that the 4 elements above
constituted a petnaming of the object.  I can't quite
see what the point of naming the left arrow over the
right arrow is - isn't this a matter of implementation
detail?

6. It would seem more to my mind that we want to specify
what the concept achieves:

   * user can change the text
   * no-one else sees the text
   * the text relates one to one with an object
   * thus the text can be a name.  Or a note...
   * and a reliable indicator that this object is this object
   * user is encouraged to enter something that would help
     the memorability goal

Or somesuch.  Implementation is .. up to the programmer
(by which I mean, no need to talk about mapping at all!).

7.  I'm now confused whether sticky notes are just another
name for a petname, or whether they are a specific part
that isn't a petname in and of itself.  Maybe the below
will help...


> part three: sticky notes alone might satisfy some needs
> 
> There are two differences between pet names as described in [1] and [2] and
> sticky notes.
> 
> The first is that sticky notes are not used as lambda names.  The user never
> starts with a sticky note and then looks up the object to which the sticky note
> is attached.  Only the reverse lookup happens -- the user encounters an object
> such as a remote peer and is then presented with the sticky note attached to
> that object.

8.  OK.  Why is this distinction/direction/limitation
useful?

Let me explain why I wonder ... from my experience
with the petname system I used in a program I worked
on, it had all these elements.  It effectively had
a set of objects, and a set of names.  A table somewhere
had a mapping from object to names.  (I forget which
way it was ... but originally it was only one way.)

Until, that is, the need for both way mappings turned
up, and at that point, the code was reworked to provide
that.  It occurred to me at that point that any reasonable
app may as well implement both ways, coz it will be
needed one day.

Example.  I'm playing poker.  I'm looking at someone
saying .. huh, she sure seems like someone I knew.  So
I think up some words and do a search.  At this stage
I need to start with all stickies and go looking for
"shifty", "eyebrows meet in middle" or somesuch.

> The second is that the information stored in the sticky note is not influenced
> by the remote peer (except inasmuch as the remote peer can influence what the
> local user chooses to write into the note).  This contradicts a common pattern
> in pet name systems that a "suggested pet name" or "nickname" may be
> transmitted by the remote peer and serve as a default or suggested value.
> 
> These two characteristics of sticky notes are useful for analyzing the security
> properties of the approach and for establishing a conceptual separation between
> sticky notes and related concepts such as nicknames, lambda names, linked local
> namespaces, centralized names, etc.

I agree with that para in isolation, but...

> Therefore, these two characteristics of
> sticky notes are useful for "marketing" purposes -- to promulgate the idea.

and ...

> These two characteristics may also have better security and usability
> properties than pet names in some use cases.  More study is warranted.

9.  OK, so here's another thing that leaps out
at me.

It seems that you are trying to bring together
two persistent enemies, being marketing, and
academic rigour.  I'd say both are laudible
goals in their places, but mixing them is tough.

As a practical matter, if you strip out all the
business of lambda whatsits, namespaces, etc,
there is this nice marketing / programming concept.
But, in the simplistic world of marketing, it's
the same thing as petnames, just a nicer name
(arguably).

That is, petnames and sticky notes are just:

   * a unique name for an object, 1 for 1.
   * kept secret by the user's agent
   * popped up by the agent when ever the object shows up
   * and bidirectional so the agent can find the object from the note/name

In the marketing domain, that's enough rigour.
The key here being that implementation will
fill in the rest - it is an option left to
the programmer whether he wants to provide
a suggested name (nickname) for a new object,
and whether he wants to expand the name into
a full sticky note running to pages or just
limit it to one simple word or line.

10.  Another thought struck me.  Possibly it
would work better to describe this not as
a concept but as a pattern.  So, talk about
"the petnames pattern" or "sticky notes
pattern" and present it in programming terms,
rather than "petname systems."

That would be far more marketable than any
thing else I suspect.  I see you brought in
the term at least once above.

(I find patterns annoying myself.  I tend
to spend ages asking people about the XYZ
pattern, only to understand it's just some
renamed concept that's been around for yonks,
but the new generation of programmers neither
understand it nor can relate it to history.)

iang


More information about the cap-talk mailing list