[sugar] Obtaining Buddy objects as contacts are encountered
Fri May 11 13:46:01 EDT 2007
Excerpted from #sugar:
15:33 < smcv> dcbw: hmm, do we support buddies changing colour/nick/avatar at
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
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
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
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
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
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())
login 2: d4a2e234698124054073b713bcc751af304338d4
login 3: 20495ffc251a2d57ff1824cabe5c1f44c8e39d99
Not very friendly.
with script http://projects.collabora.co.uk/~smcv/bubblebabble.py
whole fingerprint of default:
or just the first 8 bytes: xefom-rofed-nyzyz-gifef-baxex
First 8 bytes for my 3 keys:
It's better, but not great.
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:
(with script http://projects.collabora.co.uk/~smcv/squares.py)
More information about the Sugar-devel