7 ms·

It's fairly long and winding but the main point seems to be that because Unicode exists, and Unicode supports characters that are problematic for the concept of

It's fairly long and winding but the main point seems to be that because Unicode exists, and Unicode supports characters that are problematic for the concept of a unique identity, then it is the concept of a unique identity that is the problem. It also presents a front-end solution (fuzzy-text matching for @'ing someone's display name in a Slack channel) but does nothing to address the ever-present back-end need to actually validate that a client is who they say they are. There's a good reason you can't make your bank username 𝕥𝕙𝕖 𝕜𝕚𝕟𝕘 , and it's not "because developers are anglo-centric and intrinsically against all the wonderful individual expression and identity that Unicode could bring us." Since the article mentioned Punycode, I actually think the current implementation is an elegant solution to a real problem. Of course we should enable folks from anywhere around the world to experience the Internet in their native language. That's the reason the Chrome algorithm to determine whether to show Punycode is so complex - it has to carefully balance the desire to show text the way it was intended while considering that it might be a malicious attempt to phish someone using characters outside their typical locale. In this case, the front-end solution of asking the user "which google.com from this list of two identical-looking google.com's is the one you want" just won't fly.

JoshTriplett 6y ago
Your bank doesn't need the concept of a username. A service may need a username if it's going to have social features, public content, or other ways in which users interact with each other. If people just log in and use the service, let them use an email address as their login (which is already unique), and don't make them pick a username at all.
- akersten 6y ago
  In that case, the email is the username, and the problem remains: are josh@gmail.com and jоsh@gmail.com the same user? To the system, of course they're different - it's just looking at the bytes. Problem comes when a human interacts with the account. Maybe they see the email on the account and manually type it in to another system. Or records are printed as part of a lawsuit and has to be transcribed. Allowing indistinguishable characters in unique tokens creates confusion at best. Broadly I agree that we should reduce our reliance on unique identifiers, and I don't have a good answer for the right approach, but certainly we can't abandon the concept of a unique identifier altogether: it predates computers and the character encoding mess we made, by a long time.
  - deleted 6y ago
    [deleted]
  - inetknght 6y ago
    > are josh@gmail.com and jоsh@gmail.com the same user? I like to think I have a keen eye and pay attention to subtle details. I don't think I see a difference between the two addresses. Your message seems to state they're different though. Did HN normalize the differences? Did my browser? In a blaze of stupidity, I decided to to copy and paste into my terminal and pipe it through a hex dump [0]. * The character difference doesn't show up in the viewport in Firefox; of course, it's rendered. * The character difference doesn't show up in the HTML editor; of course, it's showing the "raw text" and the "raw text" is valid unicode. * It doesn't show up in the browser's network inspection of the response payload. That's the scariest part in Firefox IMO. * It doesn't show up in my Terminal either. Why shouldn't it? We've fought long and hard for terminals to support Unicode. Of course, then there's the fact that I decided to copy and paste from a browser into my terminal even though I already knew I shouldn't [1]. What else could be hidden in unicode? An entire bash script starting with `sudo`, perhaps? Websites can already inject their shitware into the clipboard with clipboard events [1]. [0]: https://knightoftheinter.net/img/hacker%20news%20id%2023774300.png https://knightoftheinter.net/img/hacker%20news%20id%20237743... [1]: https://security.stackexchange.com/q/39118/47800 https://security.stackexchange.com/q/39118/47800
    - FreeFull 6y ago
      The second email address uses the Cyrillic small letter O, which renders the same as the Latin small O in almost all fonts. You can see this in your hex dump, too: Instead of a single o, your hex dump shows two bytes for the second character in the second email address.
      - inetknght 6y ago
        Yup! I was surprised they're rendered the same. The hex dump didn't lie even though everything until then did.
- msla 6y ago
  There's a problem with using email addresses as IDs which has nothing to do with Unicode: Is frobozz@example.com the same as frobozz@example.com? Don't bother comparing bytes: What's changed is the time, and who owns the frobozz@example.com email account. Names need to have some kind of stability over time to be useful, and need to have some mechanism whereby they can be changed gracefully if they need to be. Email addresses have neither of those properties. Mailing addresses have the same problems to some extent, but at least most mail systems should have some concept of forwarding addresses by now. Email is never going to.
  - Spivak 6y ago
    I don’t see this as a problem so long as you don’t treat the email as the permanent source of truth of the account identity and instead have it be the email you happen to have associated with the account at that time. We have abstracted the notion of passwords as “a collection of authenticators defined by the user”, no reason your account can’t have a collection of identifiers as well.
    - thephyber 6y ago
      I agree with you that "identity" has many attributes of which an email address is only one. The problem is that in practice, control of the email address on record is sufficient to take over many modern accounts. Bank accounts likely shouldn't fall into this category, but most web sites don't have bank account level of security. Hotmail created a hornet's nest of problems when they started recycling email addresses after 6 (or 18?) months of inactivity. It allows a quick "password reset", then the account is now owned by whomever controls the email address. Effectively, the identity is hijacked because control of the email address was most of the authentication mechanism. Queue the spam messages and fraud/phishing. Also developing/managing a customer service tool which allows them to decipher these "takeover" events and ensure the person contacting them used to own the account is difficult and sometimes not possible.
      - hombre_fatal 6y ago
        Fastmail, a darling of HN, does the same.
- mc32 6y ago
  Some banks don’t have a “username” to log in but insist on “account number”. Which works but is not something I remember easily and forced me to use a PWD manager, which I guess is a good thing.
  - inetknght 6y ago
    > forced me to use a PWD manager, which I guess is a good thing. Just as long as you aren't copying those bank credentials into your clipboard :)
    - Red_Leaves_Flyy 6y ago
      There should only be to features exposed from the clipboard API. 1. Push. Add a new item to the clipboard. 2. For apps, with an opt in permission. Delete items added by the app. Good for password managers. Also, it's basically impossible to use a password manager without using the clipboard. At the one I use will automatically remove the items it sets after a timeout I can configure.
      - tialaramex 6y ago
        I largely don't use clipboard with my password manager and I'd guess plenty of people are similar. In my case I have zx2c4's pass and a Firefox extension named PassFF, so the extension just gets the usernames, passwords and anything else via IPC. It does have a clipboard mode with an expiry timer, but I very rarely need that for anything. Firefox's built-in password manager similarly doesn't use the clipboard, Google's doesn't, I believe Apple's doesn't.
        Red_Leaves_Flyy 6y ago
        In light of numerous browser exploited I've switched to an external third party password manager. On android, even givin proper permissions, the app fails to recognize many password inputs in apps, sites, etc. Probably the result of bad design on the site or app operators part. On desktop the pwd app just works.

JoshTriplett 6y ago

Your bank doesn't need the concept of a username. A service may need a username if it's going to have social features, public content, or other ways in which users interact with each other. If people just log in and use the service, let them use an email address as their login (which is already unique), and don't make them pick a username at all.

akersten 6y ago
In that case, the email is the username, and the problem remains: are josh@gmail.com and jоsh@gmail.com the same user? To the system, of course they're different - it's just looking at the bytes. Problem comes when a human interacts with the account. Maybe they see the email on the account and manually type it in to another system. Or records are printed as part of a lawsuit and has to be transcribed. Allowing indistinguishable characters in unique tokens creates confusion at best. Broadly I agree that we should reduce our reliance on unique identifiers, and I don't have a good answer for the right approach, but certainly we can't abandon the concept of a unique identifier altogether: it predates computers and the character encoding mess we made, by a long time.
- deleted 6y ago
  [deleted]
- inetknght 6y ago
  > are josh@gmail.com and jоsh@gmail.com the same user? I like to think I have a keen eye and pay attention to subtle details. I don't think I see a difference between the two addresses. Your message seems to state they're different though. Did HN normalize the differences? Did my browser? In a blaze of stupidity, I decided to to copy and paste into my terminal and pipe it through a hex dump [0]. * The character difference doesn't show up in the viewport in Firefox; of course, it's rendered. * The character difference doesn't show up in the HTML editor; of course, it's showing the "raw text" and the "raw text" is valid unicode. * It doesn't show up in the browser's network inspection of the response payload. That's the scariest part in Firefox IMO. * It doesn't show up in my Terminal either. Why shouldn't it? We've fought long and hard for terminals to support Unicode. Of course, then there's the fact that I decided to copy and paste from a browser into my terminal even though I already knew I shouldn't [1]. What else could be hidden in unicode? An entire bash script starting with `sudo`, perhaps? Websites can already inject their shitware into the clipboard with clipboard events [1]. [0]: https://knightoftheinter.net/img/hacker%20news%20id%2023774300.png https://knightoftheinter.net/img/hacker%20news%20id%20237743... [1]: https://security.stackexchange.com/q/39118/47800 https://security.stackexchange.com/q/39118/47800
  - FreeFull 6y ago
    The second email address uses the Cyrillic small letter O, which renders the same as the Latin small O in almost all fonts. You can see this in your hex dump, too: Instead of a single o, your hex dump shows two bytes for the second character in the second email address.
    - inetknght 6y ago
      Yup! I was surprised they're rendered the same. The hex dump didn't lie even though everything until then did.
msla 6y ago
There's a problem with using email addresses as IDs which has nothing to do with Unicode: Is frobozz@example.com the same as frobozz@example.com? Don't bother comparing bytes: What's changed is the time, and who owns the frobozz@example.com email account. Names need to have some kind of stability over time to be useful, and need to have some mechanism whereby they can be changed gracefully if they need to be. Email addresses have neither of those properties. Mailing addresses have the same problems to some extent, but at least most mail systems should have some concept of forwarding addresses by now. Email is never going to.
- Spivak 6y ago
  I don’t see this as a problem so long as you don’t treat the email as the permanent source of truth of the account identity and instead have it be the email you happen to have associated with the account at that time. We have abstracted the notion of passwords as “a collection of authenticators defined by the user”, no reason your account can’t have a collection of identifiers as well.
  - thephyber 6y ago
    I agree with you that "identity" has many attributes of which an email address is only one. The problem is that in practice, control of the email address on record is sufficient to take over many modern accounts. Bank accounts likely shouldn't fall into this category, but most web sites don't have bank account level of security. Hotmail created a hornet's nest of problems when they started recycling email addresses after 6 (or 18?) months of inactivity. It allows a quick "password reset", then the account is now owned by whomever controls the email address. Effectively, the identity is hijacked because control of the email address was most of the authentication mechanism. Queue the spam messages and fraud/phishing. Also developing/managing a customer service tool which allows them to decipher these "takeover" events and ensure the person contacting them used to own the account is difficult and sometimes not possible.
    - hombre_fatal 6y ago
      Fastmail, a darling of HN, does the same.
mc32 6y ago
Some banks don’t have a “username” to log in but insist on “account number”. Which works but is not something I remember easily and forced me to use a PWD manager, which I guess is a good thing.
- inetknght 6y ago
  > forced me to use a PWD manager, which I guess is a good thing. Just as long as you aren't copying those bank credentials into your clipboard :)
  - Red_Leaves_Flyy 6y ago
    There should only be to features exposed from the clipboard API. 1. Push. Add a new item to the clipboard. 2. For apps, with an opt in permission. Delete items added by the app. Good for password managers. Also, it's basically impossible to use a password manager without using the clipboard. At the one I use will automatically remove the items it sets after a timeout I can configure.
    - tialaramex 6y ago
      I largely don't use clipboard with my password manager and I'd guess plenty of people are similar. In my case I have zx2c4's pass and a Firefox extension named PassFF, so the extension just gets the usernames, passwords and anything else via IPC. It does have a clipboard mode with an expiry timer, but I very rarely need that for anything. Firefox's built-in password manager similarly doesn't use the clipboard, Google's doesn't, I believe Apple's doesn't.
      - Red_Leaves_Flyy 6y ago
        In light of numerous browser exploited I've switched to an external third party password manager. On android, even givin proper permissions, the app fails to recognize many password inputs in apps, sites, etc. Probably the result of bad design on the site or app operators part. On desktop the pwd app just works.