[sugar] [Post-trial2] Buddy identification: security and UI requirements?

[Simon McVittie]

(Mailing this now while I remember, because this is something we need to
think about relatively soon after Trial 2, I think. Daf and I will be in
Boston on Monday, Tuesday and Wednesday trying to debug collaboration, so it'd
be great if we could talk to Ivan and Eben about this while we're
there.)

At the moment, the collaboration components provide public key
advertising, but they don't actually do anything with it. Obviously this
is less than ideal, but we can't really implement anything security-wise
until someone lets us know what the requirements are. Also, we can't
design the IM security very well unless we have some idea what the UI is
going to be like.

I've previously been told that it is a UI requirement for kids to be
able to change their own colour, nickname and photo at will. Currently,
these are all we display in the UI, so (when UI for this is actually
added) kids can trivially impersonate each other: the impersonator just
has to set an identical colour, nickname and photo, which is something
we support.

Possible solutions:

* Assign an immutable "real name" to each user and sign it somehow. This would
  be a good fit if we were using an X509-style system with certifying
  authorities and trusted third parties (e.g. teachers), but we're not, so it
  isn't. Also, this has the same problem as SSL in browsers - when
  possible impersonation is detected, we have to indicate that in a way a
  6-year-old can understand, which seems unfeasible.

* When we see another user, save their name. Use the saved name to
  identify them in future. Use a heuristic to determine whether another
  user is trying to impersonate someone we've already seen.
  This seems extremely fragile, and I'd certainly rather not be the one
  designing the heuristic... we also still need some sort of UI for when
  evil is detected, but this time the heuristic can't even necessarily
  be trusted.

* When we add another user as a friend, save the local user's name for them
  (defaulting to their current nickname). Use the saved name to identify them
  in future, and make it somehow visible and obvious in the UI that they're a
  friend (display a symbol next to their name? use bold text? use a
  differently shaped XO icon, or one with thicker outlines?). A non-friend
  attempting to impersonate them won't have the distinctive "friend"
  indicator, while a friend attempting to impersonate them will appear
  with their own saved name rather than the name they've temporarily taken.

  This would also mean the child could change their friends' nicknames
  as visible on their own laptop, which would be helpful if e.g. they have
  two friends with the same name!

We'd also like to know whether it's a hard requirement that when children
change their nickname, this change is reflected in the UI of other
children's laptops. For performance reasons and to be consistent with normal
XMPP use, we'd prefer it not to be. (It'd be relatively straightforward to
provide a status message which *can* be changed rapidly like this, if desired,
but XMPP isn't really designed to propagate nickname changes in the same way.)

It may be relevant that as currently implemented, Gabble works much more
efficiently if a locally-assigned name has been saved on the server for
each contact on our buddy list (this is a quirk of the XMPP protocol -
if we have to fall back to downloading the contact's vCard to find out
what they currently call themselves, we also end up re-downloading their
photo).

It would also be useful if someone could tell us what the security
requirements are like:

* Do we have to support migration between school servers? (IIRC, yes)

* Do we have to support migration to a stronger key than was initially
  generated? (The old key would have to be kept too)

* If either of the above is supported, are they going to be rare
  enough that momentary UI glitches are acceptable? (For instance, in one
  possible implementation, they'd come online as an unknown, then a
  short time later (perhaps about a second) the unknown XO would disappear
  from the UI and be replaced by the correct buddy)

* If we continue to use key hashes/fingerprints to identify buddies, do
  we have to support migration to a stronger hash algorithm? (This would
  have to accept momentary disruption regardless)

My thought is that Presence Service should probably identify users by
JIDs - they're guaranteed to be unique, designed to be used as the
unique identifier, and as such are available instantly in Gabble. In
Salut, we don't let others interact with us until we have their TXT
record, so we have the server JID immediately in this case too.

In practice, at least the Gabble part of the PS has to identify buddies
by JID anyway, with a mapping between JIDs and keys maintained for OLPC
users; non-OLPC XMPP clients (e.g. parents with Google Talk) must be
identified by JID regardless, because we have no other identifier.
Whether we actually interoperate with non-OLPC XMPP clients is a
question of policy, but it'd seem a shame not to, particularly in
countries where Internet access is already widespread.

	Simon