[Cosmo-dev] Allowable Characters in Cosmo Usernames

[John Townsend]

I would add @ so that people can use email addresses. So if you add  
@, +1 from me.


On May 18, 2006, at 6:13 PM, Todd Agulnick wrote:

> 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
>>
>>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev