[Cosmo-dev] Allowable Characters in Cosmo Usernames

[Todd Agulnick]

After a conversation with Brian earlier today, we agreed that the 
character set of usernames is really not a primary area of innovation 
for Cosmo, and it would simplify matters substantially to conform with 
current (albeit simplistic and restrictive) conventions. Brian asked me 
to make a concrete proposal, so here it is:

Usernames in Cosmo must be at least 3 but no more than 16 characters, 
and may contain only the following characters: A-Z, a-z, 0-9, ".", "-", 
and "_".

Comments?

-Todd


On 5/18/2006 10:43 AM, Matthew Eernisse wrote:
> Just a data point ... at my last job, we did a big Unicode update a 
> couple of years before I left, that among other things allowed people 
> to use non-ASCII characters for their username in our Web app.
>
> It worked fairly well, but in practice I think few users actually 
> availed themselves of it. And it did cause us a number of real 
> headaches -- for example, the JavaScript 'escape' function for URL 
> encoding not handling Latin-1 characters properly.
>
> At the end of the day, I think it caused us more problems than were 
> justified by the value we got from it. With translated content, if 
> something is broken, it just doesn't display correctly. But with the 
> username there's all the added encryption and auth stuff you have to 
> deal with, so they may not even be able to get into the app.
>
>
> Matthew
>
>
> Grant Baillie wrote:
>>
>> On May 18, 2006, at 8:28, Todd Agulnick wrote:
>>
>>> On 5/18/2006 7:49 AM, Brian Moseley wrote:
>>>> in the spirit of being as permissive as possible, however, it might be
>>>> okay for us to explicitly allow all of these characters, including
>>>> '/', and field any support questions that might come up from
>>>> mycrazyusername at here&there.
>>>
>>> Easy for you to say! You're not going to have field those support 
>>> questions. ;-) As someone who *does* field 'em, I'm very much in 
>>> favor disallowing characters that are going to cause problems for 
>>> unwitting users. Allowing anyone to have "&" in their username isn't 
>>> worth even a single user writing to say that they can't access their 
>>> account. I have my own front-end for account creation, so I can be 
>>> more restrictive than Cosmo, but I'd prefer that Cosmo lock down 
>>> these characters anyway because users can always go around my front 
>>> end.
>>>
>>> On the more generic question of non-ASCII characters in usernames, 
>>> are there good examples of online services that allow them? My quick 
>>> scan didn't turn up any and I wonder whether that's due to a 
>>> preponderance of US-centric, international-unaware development -- or 
>>> whether there's some other problem lurking here. I, for one, am 
>>> nervous (again) about supporting users whose usernames I can't read 
>>> (or can't render because I don't have the fonts). And my preliminary 
>>> tests with my client failed when I tried using non-ASCII characters 
>>> (probably because the encoding happened at the wrong level, or maybe 
>>> because encoding happened into UTF-16 instead of UTF-8), so there is 
>>> some non-trivial complexity here.
>>>
>>> Either way, definitive answers to these questions would be really 
>>> useful. Has anyone had experience with a service that allowed 
>>> non-ASCII usernames?  Are there other issues that we haven't foreseen?
>>
>> I don't have experience of non-ASCII usernames in Web services, but 
>> the email protocol world has pondered these issues: The specs for the 
>> various SASL mechanisms (used in IMAP/SMTP/POP authentication) have 
>> been updated to support non-ASCII usernames and passwords.
>>
>> In their case, and probably yours, I believe that saying "use 
>> unicode, but encode with UTF-8" is not enough. To avoid collisions 
>> (where you have strings that are equivalent to the user, but are not 
>> identical character-for-character), you need to specify some kind of 
>> unicode normalization, and also weed out, or remap, undesirable 
>> characters.
>>
>> The IETF got started down this road with IDNA (essentially, DNS with 
>> unicode support). There, it was important to prevent phishers from 
>> registering, say Kmart.com, where the "K" is "Kelvin sign", or 
>> inserting invisible spacing characters in domain names, etc. I'm not 
>> sure what the potential attacks are for cosmo usernames, passwords, 
>> but they're probably there :).
>>
>> --Grant
>>
>> _______________________________________________
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>>
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>
>