I, too will need to think in much more depth about this problem. I know I discussed a few of the implications with Dan as he began implementing the PS early on.
>From an interaction design perspective, I don't think that it's necessary to allow name changes (or at least, we don't need to make it trivial, like changing colors will be). The idea is that children will be identified by their given name, and as such I'd rather not refer to a "nickname", unless we actually make the distinction between a nickname (changeable) and real name (much less so). This doesn't guarantee security, of course, but it does make it harder to impersonate someone. Also, we discussed possibilities for what might happen when a child changes colors, photos, etc. One possibility is that these children are rendered slightly differently in the UI, perhaps with a badge. By clicking on them (or some interaction not yet determined...perhaps for friends you actually get a notification message) you will be able to see the former colors/photo (as stored on your machine) and the new colors/photo (as provided by them). This would make it rather difficult for Bob to spoof your friend Alice, assuming that you have ever in the past received Bob's identity info, since he would always have to advertize "I'm Alice, formerly known to you as Bob." I suppose this would actually be sufficient if we also specially identified friends in the UI as well, as you mention, perhaps by applying a star badge to them. In that case, any friend of yours who attempts to spoof another friend of yours will be rendered the same, but will also initiate an "identity change" message. Any non-friend of yours - even those you've never seen before - can try as they might to spoof a friend of yours, but can never have the star badge. As another note, when these changes in identity occur, its probably beneficial for the children to view the "identity change" message before the interface adjusts the rendering of the XO whose identity changed. That way you can find Alice rendered in pink/purple as you're used to, without being temporarily confused by the fact that she changed overnight to green/yellow. As far as unique naming goes, as I mentioned, I'd really prefer to use real names. Real names, of course, aren't always unique. I'd like to use first names only by default, adding the last initial in the display when first names conflict. Of course, when the last initial conflicts, we could use full last names. Beyond that, we're mostly out of luck, but perhaps that doesn't matter in the general case. If, however, you want to make two people with identical names your friends, the "make friend" process could check the list of current friends, find the match, and alert you to it, offering to let you modify the name that you locally use to represent the new friend. This has the added bonus that, if an outsider you've never before seen tries to spoof a friend, and you try to make the outsider your friend thinking that you accidentally de-friended the person they're spoofing, you'll get the duplicate friend message and think twice about continuing. - Eben On 7/21/07, Ivan Krstić <[EMAIL PROTECTED]> wrote: > On Jul 21, 2007, at 4:07 PM, Simon McVittie wrote: > > (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.) > > I'll read the rest of the message in a bit; can you meet with me at > 2PM Monday? I'm extremely busy the first three days of next week. > > -- > Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org > _______________________________________________ > Sugar mailing list > [email protected] > http://lists.laptop.org/listinfo/sugar > _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
