Let’s talk about usernames
b-list.org
b-list.org
Sorry what? That seems pretty unneccessary. A third party system to dictate how a third party system handles it local alias system for emails? I can't see any benefit to that.
Whether a mail server handles '+' in a standard way is not guaranteed, and surely it is up to the user how they use that feature if enabled.
From RFC 2822: "The local-part portion is a domain dependent string."
Headaches await you if your code is making a lot of assumptions about how the originating domain manages that local-part portion.
i understand why they do it, but i can't condone it off course.
The service should just allow it, and make sure the appropriated subscribing fee.
I can always create multiple email accounts, you know. So I don't see how spending development efforts to parse and detect + and . is effective.
It is extremely easy to setup extra email accounts, so preventing people from doing so with slightly less work is pointless.
It is stupid because it could prevent someone from using their real, valid email address because it matches another, different, valid email address.
The author has announced they believe them to intentionally indistinct and has announce an intent to break handling for any mail servers that consider them unique. All on account of gmail ignoring them?
This coupled with their author's intent around + makes me loathe this behavior.
So please don't do that. Respect the bytes that be!
You’re fighting the wrong battle.
https://github.com/martenson/disposable-email-domains/blob/m...
A lot of sites I've come across lately are going back to the old-school way of only whitelisting email addresses from .edu domains or ISP accounts ("@comcast.net").
Gmail itself is allowed, but the addresses are normalized. I'm well aware of its potential for abuse.
I have an email address for every site I sign up for.
Helps you figure out who sells your email.
How do you handle this? Or do you not?
I guess you could do a DNS lookup of the mail exchange records and see if it points back to gmail and compile a list of domains to allow one account from... but then that would break many companies emails. That’s no fun.
Services need a better way to figure out fraudulent or abusive behaviour than guessing based on the email account's domain name.
I personally own over 100 from a couple years back when recapta was easily automateable and the phone-number requirement wasn't there.
I haven't seen ISPs give out emails addresses like that in years (I now my last couple of ISPs have no such thing).
So you're basically limiting yourself to people from universities, or who've had an old-school ISP for a while.
Mobile carriers even still seem to, though they are optional and require an additional setup step.
It's all too much for me to keep track of, but for some people it's no big deal to create new e-mail addresses every month.
Obviously it never works, as I get the "I see you're trying to create a new account" email, but one of these days he's going to figure out a way to take over one of those accounts and then I'll really be fked.
(1.) What are you imagining is the attack vector exactly?
(2.) Are you asserting that all website owners should build to Google’s (non-standard) behavior?
Can me and my wife both sign up to HN and use my email but hers be josh+swife@joshmanders.com and mine be josh@joshmanders.com?
That's a strange usecase, isn't it?
Having said that, in development, it's super nice to be able to create addresses with +'s in them.
On top of that, it's just as easy to set up a catchall email address -- an email box that accepts all mail for a domain, literally anything@mydomain.com. So a malicious actor could sidestep this security attempt with minimal effort, but it still inconveniences legitimate users despite being worthless from a security perspective.
It's just as easy to write a script to use ephemeral hosts that you don't need to sign up for. Things like Mailinator.
All it does is irritate people like me who use +words as prefilters for email (and to see which companies are selling my email/user data).
Please don't "normalize" email addresses like this. Not all mail systems are Gmail, and many do treat "john.doe@example.com" and "johndoe@example.com" as different identities. And even if we are talking about Gmail - it's not your identity system's job to deduplicate different logical addresses for the same physical inbox.
Lots of weird email systems exist. Don't assume that everybody works like gmail. And do test that things work right with uppercase letters in email addresses: I've been locked out of systems before because I use an uppercase letter in my email address and one half of the system was trying to match the lower cased version to the actual text.
RFC5321 s2.4:
The local-part of a mailbox MUST BE treated as case sensitive.
Therefore, SMTP implementations MUST take care to preserve the case
of mailbox local-parts. In particular, for some hosts, the user
"smith" is different from the user "Smith".
However, exploiting the case sensitivity of mailbox local-parts impedes
interoperability and is discouraged.
And when that happens, trying to patiently pull a "well, technically" and explain to them about RFC this and the specs say that is a way to lose users.
(I actually have extremely strong feelings about email, email addresses and the whole associated mess of specs, but had to tone it down for this article since it was mostly about the various traps you can wander into from naïvely thinking that you can just read a spec or implement something obvious and get away with it)
Not in my experience. Showing compassion and agreeing with them that what happened is terrible and you wish things were different but you didn't call these shots back in the days and if they want improvement you can both go together and complain to google, the service which is actually broken.
Most people just want to be listened to. If you can do that, you'll earn a loyal fan, even if you don't do exactly what they tell you to when agitated. Some will even appreciate learning more about the email systems after the fact. They may even get the feeling you went above and beyond by offering to help them with matters outside of your site.
Many people, even after being listened to, and even after having things patiently explained to them, still continue to enter someone else's email address into forms which will send sensitive information to that email address, and complain that they never got their important email, or that some "hacker" has "hacked" "their" email, etc.
In a perfect world this would not happen. We don't live in a perfect world and are unlikely to live in a perfect world any time soon, so we should not be asking "how can we be pedantic and tell users it's their fault for not reading the RFCs", we should be asking "how can we protect users from their ignorance of the RFCs".
(when I wrote this article, I did not expect that this would be the single most controversial line in it from HN's perspective, but I guess by this point I should have anticipated it)
Has it? In my experience, even if people know dots and the part after the + don't matter for their Gmail account (and most don't) they know it doesn't matter to Gmail, a peculiarity they can use to create multiple accounts on a single website without creating new email accounts.
(This is different from case insensitivity, which the majority of popular email providers seem to implement.)
On the one hand, that's a (presumably extremely) rare corner case - on the other hand, some applications must handle those corner cases.
Do you want to run a support system where when you ask for people's username or email address, you also have to ask them for their casing (and in the case that their problem is that they didn't know it mattered, they may not know what they signed up for)?
I worked at an ISP for many years. Even though it was all backed by Linux, usernames (which included email addresses) were considered case insensitive for the purpose of the service (all usernames were lowercase). It solves so many problems and the downsides are so small all the sane email providers did it.
The flip side of this is that it was a simpler time. Usernames and email addresses were ASCII, not Unicode. These days with Unicode, you can't even be sure that uppercasing and then lowercasing an already lowercased string yields the same characters.
It's not an issue if they're the same, the issue is if they're different. E.g. if I'm storing bitcoin on an exchange (I know) behind the email@domain.com, then I don't want someone else to be able to register Email@domain.com and then start looking for bugs in the service or start trying to socially engineer customer support. (The local part of the email address is case sensitive as per the spec.)
People can hem and haw about the specs, but at the end of the day Gmail trained most of the world to believe email addresses are case-insensitive, dots don't matter, etc., and now we have to live with the consequences. If that means somebody can't sign up for twelve accounts using case and dot variations of their Gmail, well, so be it. And if that means they come to HN to rant about how that awful site didn't follow the RFCs, then they come to HN to rant about that, but their account will be safer in spite of it.
I've only once had my email address rejected by a website (for ending with an underscore), but I never bothered setting up another email just for them.
No matter what, there are reasonable hypotheticals where you get angry and take your business elsewhere. The difference is my approach has you leave because you're angry at the signup page, and your approach has you leave because someone stole your stuff. I'll take my approach any day of the week.
For something as important as the credentials for a bitcoin exchange account, as Alex gave as his example, there should be policies specifying the reasons why account credentials can be changed and what evidence must be presented to do so. Front-line customer service reps shouldn't be flying by the seat of their pants when making difficult decisions with potentially hundreds of thousands of dollars on the line.
The point of social engineering attacks is that they’re innocuous requests that don’t raise suspicion, and are hard to train people against.
- Functions to get the account based on the email address
- Internal tools
- Stored procedures and other SQL stuff that happens outside the main code base
- Third-part integrations (Mailgun, Sailthru, ZenDesk, SalesForce, etc.)
That’s a huge attack surface where if there is even a minor mistake by a junior dev that no one noticed then everyone is going to lose their assets under protection.
At least here in the UK, gmail has high reach among techies but is very much a minority provider for normal people. Looking through the 3000ish registered accounts on the local community website I run, Hotmail, Yahoo, and particularly ISPs (btinternet.com, plus.net, sky.com) are all more common than gmail.
Who cares if they do? It's not like that person couldn't create multiple email addresses anyway. E.g. abc@gmail.com and def@gmail.com can be the same person. You can't validate for that, other than other "gamification" systems (e.g. how HN treats new users - disincentivizes creating multiple accounts because why be limited on your second one when you have a good first one).
by the way I have used the + trick on google to sign up for a service (and pay for it!) that wouldn't let me reuse my old account for some reason. So their relaxed validation made them money.
Say you run an online store. You offer USD $5 in first-time user credit.
A lot of people (even some nontechies I know) know about the "+" trick for gmail. Assuming your signup flow is easy and fast, it's very easy for those people to sign up for multiple accounts and get multiple $5 credits.
If a lot of people do that, it might significantly impact your bottom line. Not just because you have to give away a lot of inventory, but secondary effects also suck: you stop the $5-free promotional, and then all of the legitimate users who signed up during the campaign who told their friends to sign up and get some free money now have their friends bad-mouthing the site to them because "it didn't give me free shit the way you told me I should expect it to!". You might see a drop in sign-ups to below pre-promotional levels, or, worse, you might see people who signed up during the promotional trust and use your site less. I know trends/behaviors like this seem trivial--and they definitely would only affect a minority of users--but past a certain scale effects like those can have a real financial impact.
Now let's say your site is "smart" about the "+" trick and doesn't let people with gmail (or google-federated emails--boy, is figuring that out a bastard) accounts sign up multiple times. You'll lose the dubious potential business of folks who like gaming promotionals. You'll still be vulnerable to people creating second email accounts and signing up using those--but the difficulty asymmetry now favors you, the vendor: it's work for a user to make a second email account; work they probably won't do, especially if you blacklist typical temp email services like guerillamail. If the promotional is large enough to entice first-time users but small enough to deter people from doing this, you have succeeded in minimizing your loss. If the user already has a fleet of accounts for this purpose they're probably going to just take your money anyway.
Of course, there's another more annoying scenario which I'll mention because sites should never do it: sites that think they're being smart about the "+" trick by not storing the part of the address between the plus and the domain part. This is usually done to get email campaigns (read: almost entirely spam) to show up in the user's main mailbox rather than some filter-purgatory. It will drive users away in two main ways: first, if I'm technical enough to use the "+" trick and a filter to route mail, I probably have enough obsessive annoyance with spam to immediately either junk-flag yours or delete my account, compared to a small chance I would have actually read it otherwise. Second, more than half of sites that do this which I've audited parse and strip the content of the email address wrongly (parsing emails is very hard, after all) in such a way that what they end up storing could be a totally different person's email, or an invalid one. That means signups just won't work. Whatever you do, don't do this.
This doesn't only apply to first-time-user promotionals, either. It also applies to:
- Referral bonus programs.
- Services that give hand-customized products to users (think a "one per user" etsy store with one person knitting cat dolls or something): multiple similar contacts from the same user would mean you spend a lot of time making their products--time which might be wasted, even if they paid for their products, compared with time spent making them for lots of different users and increasing your recognition/exposure.
- The same applies to tech-support contact-us forms: one user can "bogart" your support staff, clogging the queue with (legitimate or not) requests and defeat your rate limiters by using the "+" trick, making other users wait a long time for replies.
- Others I haven't thought of.
What I noticed what several (large) services these days do, is ask for your credit card number on signup (even if they promise not to bill you).
If they are really giving away credit for free that can be used wholly then they probably need to verify your identity e.g. a $0 credit card authorisation or something.
Denying registration to a suspected-duplicate seems a lot safer than mailing to a different person.
For instance, on my email domain, david+abc@example.com, david.def@example.com, and david_ghi@example.com are all the same ('+', '.' and '_' all act like you'd expect '+' to), but david+xyz@example.com is not (it get's picked off and aliased somewhere else). Applying gmail conventions to other domains is silly and wrong.
The problem is that then you're adding potential attack vectors to every single web app just to cater to the .01% of email clients that insist on implementing the email RFC exactly to spec. Not deduplicating email addresses creates an attack surface for both hard-to-spot technical issues and also social engineering attacks. E.g. what if your ESP at some point adds deduplication on their end, either mistakenly or on purpose, then suddenly you're sending password reset requests to the wrong users.
I think you should normalize email addresses to enforce account uniqueness, both for security purposes and usability, as long as you also store a second copy of the email address exactly as the user entered it and only send email to the latter version.
Thank you, so much.
I just wanted to highlight that for anyone who looked at the comments to decide whether or not to read the article.
Send email to it
That is literally the only way to validate an email address. There is no regular expression or algorithm that can validate and/or deduplicate an email address.
You must simply treat every email as unique until you send an email to it and that person proves otherwise.
That being said, this article brings up a lot of important things about confusables that everyone should definitely be aware of, especially if you're going to have public identities.
john.doe@gmail.com
johndoe@gmail.com
A better approach might be to limit the effect that a new account can have in the system. Hackernews, Reddit, Stackoverflow all do this through reputation. A new account on these systems is unable to achieve much until time is spent proving the account is being used. Thus reducing the incentive for an individual to create multiple accounts.
Which is impossible; a number of people run their own email or use a small friend-run email server, and you can't possible discern the delivery rules from the outside.
Yes. A small number is a number.
If we could go back in time and force every single implementer to follow every relevant RFC to utter perfection (and make sure all the RFCs were perfectly unambiguous), I'd be more sympathetic.
But email is fucked. The sheer number of oddball things, hacks, workarounds, deviations and other bits of mess that implementers have engaged in over the years means the RFCs should be treated as at best a loose hopeful outline of how email might in theory work.
Isn't this a really dangerous game to play? Just because some major MTA's assign a class of addresses to each user doesn't make each member of that class not a unique identifier in general. Is it worth the headache to maintain a list of various email systems' policies rather than just treating them all as unique?
You can generally get away with treating the names as case-preserving (as distinct from case-insensitivity), and you are probably safe in rejecting quoted localparts. But beyond that, even forcibly lowercasing email addresses, is likely to cause problems.
Also, it’s useful to make use of +foo or varied usages of dots to create a unique email address for each site: for one thing, it’ll help if one site leaks your email address, then it’ll let you trace the origin of the leak if that email address gets unwanted email.
Finally attempting to deduplicate email addresses before authentication is almost as bad as lowercasing the password before checking if it matches.
I'd be fairly surprised if your average user of gmail knew this: I know it and I use it in part because it lets me _distinguish_ different accounts on the same site. Second-guessing someone who's taking advantage of this feature is more likely to generate tech support requests than not.
Non-anecdotally, articles with large numbers of views/comments about the trick can be found with a quick Google search on non-techie sites like NYT/HuffPost/BusinessInsider/Buzzfeed/Pinterest/etc. Not that those are definitive, but I think knowledge of this is more widespread than you think.
If you actually strip the dots and plusses from my email, and start sending stuff to my main address, then I will mark your messages as spam. You need to store the normalized and non-normalized versions of the address. Actually, you need to do this for normalizing on usernames anyway, to make sure you don't mutilate people's Arabic names or anything (Unicode-normalized cursive looks really bad; you need to preserve the original version, while keeping the normalized version around specifically for uniqueness checking).
I think it's not even close. You have to transmit the content of the email address to the server, since you might need to email the person. Whether you validate/sanitize/perform voodoo on it there is up to you.
You don't have to transmit the password (because one way hashing), and should never do so.
A harder question is what you should assume about people who run a "+"-tricky email service on their own domain (e.g. federated gmail) and who later switch to using a service that isn't "+"-tricky (e.g. federated gmail user switches to running their own mail server). What's your default policy: default-allow or default-deny? I suspect the answer will have to do more with the amount of potential revenue lost due to such users' likelihood to abuse the plus trick, and less about the technicals of how to address it.
What system with any non-trivial level of use uses the text username as (1) the FK in the database, as opposed to the generated or auto-incremented ID in the db; (2) the login name; and (3) the publicly-displayed displayed "name" of the user for others to see?
Plenty of forums etc use the login name for #2 and #3, and I'm not convinced by this article that that's the wrong way to do it. I haven't ever seen a single professional product that uses the text username that a user logs in with as the actual DB-level foreign key. That's grade school level database design.
There is also the security issue that by having the login name also be the publicly displayed name lowers the bar for attempting to make a targeted attack on the site, as well as other sites where the attacker suspects the victim may be using the similar login name. This can particularly be true in cases of harassment across platforms, which while is not a computer science security issue, it is a personal psychological security issue.
That's exactly the point though. If you join on the username than allowing emails/usernames or whatever that identifier is to be edited is very hard. How you identify the row to auth against is literally the point of a username.
Discord has a very interesting solution to this. They have user names and user ids. User IDs are tied to emails and the user's name seems to just be a random text identity for displaying to users. I assume most of their backend code used a unique, sequential or random, integer ID to identify and talk about users while their frontend just makes the ID to a "user name". As long as you slap account creation behind a verification email and don't mind one user being able to sign up for multiple accounts you side step many of the larger problems that come from choosing user names because, in effect, you are choosing the "Real" username and you can make any guarantees that make writing all of your other software easy.
In Blizzard's implementation, I can't add a friend by just knowing their name, I need their id number as well, and the process for finding it isn't exactly front-and-center.
The edge cases discussed don't pop up that often unless you have lots of folks using your software or are really diligent about fuzzing and testing edge cases. If you roll your own, say, username system, you probably aren't going to fall into either of those two cases. Which means you're vulnerable.
Like storing sensitive data in the authn's session system because you don't understand encryption vs signing nor how to find out -- maybe it's time to just sit down and credentialize as a craftsman.
The authn/z systems I've used that were the biggest headaches in my life were kitchen sink frameworks trying to generalize over everyone's creature features, and they were often tied to a company/community culture of not-gonna-touch-it that only hurt users and security.
My comment was stating that you should default to these types of libraries and only roll your own if you can't do what you need to, simply because they're more likely to handle edge cases that can have serious implications.
Do you do unicode normalization on your usernames? I freely admin that I don't, and wasn't aware it was needed until I read this post.
Please don't do this, lots of people (including myself) use the '+' hack to separate accounts for different contexts (business/personal, different projects/clients, etc).
Checking for the existence of any 'john.doe@example.com'-like accounts would mean I have to register an entirely separate email account or set up (another) email forwarder/alias.
You should ideally also store a second copy of the username in the original casing and normalized as NFC for display purposes, as some users care a lot about seeing their username exactly as they entered it. (And in fact not allowing this may be seen as culturally insensitive in some cases, much like not supporting unicode.) The same applies to the user's first and last name, which you can store in NFC for display purposes and casefolded into NFKC for string comparison (e.g. search) purposes.
That said, most sites limit usernames to ASCII characters so that they can be (easily) used in URLs. In this case you don't need to casefold or normalize, just converting to lowercase is enough.
I wanted to stay out of the Python 2 vs. 3 quagmire in this article, but it's worth knowing that in Python 3.3+, strings have a 'casefold()' method:
https://docs.python.org/3/library/stdtypes.html#str.casefold
Unfortunately, since Python 2 still has around two years of upstream support before EOL, I can't universally recommend people just use 'casefold()', no matter how much I'd like to.
Could be as simple as publishing a set of regular expression subsitution rules, specifying (for example):
* render to lower case (because this particular domain is case insensitive)
* drop periods (because this domain treats them like gmail does)
* drop '+' and any subsequent characters (because this domain treats them like gmail does)
* ASCII only (because mail software is old, and doesn't support unicode)
Etc.
Each domain could then publish their own rule, perhaps in a DNS txt record, and anyone needing to check if two email addresses alias to the same could run the correct checks.
I think a better solution would be to use a case insensitive collation on the database for the email column.
If the user changes the capitalization of their email, treat it like any other email change (validate the new email via email token)
Excellent read by the way. Many things I have never considered or even worried about before.
Many sites-- like HN-- may not even need that. If you have system and login identity you can just display "dingus" as the name of every single user and the system should still work the same.
>Well, it’s easy until we start thinking about case. If you’re registered as john_doe, what happens if I register as JOHN_DOE? It’s a different username, but could I cause people to think I’m you? Could I get people to accept friend requests or share sensitive information with me because they don’t realize case matters to a computer?
Just this month we fixed this issue by using a citext column in postgres. So yes, it is easy. Maybe I'm missing an edge case here?
If so, the rest of the article covers in great detail all the other edge cases :-)
Now, how did you solve the other problems mentioned?
The reality is that there are almost ten billion people on this planet and they live for upwards of a century. You are simply deluding yourself if you think it is reasonable to build a system with unique, permanent usernames. Nothing in the real world works like that, including trademarks. And it just helps enforce the very problem that people try to trust usernames and then get tricked by people who sniped usernames that are tied to other peoples' well-known identities (leading to abused "verified" badge systems and legal challenges and expensive hostage scenarios... it just sucks).
And for what? To make it easier to hand-type a URL? Does anyone even do that? I am super technical and I barely even do that in 2018, as if nothing else there are too many websites in existence to remember all of their one-off URL schemes. Like almost everyone, I either use the site's built-in search feature or I do a search on Google to find people, and let a combination of page rank and personalized results guide me to the right destination. Some web browsers don't even show URLs anymore!
Here is a great example of where it is completely insane: Facebook. There is absolutely no good reason for that website to have usernames for regular users, and they frankly shouldn't have usernames for businesses either. It isn't even clear to me that the app--which most users are using, not the website--even has a way to show people's usernames, which means this is an identifier which somehow everyone knows must be chosen and must be unique and is nigh-unto permanent but which somehow is also simultaneously meaningless but is also a horrible point of contention? What?
I am lucky. I spent a bunch of time in 1994 to select a username, and despite being 13, I was mature enough to come up with something that wouldn't ever come to cause me complex problems. People ask me what it means, and it essentially doesn't mean anything: it has only a positive connotation to me when I hear it, it is entirely neutral, and it had no existing usage I could find. Yet, I also still got screwed, as I am semi-famous, and everyone knows me as this username. I have kids who look up to me enough to want to take my name as a show of support and I have to essentially be the big bad asshole about it because in a world of unique and permanent usernames, people then assume the kid is really me. On the other side, I have been asked to rename myself by moderators of various forums as they couldn't believe the real saurik got an account on their site, and it was "confusing" people.
And so in the end we all have to deal with the worst-case scenario anyway: unless you do nothing but sign up for random sites rumored to be interesting constantly (which I seriously tried to do), you eventually will succumb to needing a way to prove who you are on multiple sites and tie together those identifies. And for most users... as in virtually all "normal users", that moment comes when they are using only two websites, as their username was probably something like jay.freeman.178 as everything that was even remotely interesting to them was taken a decade earlier by literally a different generation of humans, so they let the website automatically generate one.
In a world where everyone is having to solve the worst-case problem anyway, every site should just have numbers as unique identifiers, at most have some kind of trust score for degrees of separation on the site (so you can get a feeling for "is this the saurik that I met?"), and everyone should be trained "names don't matter and if you see someone with that name it doesn't even slightly mean that they are the same person you met last week".
So that you can be identified? (I'm not talking identified in a mathematical sense, but in a informal conversational sense (you know, what usernames are actually used for)). The whole point of a username is that it is the most humanly convenient way to represent a user in text in the context of a certain site.
Because the alternative would be to have thirteen saurik in the same thread debating a topic and you would have no way of distinguishing them. Avatars are an attempt to fix that but it sucks and is bloated for many scenarios.
Sites that do allow you to change username break conversations where people refer to each other using the username (stackoverflow comments are a really common and annoying issue)
Yes, it is annoying when you don't get your first pick but it truly is not a big deal and it solves a real problem.
jay.freeman.178 is an excellent username. You are not your username.
The problem with breaking continuity in forums and other similar networks can be mitigated via dynamic user name lookups (eg how Facebook does `@` mentions - however I have also seen some forums do this as well), supporting in line quoting (like how message boards often work), nested replies (HN, reddit, etc). Granted there will still be occasions when references slip through the net but us humans have a remarkable ability to deduce the context of the written word even when it doesn't always read perfectly.
A possible implementation would be to allow the user to give a "nickname" to add to usernames he wants to identify uniquely that would be visible only for them. For example since I talk now with you I could add to your username "user with whom I discussed identities and usernames" and this (or a short version of it) would be shown next to your username from now on.
A more automated way to do this is to create a unique image for the user based on the content they have posted, when they created their account, not so personal but requires less effort from the user, I'm sure such systems exist in many sites to create avatars. Obviously in this machine learning times we could get to do sth much better.
In the real world, people almost always go by their first name, and we don't have this problem. When two people in a social circle have the same first name, we don't turn and say "well everyone has to use their whole name, always, now." Rather, we adjust our names (usually someone gets a nickname, or goes by their last name).
The steam system allows multiple people to have the same display name and it works just fine. Sure, people can troll with it when they join your tf2 server (and then you kick them off).
The blizzard system also works great. The unique identifier is there, if all other forms of attempting to add a friend fail, but mostly you end up working contextually.
If your apps' users report problems with identifying people, just allow users to add more specificity to their username. "People always get me confused with this other user 'chairdude', can I change my display name to 'armchairdude'?"
If thirteen 'saurik's want to have a fun time and create a confusing discussion thread together, so be it.
I was also recently annoyed at being forced to switch to a new system for my credit card, and it's a unified system with all their other cards and banking customers, and still uses "username" (instead of email) as a login, so of course my name was taken. I decided to just append some random characters, and then realized I could just generate my entire username and have been doing that since, when I don't care about identifying myself to others. My password manger saves it, so it really doesn't matter to me.
Even better, if they have your email and use it for password recovery, you can basically turn it into a two step authentication by not saving the password and using password recovery every new time you need to log in. Though, that can get annoying if their password recovery takes a while to send.
There's no way to merge the online accounts, even though the banking accounts are merged and I can see all of the financial information from each no matter which login I use.
I found a way to change it and it still worked last time I tried.
You must install Facebook Messenger. I am using iOS, don't know if the Android version is the same.
Keep in mind that your old username will no longer lead to your profile once changed. For me this was exactly what I wanted but for some they might want to not change their username after all due to this.
In the Facebook Messenger app, tap your profile picture in the top left corner. This brings you to a screen with the title "me". Right under your picture it will say "username m.me/yourusername" where yourusername is your actual username. Tap on your username and select "edit username".
Once you've changed your username in the Facebook Messenger app your identifier on Facebook itself will change also so now when people go to your Facebook profile on facebook.com in their web browser they will see your new username in the address bar.
Figuring this out was actually very difficult, as most information online claimed that your username could not be changed.
Because it somewhat seems to me that Facebook also don't want people to change usernames I ask that everyone who reads this keep that secret. HN pages usually don't rank highly on Google so mentioning it here shouldn't matter too much.
If any Facebook employees read this, please either
a) Make it easy for others to find out by updating official documentation, or
b) Make it easy to change from the main facebook.com application, or
c) Forget that you saw my comment.
As I'd like to be able to change my username in the future as I have done in the past.
For example when I send a photo by Messenger it is attributed to my ( n-2 ) name.
One could probably infer something about the state of Facebook's architecture from further study.
ICQ did that. Though it still led to interesting results, because lower numbers were thought to be more valuable, and people were buying/selling those.
Perhaps a random numbers with the same number of digits or UUIDs may work without such issues. :)
However my slashdot number, which I've had nearly 20 years, I know nothing more than it begins with 2.
The modern numbers I remember are my mobile phone number, my wife's, and my passport numbers (phone numbers as we've had them over a decade and all of them because I have to write them on forms so much). The only other numbers that spring to mind are my staff number at work (used in various forms, had since 2003) and my bank numbers (needed to log on)
If you use a number a lot, you learn it. If you don't (like usernames which are saved) you forget it. I can barely remember my credit card pin as I use contactless so much, but muscle memory seems to work there.
Then people will be buying/selling UUIDS which are easier to pronounce or memorize. People will always consider patterns more valuable.
UUIDs were also my first idea, but I have the feeling that sharing them (i.e. to invite a new friend) would be cumbersome. I wonder if a new system akin to what3words.com could help there.
The weakness lies partly in ICQ: they allowed to easily find all these people using @hotmail.com e-mail address and even showed this information. Sure, you could disable being part of this feature (IIRC it was called "yellow pages" or something akin to it) but still.
The other part of the weakness is exactly the very issue of domain squatting, username squatting, e-mail squatting or whatever you want to call it. I understand Microsoft wants to save space on their e-mail servers back in the early '00s but: former username should be frozen and their e-mail could be either bounced or silently rejected to /dev/null or whatever's the Windows equiv.
Blizzard's WoW has the rule that you you can only get a username from an inactive account. An inactive account is an account which did not play the previous expansion. That's their compromise. To be fair, it is not like people use WoW usernames for password recovery.
As for using numbers as username: that is what UNIX does under the hood, it is what Facebook does under the hood as well, it is what Blizzard's WoW does under the hood as well, and what T9 converts to as well, and ICQ did as well in contrast to MSN. Turns out people are lousy at remembering a bunch of numbers. So they resort to 26 character system of letters, or 36 character system of letters plus numbers. (Some services are more or less strict.) So, no, using numbers as human-usable UUID is not a solution but using it under the hood is totally OK.
† http://habitatchronicles.com/2008/10/the-tripartite-identity...
The real problem is that unique and permanent usernames serve as tatoos (which people later may find to be humiliating or depressing), disadvantage late-comer non-technical users (who will almost never have a good username and almost never will have the same username on two websites), and lead to weird problems with assumptions people make about what usernames even mean (that they are a signal for identity) that are simply not true.
Expiring hotmail addresses have been problematic in many cases, and any unique lookup string will eventually be stored somewhere by someone and assumed still valid later on.
It's not even solved in full for phone numbers, despite everybody knowing they can expire and be reassigned - since long before our own lifetimes.
Do you realize how impractical it is for users to remember these numbers for every site? Until we get to the stage where every non-English-speaking user and their grandma finds a password manager convenient, this proposal won't even pass the laugh test.
Case in point, I operate a service that uses numeric identifiers. Going by the helpdesk queries, our users are more likely to get their email address wrong than their membership number.
That's really not an issue. It isn't much easier to remember that I'm "John28161" on a busy site. Websites have been offering "I forgot my username" functionality for ages, so as long as you remember your e-mail address, you're fine. Also, just let users bookmark their personal profile page (foo.site.com/user/83755567565) easily and it's solved even if cookies are deleted. Apps won't have a problem either way.
Digits are much easier to spell over the phone than a mixture of letters and digits.
People are used to identifying themselves with a sequence of digits. If you're dealing with the tax office, the water company, the electricity company, or whatever, you get asked for your customer number, your meter number, your reference number, and so on, and usually these consist mostly of digits. Sometimes these identifiers are way too long, or several different identifiers are unnecessarily used, or the same sequence of digits is confusingly referred to by several different names ("customer reference", "account number", whatever), but those are separate problems.
100595964940551841549 isn’t exactly usable for that. Even phone numbers, such as 01573 0677867 are much shorter, and they follow a pattern.
Though yes, i agree that once the nr of accounts start going above 1 or 2 a password manager will be required.
During my freshman year of college a particular sandwich shop hired a spokesperson who shared my first name. One thing led to another, and the name of that shop became a lasting nickname.
Unfortunately that spokesperson turned out to be quite a monster, leaving me in a bit of an awkward position on sites that don't allow username changes.
This dilutes your otherwise excellent point. URLs are great when done right and lots of people prefer them to the sites search functionality. But that is entirely orthogonal to identities, which barely ever need to show up in a URL. (Unless treated as permanent and uniquely attached to physical people, which we agree they should not.)
Uh, Facebook doesn't have usernames, and haven't had usernames for as long as I've been able to be a member.
There's an option to grab a unique identifier for your personal page, so that you become https://www.facebook.com/identifier, but it's completely optional, it's just a vanity thing.
Same for groups, they can grab a unique identifier, or stick to their auto-generated id.
Same for businesses.
There are probably people out there with spreadsheets full of service types, account names and passwords of accounts they control that include all the two letter to four or five letter company names, and many celebrity names, just in the case that someone wants to pay for it. The domain name game, just evolved for the current climate.
I mean, it would take me less than $25k worth of my time to build something to automate this, even if I had to get rotating IPs, mobile accounts, and have mechanical turk to solve CAPTCHAs (although with all those features it might be close), and you were offered that for one account.
I joined a Big Dinosaur Company early enough that they were still using mainframe RACF as the system-of-record for authentication, flowing downstream to LDAP. So indeed I received, for example, dlg28 as my ID and stem for e-mail address.
However after several years the SoR was migrated to Windows LDAP ( can't remember its brand name ) and it generated 'sensible' IDs for all the newer staff. So someone received JimSmith as ID & e-mail address.
We oldies felt old and uncool! So a project introduced self-selected e-mail aliases for the oldies, which then led to interpersonal conflicts because jsm22 wanted JimSmith@, but the 'new' Jim Smith already had that... But jsm22 felt he had title to it since he had worked there 40 years etc etc So he was given JimBSmith@ which of course led to misdirected e-mail. Hilarity ensued.
I'd rather they had never introduced the long-form IDs at all!
No need to go that far... just look at the URL bar right here. :-)
Yeah so what’s your alternative again?
If this is your belief why have you stuck to a specific name, to the point of signing up to random sites just to take possession of it?
In business you have customer account numbers, bank account numbers, membership numbers, invoice numbers etc. There is no conflation with identity - you are not your account with your bank, gym or stationary supplier. It is only because of internet forums and login usernames that we have even gotten to this state of affairs in the first place.
Usernames (or internet aliases in general) were a routinely mocked part of internet culture by mainstream culture. People these days use services in spite of usernames rather than because of them. The president of the united states has 'real' in front of his name. Think about that. In no other medium do we have people asserting that they are the genuine person they are claiming to be. Its tautological.
Depends what's associated with the account, no?
If it's something like Steam, your username might be tied to hundreds of dollars of purchases.
If it's Slashdot, you'll lose your sweet low user ID.
If it's StackOverflow, you'll lose your various reputation scores.
To be honest, given user names are just an arbitrary reference, you could probably also include phone numbers, IP addresses, social security, national insurance and house numbers into the list of prior art as well.
Not that I'm advocating the use of numbers instead of names. Twitter I think gets it right where they give everyone a number which is fixed but you can assign yourself a name; which can change. Most of the time people choose not to, But the option is still there.
Most users have at least two email addresses because most of their mail is routed through email addresses like "PartyChick88@hotmail.com" but they don't feel comfortable putting that on job applications and medical forms.
It is a statistical certainty that people have missed job opportunities and subsequently defaulted on mortgages because they sent off a bunch of job applications on their "business" email address and then forgot to check it because they don't use it much.
One of the more common office security failures is to have your email client auto-fill to someones personal account instead of their company-issued account, resulting in sensitive documents leaving the auditable environment of the office email server.
Now for sure, it's not exactly up there with global warming and north korea, but I'm not sure I'd call it a "no-problem". It's a fundamental UX failure that we're only just now starting to see get fixed with email address aliases becoming a more widespread feature, and even that is just a patch. We've all gotten used to it, but that doesn't mean it's not a problem.
I have no idea who you are and don’t recognise your username. Was that whole rant just a humblebrag that you’re “internet famous”? Because here at least, no one cares.
Seems like a real anxiety, not just a humblebrag. I’ve felt the same way and my response is to just make up new names all the time.
It does not address many of the other things higlighted in this post but it is a start, at least for my services.
This is needlessly user-hostile. If users wish to use mailbox extensions to have multiple unique accounts, that's their right. They can always get multiple different email accounts, after all.
He doesn't mention the one thing he ought to do, which is to strip email addresses of comments before checking them: (foo)jdoe@example.com, jdoe(bar)@example.com, jdoe@example.com, jdoe@(home)example.com & (a (nested (comment)))jdoe(more)@example.com(all done) are all the same email address.
It defines a (small) set of profiles to validate and compare various types of string, including "Username" (in both case folded and case prepared variants) and "Nickname".
Want to compare two usernames for equality? Run the two strings through the comparison steps for the UsernameCaseMapped[1] profile.
It won't solve all of your problems, but it's a good place to start.
> System-level identifier, suitable for use as a target of foreign keys in our database
> Login identifier, suitable for use in performing a credential check
> Public identity, suitable for displaying to other users
Some sites want a fourth one:
Public Identity, suitable for other users to use to refer to each other.
Like on Twitter: "Discussed this with @bob and @jane yesterday, you'll find ..."
Now, you don't need a unique username to be able to meet this requirement - StackOverflow is an example of a site that handles this I think? But having a unique username is a common pattern that many sites use to solve this so it seems worth mentioning.
- Normalization: http://userguide.icu-project.org/transforms/normalization
- Confusables: http://icu-project.org/apiref/icu4j/com/ibm/icu/text/SpoofCh...
(and there are so many more things)
Their routing (for URLs) is also not case-insensitve. The whole framework by default is case sensitive. Honestly, kind of annoying.
Also i never allowed less than two letters and characters that weren't numbers, latin letters, a space and a few punctuation symbols.
This is a very good read and one I have bookmarked to share with colleagues.
Coincidentally, today a spammer is creating hundreds of accounts with such variations of the same email (gmail) address -- something that should be stopped right away.
Couldn’t you store an upcase version of the username that is unique for this? You would still keep both columns so you have the upcase version for uniqueness and the original column for display name. This would also be backward compatible.
For most applications you are better off with making everything NOT case sensitive.
That's why SunSed language is completely case insensitive -- from variable names, tags (functions) to all string comparations. Users should not worry about case!
I always wondered why we don't use emails as (unique) login names generally. I mean they can be shown with wildcards if that is the concern?!
I somehow created a Reddit account without an email address in order to comment on something about 8 years ago.
Eventually, I decided to comment on something else but forgot the password.
I was unable to reset the password without an email address.
So I never commented on Reddit again...I don't want a username that isn't styfle :)
Also Atlassian Stride doesn't support sending the \xad character at all. It just fails...
\xad makes me \sad
I wonder if Auth0 or Cognito resolve any of these issues.
No it's very simple. Restrict usernames to ascii. Do unicode where it makes sense.
(also, a nitpick: "just ascii" is still the wrong approach, since you probably don't want people putting BEL or NUL in their usernames)
But regardless, even if people in the 90s weren't more privacy minded (which really REALLY goes against my experience with any community i either was aware of - and i use the net since 1993), this doesn't really change my opinion that people should not use their real names online and instead they should limit themselves to latin, letters and a few symbols that cannot be forged.
Think about it ... people who have you in their addressbook already have nicknames for you.
People who you let see your first and last name can already see that.
About the rest of the people - why do they care?
Only because you want your REPUTATION to be communicated to others in English. Hey it's "someguy22"!!
Yeah that's a pretty limited thing. Could be useful but really, how often do we remember names of others? Only celebrities. And who actually cares about Aziz Ansari and his sex life? Or any of the other dudes who we never met? Or why is one dude "the" Bill Gates and the others with same name are not verified by Twitter? My point is, think about what is the sociological meaning behind usernames.
I'd say it's less about broadcasting your reputation and more about letting other people make that judgement about you out of their own interest.
1004383737289302@example.tld ?
Otherwise how did you come across John's email? SPAM?
From him spelling it out to me when I asked him on transit?
I've got 100% of my contacts either by them spelling out their contact to me, or by them entering it into my contacts app, or by me telling them my email, and they sending an email to that.
For all these use cases, 193938939302002 is a useless identifier.
So how should I handle emails, when I want to allow people to register emails?
Same here. John gave you a card? Cool, maybe it can have a QR code you can scan. Or do you enjoy reading and typing long URLs and having to double check them?
How do you handle emails, you ask? Well, how do people enter their emails? They can visit your site and the emails get autofilled. They can bump phones or use bluetooth or any number of ways that don't require verbally spelling things out.
And anyway, if you haven't allowed someone to email you, why should they be able to spam you?
I don’t use CCs, but I (and my parents) have memorized the Kontonummer and Bankleitzahl (and, from that, you can concatenate the IBAN).
> Same here. John gave you a card? Cool, maybe it can have a QR code you can scan. Or do you enjoy reading and typing long URLs and having to double check them?
I visit wikipedia by typing https://en.wikipedia.org/wiki/<topic>.
If a URL is designed well (HN’s aren’t), this is very easy. Wiktionary and Wikipedia do it well, reddit’s is also okay, e.g. https://redd.it/7wwtqy – most sites, in fact, work nicely like this.
> Cool, maybe it can have a QR code you can scan.
Most don’t.
Maybe you remember the time, just a few years ago, when everyone knew their phone number and email, and their friends’, by heart? Why force people to change that? Relying on autocomplete and autofill for everything is horrible, and creates massive network lock-in.
Are you one of those people who remembers every password on every site, because you think a password manager will one day screw you?
51.15.1.223 is my server, in case I need to SSH into it.
> Are you one of those people who remembers every password on every site, because you think a password manager will one day screw you?
I remember two of them, the password to my password manager, and the password to the email that I’d need to reset the password to my password manager.
It’s always nice to use automated tools such as a digital contacts app or a password manager. But you shouldn’t rely on it.
During the @googlemail.com to @gmail.com switch for German gmail addresses, I told Google not to switch. A few years later, in '16, Google auto-switched me anyway, so I selected "undo". In that moment, Google (probably due to a sync bug) wiped all my stored passwords in Chrome, all my contacts, all my emails, and my entire Calendar. On all connected Android devices as well.
It took me ages to get back to have everything working again after that, because I relied on this technology. I’ve lost contacts to some friends that I’ll never be able to get back, because I only had them in Google contacts, or in Gmail.
So I won’t ever support any suggestion that would make me rely even more on these. I’m self-hosting everything now, I’ve got backups everywhere, and, just in case, I’ve got the most important info memorized.