[sugar] Obtaining Buddy objects as contacts are encountered

[Simon McVittie]

Excerpted from #sugar:

15:33 < smcv> dcbw: hmm, do we support buddies changing colour/nick/avatar at 
              will?
15:33 < dcbw> smcv: yes, we do
15:33 < smcv> dcbw: if so, any spoofing protection is essentially worthless 
              since they can freely change how they appear in the UI
15:33 < dcbw> smcv: I'm not sure if sugar supports the name change in the mesh 
              view correctly
15:33 < dcbw> smcv: keys cannot be changed
15:34 < dcbw> smcv: the only unique ID of a person is thekey
15:34 < smcv> yeah, but children aren't expected to be able to look at a 
              contact's key :-P
15:34 < dcbw> smcv: no, the UI needs to deal with continuity management; if I 
              try to chat with 'john' but it's a different 'john' than I talked 
              to yesterday, then the child needs to know
15:34 < dcbw> smcv: there are definitely some UI issues here that need to be 
              sorted out
15:35 < smcv> consider: alice knows bob and charlie. bob isn't online at the 
              moment. charlie changes his nick and color to match bob's and 
              talks to alice
15:35 < smcv> as far as alice can see in the UI, he's bob
15:35 < dcbw> smcv: in which case, the key is the same, and the user gets 
              notified that this 'bob' isn't actually the 'bob' you might think 
              it is
15:36 < dcbw> smcv: same thing with jabber; I'm sure you can have two people 
              named "bill" but htey have different jids
15:36 < dcbw> smcv: you as the user need to know the difference
15:36 < smcv> dcbw: is that notification also meant to be triggered when bob 
              changes his nick to robert?
15:36 < dcbw> smcv: we may also allow you to set a real name or something for 
              the buddy that gets used no matter what the buddy's nick changes 
              to
15:36 < smcv> dcbw: on jabber, typically one of them would be called 
              bill at jabber.org and the other william at gmail.com
15:36 < smcv> or whatever
15:37 < smcv> it's rather harder to compare 128-bit hex strings
15:37 < smcv> (I assume we're doing our best not to expose the JIDs in the UI 
              at all, in fact)
15:37 < dcbw> smcv: correct
15:38 < smcv> dcbw: "allow" -> they won't
15:38 < smcv> surely?
15:39 < smcv> at least not until they've been bitten by friends impersonating 
              other friends a couple of times and someone knowledgeable has 
              explained how that helps

It seems to me that there are two directions for anti-spoofing:

* Has this buddy changed their identity recently?
* Does this buddy have an identity confusingly similar to one of my
  other buddies?

For the first, when a buddy has changed their colour and/or nick recently, we
could highlight their XO somehow, with a mouseover popup showing other recent
colours and nicks they've had. This would be easy to do, and catches the case
of one of your buddies trying to impersonate another - at the very least, you
can see that "Bob" was called Charlie until recently, and get suspicious.

For the second, you'd have to use some sort of heuristic to detect "are
they trying to trick me?" and have a ssh-style "warning: something dodgy
is going on here". As we know from ssh and web browsers, making a UI for
this that non-crypto-literate users will understand is rather tricky.
However, this is what we'd have to deal with for the case of someone you
haven't met yet trying to impersonate someone you have (suppose that instead
of impersonating Bob himself, Charlie asks his cousin Dave, who
Alice doesn't know, to do the impersonating).

Thinking about it, another possibility would be:

* when someone tries to change their nick or colour, don't change it
  anywhere in the GUI until the user has accepted the change
* have some visual indication that you haven't met someone before
  (for the "cousin Dave" case)

In any case, to be able to recover from mistakes you will have to
be able to find out something unique and unspoofable about a contact.
This could be done by asking them to send you a message when you next
see them in person, if it's someone you ever meet in person, or by
asking them a question the real person would know the answer to, but
when we have this whole key-based security thing, it'd be nice if it
could actually help us! Possible things:

* When the OLPC is first registered, have the server sign the child's
  "official" identity (e.g. full name). (The reason it has to be signed
  is so the child's mesh identity can include it - then at least anyone who's
  on the same server can verify it while not currently connected, if
  they've previously stored the server's key)

* Display the fingerprint (probably not all of it, since we're not
  dealing with the NSA here :-) in a friendlier form - perhaps a pattern
  of coloured squares and/or a bubblebabble string.

To see how well the latter idea works, I tried encoding my three Sugar
test profiles' fingerprints.

Raw fingerprint as calculated by Sugar
(Python: from sha import sha; sha('AAAAB3...=').hexdigest())
default: 0f8b0e297ff44f30bb0affcebcb329a0604192ae
login 2: d4a2e234698124054073b713bcc751af304338d4
login 3: 20495ffc251a2d57ff1824cabe5c1f44c8e39d99
Not very friendly.

BubbleBabble (ftp://ftp.ietf.org/ietf-mail-archive/secsh/2001-08.mail)
with script http://projects.collabora.co.uk/~smcv/bubblebabble.py
whole fingerprint of default:
xefom-rofed-nyzyz-gifef-bivub-pizys-vizur-fepap-bomug-cygip-vyxox
or just the first 8 bytes: xefom-rofed-nyzyz-gifef-baxex
First 8 bytes for my 3 keys:
xefom-rofed-nyzyz-gifef-baxex
xuhap-dumef-gipym-cynib-haxox
xemag-nolyz-sonoc-pareh-laxex
It's better, but not great.

Colour squares:
If we have, say, a 4x4 grid with 2 bits per "pixel" per R/G/B channel (to make
colours nicely distinct) that's 4x4x6 = 96 bits of information.
Taking the first 12 bytes of each of my keys I get:
http://projects.collabora.co.uk/~smcv/fingerprints.png
(with script http://projects.collabora.co.uk/~smcv/squares.py)