Your e-mail is your username

The 30-years-old unix pattern for user management involves a UserName, Password pair associated to a unicity constraint on the usernames. On most web applications, this pattern has been enriched as a triplet UserName, Password, Email with, usually, a two-fold unicity constraint both on usernames and on emails. But is there any good reason to distinguish e-mail from username?

By looking at the major web players (Google, PayPal, Amazon …), the answer is negative without any doubt. This pattern has already been widely adopted. Yet, it’s still not stated a being an obvious web design best practice. For example, there is still no simple ways in ASP.Net 2.0 to enforce such a policy through the CreateUserWizard. Let’s review the arguments in favor of this pattern.

• UserName and Email are redundant because both are used as user identification keys. For the user, it means more information to provide at the registration step, and then more information to remember.

• Choosing your UserName is often painful because most of the time your favorite username is already taken (unless you got the chance having a pretty unfrequent first name like joannes).

• UserName is not idiot-proof because most non-web traditional services (your bank, your mobile operator) do not rely on your name to get you authenticated.

A mighty, but somehow recursive, argument is that since big players (Google, PayPal, Amazon) are doing that then doing anything else is only going to hurt a large number of users.

The only real drawback of this approach is the lack-of-privacy concern i.e. you may prefer your e-mail address to stay invisible to the other users of the website where you are registering. Yet IMO, the Display Name is a much more appealing and user-friendly concept compared to the username approach.

Ps: PeopleWords.com does not follow this pattern. I have no good excuse for this situation. I was just young and inexperienced at the time.

Reader Comments (2)

The whole point of a UserName is to have a constant public handle for every user. As you mentioned, an email address is (or better: should not be) public. But it isn’t constant either, as email addresses can change. Similar, a DiplayName doesn’t qualify as a handle. So you’d probably add an additional constant user handle, a UserId (often an integer or a GUID). Instead of the (A) username-password-email triple you now have a (B) userid-email-password triple. To be fair, the first triple often is actually implemented as a (C) userid-username-password-email quadruple (except in UNIX, where the username is used everywhere). The UserId in (B) is not a problem in B2C & B2B apps since the user doesn’t care or ever see his UserId. Hence I agree, it makes lot of sense for B2C and maybe also B2B applications, but I see problems in community-based applications. In such apps, you’d want to have a simple way to refer to buddies, their profile websites etc. You need a unique constant handle, like a user name. For example:

• MSN/Live Messenger: Having to enter your email address whenever you want to add your MSN account in your profile somewhere is really bad. But even more, I wanted to change the email address associated with my MSN account lately. It was a mess, since I had to create a new account (!). I’ll never have such problems with my ICQ or Skype account.
• MSN/Live Spaces: There you’ll chose a handle (that then will become a subdomain). What’s this, if not a user name?
• Flickr: They use unhandy cryptic user ids to identify you, something like “1234546764@NXY”. Is this really better than a real user name? Btw, the privacy issue is not only a member-to-member problem. Even more important, I often don’t want the application to know my address. For example, why do I have to provide my email address only to customize my google search page? Every form you enter your email address is a potential spam risk (I’ve observed that multiple times, as I’ve used unique email addresses for years). September 25, 2006 | Christoph Rüegg

Btw, I forgot: MS Passport also uses email addresses as user names. However, there’s a reason they’ve introduced the *@passport.com handles, which look like email addresses but aren’t:

• You won’t get spam (or other emails) on it
• it will never change. So the basically replaced the email-password tuple with a username-password tuple - because email addresses as usernames indeed have disadvantages. Nevertheless, for most non-community apps where you need an email address it’s a good approach, as long as you only use the email address for authentication, not for identification (and thus allow to change it) September 25, 2006 | Christoph Rüegg