9 ms·

Identity Beyond Usernames

181 points by polm23 6y ago

deleted 6y ago
[deleted]
akersten 6y ago
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
      - 6y ago
  - 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.
ryukafalz 6y ago
I like the petname approach that GNS[0] takes - there are stable identifiers (they're public keys) but users are meant to refer to identifiers using local names (or names that their contacts have set). [0] https://tools.ietf.org/id/draft-schanzen-gns-01.html https://tools.ietf.org/id/draft-schanzen-gns-01.html
- memexy 6y ago
  Generally, using cryptography or associated cryptographic functions is the way to go when trying to make robust systems. Joe Armstrong has a great talk where he outlines how to create a content addressable store for storing and working with knowledge/data. He suggests using SHA256 content hashing because giving items of data unique names is a hard problem so we might as well name pieces of data by their content hashes and then have a human readable pointer. -- https://www.youtube.com/watch?v=lKXe3HUG2l4 https://www.youtube.com/watch?v=lKXe3HUG2l4
tsimionescu 6y ago
The author's solution is to shift the problem of uniqueness of usernames to email, as if email is less likely to change than a site-specific username. The opposite is actually true - there are many reasons to change your email, while changing your username on the vast majority of websites is simply unnecessary (e.g. anything without a social component, such as banks, shops, Healthcare providers etc.). Not to mention, if you don't have a system for ensuring unique usernames, you also shift the burden of ensuring identity to your other users, who now have to understand how to distinguish different users with the same name.
- gcbw3 6y ago
  to me it seems the suggestion is to allow aliases (nicknames, images, utf, qr-code, text) and stick with numerical ids (or whatever you use as the true primary key, which can be email or phone number i guess, but hope not). Even hints that for directories, etc at the end.
  - crooked-v 6y ago
    Discord and Blizzard both use a unique numerical ID as the true source of identity (your name displays like "Mr. Bob#1234", but only the "1234" part is actually important), while using email for logging in. The email and the display name can both be changed at any time.
    - tonyarkles 6y ago
      And ICQ! While AIM was letting people choose usernames, ICQ looked deep into your soul and assigned you an ID based on the order in which you joined :)
      - mey 6y ago
        Still remember my ICQ number even though it got account hijacked LONG ago.
    - csande17 6y ago
memexy 6y ago
> This even allows them to have fully-Unicode usernames; username phishing is less of a problem when users expect duplicate usernames, and none of your systems depend on username uniqueness. It's surprising but providing an extra degree of freedom makes the system more robust. Username phishing is a real problem on Twitter because people expect unique names associated with each person they interact with but if usernames can not be assumed to be unique then using the name as a heuristic for identity is no longer a viable shortcut so people have to develop other ways of making sure they're talking to who they think they're talking to. On a related note, keybase (keybase.io) proofs never made sense to me until I started thinking about how I would prove to people that I am indeed who I say I am. Keybase provides a cryptographic basis for trust, which is much better than what most social media systems currently support with their verification mechanisms. I personally trust cryptographic signatures over whatever verification mechanism Twitter is using to provide blue check marks to verified accounts.
User23 6y ago
This is why I like hexl-mode[1]. [1] https://www.emacswiki.org/emacs/HexlMode https://www.emacswiki.org/emacs/HexlMode
notJim 6y ago
GDPR adds an interesting wrinkle in all this. GDPR requires both the right of removal (removing @-mentions) and the right of rectification (updating them.) So if I change my name from notJim to notJohn, GDPR requires* services to update previous @-mentions from notJim to notJohn, and similarly requires services to remove old mentions of notJim if I request removal. Using an identifier behind the scenes greatly simplifies this, because instead of dealing with text, you fetch the appropriate display name at render time. * IANAL, etc, and I'm sure requirements and interpretations of GDPR vary, but I do know that my company invested quite a lot into systems to fix this @-mentioning issue, so at least some people thinks it requires this and are willing to spend probably millions of dollars of engineering time to comply with said requirement. Personally, I support this provision.
miki123211 6y ago
If you want to learn how to do accessibility, specifically alt texts, properly, this guy does it exactly right. I'm a screen reader user and don't encounter those often. There's even some fun in those alt texts, i.e. "screenshot of unicode character inspector revealing "epic" to actually be "еріс". of course you, a screen reader user, aren't fooled." Btw, most people would just label that "screenshot", which is extremely infuriating.
- tenryuu 6y ago
  I'm not a screen reader user, but I have ublock origin on my mobile filtering out media elements over 1000kb. Instead I was given the alt texts for at least one of the images. It's great when people do this, so many times I also just get emails from marketing that are images only without any descriptors, and I can't help but think about how many international groups simply don't care about accessibility.
  - andrenotgiant 6y ago
    wow I didn't know uBlock could do that! Does it actually prevent the large media elements from downloading? how?
    - recursive 6y ago
      Presumably by closing the connection based on the Content-Length response header.
- deleted 6y ago
  [deleted]
- jonnytran 6y ago
  I regularly use the speech feature of macOS to read web pages aloud to me, so I was also pleasantly surprised to hear meaningful descriptions of the images from the alt text. Maybe one day computers will be able to describe to me what is in an image without a person having to type it.
gumby 6y ago
The author’s choice of the epic / epic web sites was inspired too: those Cyrillic characters spell out “Eris” the goddess of...discord!
kibwen 6y ago
> The only solution is to develop systems that don’t have usernames. I disagree that this is the only solution. The OP comes very close to discovering an alternative one: don't allow users the power to select their own arbitrary username. When a user makes an account on your site (and if your site actually needs publicly-displayed usernames in the first place), give them the option of, say, ten usernames generated by the site itself; these don't need to be numeric codes like WeChat does, they can be pronounceable phrases in the same manner that Gfycat generates URLs. Everyone will end up with names like "questionable wet aplomado falcon", "each unlawful harlequin bug", "icy inferior iceland gull", which honestly isn't any worse than the average name I encounter on Reddit or elsewhere. The biggest downside(?) of this approach is that it makes it harder for someone to build their personal brand, but the older I get the more I think it's a bad idea to use a consistent nickname across different websites.
- kitotik 6y ago
  > The biggest downside(?) of this approach I tried this approach for a service awhile back, and the biggest hurdle was educating the users. Even determining what to call it was a huge challenge, as it’s clearly not a ‘username’.
  - kibwen 6y ago
    In what way would the user need to be educated? Social products like IRC, Twitter, and Reddit have accustomed users to seeing opaque, often-nonsensical strings next to every action taken by every user, and the only difference here is that a given user hasn't had the opportunity to select their own opaque and nonsensical string to associate with their actions. They wouldn't even need to remember this string to log in, because sites use email or third-party login services for that (and even if they did need to know their own username to log in, their browser would remember it for them).
    - kitotik 6y ago
      I’ll happily accept any wireframes you may have that wouldn’t increase friction beyond the typical “choose your username and password”. You may be overestimating the typical non-hackernews user. It’s at least as challenging as getting users to use things like 2fa and/or recovery codes.
MR4D 6y ago
Unicode is what happens when humans see the Tower of Babel and someone says, “hold my beer - I got this.”
politicdone 6y ago
I know the article isn't about this, but I loved this part the main problem — plain text editing forces us to conflate our model of identity with our model for labels. The identity you have is not the labels others or you apply to you. But that very notion is advocated by the fake left thought police to tell you you have to conflate the two, in fact, your identity is nothing except the labels they proscribe you, and they demand you act in conformance with the rules they invent for that label. It's funny that their idea hits a wall in this practical expression in coding. And I wonder if illumination will strike more generally
falcolas 6y ago
Unicode usernames in Discord are my bane. I can’t search for them. I can’t type them in manually. I can’t even copy their official name because the app interface doesn’t allow selecting them. If the right click context menu doesn’t allow the operation I need, I’m just SOL. A complete clustertruck.
ridaj 6y ago
The author lists a bunch of gripes with alphanumeric usernames but I'm fact many of these shortcomings are not worth a switch away towards non-unique, freeform names (John Smith), or towards random ID allocation (whether purely numeric or word-like). In spite of what I'd personally have bet on a decade ago, I don't actually know many international users who complain about alphanumeric handles. People can/should still have Unicode-ish display names on top of handles, change those, and be searched by those. Twitter does this well for example. But a human-readable, ASCII-friendly, user-chosen unique handle is the best thing I've seen so far for disambiguation on a social network.
chrismorgan 6y ago
Purely as an implementation note, the Slack rich text editing widget is quite poor, and the Discord rich text editing widget is lousy. Both have serious bugs (Discord’s seems to be almost nothing but bugs) where their widget just doesn’t behave like a normal <input type=text> or even contenteditable (which behaves subtly differently), in decidedly off-putting ways. On @-mention autocompleters in general (and :emoji-code: completers too, and GitHub/GitLab issue/PR #-reference completers), I honestly can’t think of one that I’m completely happy with. Every last one I’ve experienced harms the editing experience with surprising and inconsistent behaviour. It’s all surprisingly hard to get right, and very few people that implement seem to even try to actually get it right. Perhaps I should perform a more detailed study, enumerating the problems clearly, and try to create one that’s as close to flawless as is possible. (I’m sceptical that flawless is actually possible with the tools given web tech, especially in Blink and I think WebKit which don’t properly support the difference between before-end and after-end in selection in contenteditable, which matters more than you might think.)
yencabulator 6y ago
Here's a thought I had when Twitter was still very new: 1. Sites should forbid dots in "normal" usernames. 2. Usernames with dots can only be registered by demonstrating ownership of the corresponding DNS domain. Now you can have your favorite "brand" across all sites, nobody else can register it before you, etc. This is obviously not very non-techie friendly at this time...

181 points by polm23 6y ago

deleted 6y ago

[deleted]

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
    - 6y ago
- 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.

ryukafalz 6y ago

I like the petname approach that GNS[0] takes - there are stable identifiers (they're public keys) but users are meant to refer to identifiers using local names (or names that their contacts have set). [0] https://tools.ietf.org/id/draft-schanzen-gns-01.html https://tools.ietf.org/id/draft-schanzen-gns-01.html

memexy 6y ago
Generally, using cryptography or associated cryptographic functions is the way to go when trying to make robust systems. Joe Armstrong has a great talk where he outlines how to create a content addressable store for storing and working with knowledge/data. He suggests using SHA256 content hashing because giving items of data unique names is a hard problem so we might as well name pieces of data by their content hashes and then have a human readable pointer. -- https://www.youtube.com/watch?v=lKXe3HUG2l4 https://www.youtube.com/watch?v=lKXe3HUG2l4

tsimionescu 6y ago

The author's solution is to shift the problem of uniqueness of usernames to email, as if email is less likely to change than a site-specific username. The opposite is actually true - there are many reasons to change your email, while changing your username on the vast majority of websites is simply unnecessary (e.g. anything without a social component, such as banks, shops, Healthcare providers etc.). Not to mention, if you don't have a system for ensuring unique usernames, you also shift the burden of ensuring identity to your other users, who now have to understand how to distinguish different users with the same name.

gcbw3 6y ago
to me it seems the suggestion is to allow aliases (nicknames, images, utf, qr-code, text) and stick with numerical ids (or whatever you use as the true primary key, which can be email or phone number i guess, but hope not). Even hints that for directories, etc at the end.
- crooked-v 6y ago
  Discord and Blizzard both use a unique numerical ID as the true source of identity (your name displays like "Mr. Bob#1234", but only the "1234" part is actually important), while using email for logging in. The email and the display name can both be changed at any time.
  - tonyarkles 6y ago
    And ICQ! While AIM was letting people choose usernames, ICQ looked deep into your soul and assigned you an ID based on the order in which you joined :)
    - mey 6y ago
      Still remember my ICQ number even though it got account hijacked LONG ago.
  - csande17 6y ago

memexy 6y ago

> This even allows them to have fully-Unicode usernames; username phishing is less of a problem when users expect duplicate usernames, and none of your systems depend on username uniqueness. It's surprising but providing an extra degree of freedom makes the system more robust. Username phishing is a real problem on Twitter because people expect unique names associated with each person they interact with but if usernames can not be assumed to be unique then using the name as a heuristic for identity is no longer a viable shortcut so people have to develop other ways of making sure they're talking to who they think they're talking to. On a related note, keybase (keybase.io) proofs never made sense to me until I started thinking about how I would prove to people that I am indeed who I say I am. Keybase provides a cryptographic basis for trust, which is much better than what most social media systems currently support with their verification mechanisms. I personally trust cryptographic signatures over whatever verification mechanism Twitter is using to provide blue check marks to verified accounts.

User23 6y ago

This is why I like hexl-mode[1]. [1] https://www.emacswiki.org/emacs/HexlMode https://www.emacswiki.org/emacs/HexlMode

notJim 6y ago

GDPR adds an interesting wrinkle in all this. GDPR requires both the right of removal (removing @-mentions) and the right of rectification (updating them.) So if I change my name from notJim to notJohn, GDPR requires* services to update previous @-mentions from notJim to notJohn, and similarly requires services to remove old mentions of notJim if I request removal. Using an identifier behind the scenes greatly simplifies this, because instead of dealing with text, you fetch the appropriate display name at render time. * IANAL, etc, and I'm sure requirements and interpretations of GDPR vary, but I do know that my company invested quite a lot into systems to fix this @-mentioning issue, so at least some people thinks it requires this and are willing to spend probably millions of dollars of engineering time to comply with said requirement. Personally, I support this provision.

miki123211 6y ago

If you want to learn how to do accessibility, specifically alt texts, properly, this guy does it exactly right. I'm a screen reader user and don't encounter those often. There's even some fun in those alt texts, i.e. "screenshot of unicode character inspector revealing "epic" to actually be "еріс". of course you, a screen reader user, aren't fooled." Btw, most people would just label that "screenshot", which is extremely infuriating.

tenryuu 6y ago
I'm not a screen reader user, but I have ublock origin on my mobile filtering out media elements over 1000kb. Instead I was given the alt texts for at least one of the images. It's great when people do this, so many times I also just get emails from marketing that are images only without any descriptors, and I can't help but think about how many international groups simply don't care about accessibility.
- andrenotgiant 6y ago
  wow I didn't know uBlock could do that! Does it actually prevent the large media elements from downloading? how?
  - recursive 6y ago
    Presumably by closing the connection based on the Content-Length response header.
deleted 6y ago
[deleted]
jonnytran 6y ago
I regularly use the speech feature of macOS to read web pages aloud to me, so I was also pleasantly surprised to hear meaningful descriptions of the images from the alt text. Maybe one day computers will be able to describe to me what is in an image without a person having to type it.

gumby 6y ago

The author’s choice of the epic / epic web sites was inspired too: those Cyrillic characters spell out “Eris” the goddess of...discord!

kibwen 6y ago

> The only solution is to develop systems that don’t have usernames. I disagree that this is the only solution. The OP comes very close to discovering an alternative one: don't allow users the power to select their own arbitrary username. When a user makes an account on your site (and if your site actually needs publicly-displayed usernames in the first place), give them the option of, say, ten usernames generated by the site itself; these don't need to be numeric codes like WeChat does, they can be pronounceable phrases in the same manner that Gfycat generates URLs. Everyone will end up with names like "questionable wet aplomado falcon", "each unlawful harlequin bug", "icy inferior iceland gull", which honestly isn't any worse than the average name I encounter on Reddit or elsewhere. The biggest downside(?) of this approach is that it makes it harder for someone to build their personal brand, but the older I get the more I think it's a bad idea to use a consistent nickname across different websites.

kitotik 6y ago
> The biggest downside(?) of this approach I tried this approach for a service awhile back, and the biggest hurdle was educating the users. Even determining what to call it was a huge challenge, as it’s clearly not a ‘username’.
- kibwen 6y ago
  In what way would the user need to be educated? Social products like IRC, Twitter, and Reddit have accustomed users to seeing opaque, often-nonsensical strings next to every action taken by every user, and the only difference here is that a given user hasn't had the opportunity to select their own opaque and nonsensical string to associate with their actions. They wouldn't even need to remember this string to log in, because sites use email or third-party login services for that (and even if they did need to know their own username to log in, their browser would remember it for them).
  - kitotik 6y ago
    I’ll happily accept any wireframes you may have that wouldn’t increase friction beyond the typical “choose your username and password”. You may be overestimating the typical non-hackernews user. It’s at least as challenging as getting users to use things like 2fa and/or recovery codes.

MR4D 6y ago

Unicode is what happens when humans see the Tower of Babel and someone says, “hold my beer - I got this.”

politicdone 6y ago

I know the article isn't about this, but I loved this part the main problem — plain text editing forces us to conflate our model of identity with our model for labels. The identity you have is not the labels others or you apply to you. But that very notion is advocated by the fake left thought police to tell you you have to conflate the two, in fact, your identity is nothing except the labels they proscribe you, and they demand you act in conformance with the rules they invent for that label. It's funny that their idea hits a wall in this practical expression in coding. And I wonder if illumination will strike more generally

falcolas 6y ago

Unicode usernames in Discord are my bane. I can’t search for them. I can’t type them in manually. I can’t even copy their official name because the app interface doesn’t allow selecting them. If the right click context menu doesn’t allow the operation I need, I’m just SOL. A complete clustertruck.

ridaj 6y ago

The author lists a bunch of gripes with alphanumeric usernames but I'm fact many of these shortcomings are not worth a switch away towards non-unique, freeform names (John Smith), or towards random ID allocation (whether purely numeric or word-like). In spite of what I'd personally have bet on a decade ago, I don't actually know many international users who complain about alphanumeric handles. People can/should still have Unicode-ish display names on top of handles, change those, and be searched by those. Twitter does this well for example. But a human-readable, ASCII-friendly, user-chosen unique handle is the best thing I've seen so far for disambiguation on a social network.

chrismorgan 6y ago

Purely as an implementation note, the Slack rich text editing widget is quite poor, and the Discord rich text editing widget is lousy. Both have serious bugs (Discord’s seems to be almost nothing but bugs) where their widget just doesn’t behave like a normal <input type=text> or even contenteditable (which behaves subtly differently), in decidedly off-putting ways. On @-mention autocompleters in general (and :emoji-code: completers too, and GitHub/GitLab issue/PR #-reference completers), I honestly can’t think of one that I’m completely happy with. Every last one I’ve experienced harms the editing experience with surprising and inconsistent behaviour. It’s all surprisingly hard to get right, and very few people that implement seem to even try to actually get it right. Perhaps I should perform a more detailed study, enumerating the problems clearly, and try to create one that’s as close to flawless as is possible. (I’m sceptical that flawless is actually possible with the tools given web tech, especially in Blink and I think WebKit which don’t properly support the difference between before-end and after-end in selection in contenteditable, which matters more than you might think.)

yencabulator 6y ago

Here's a thought I had when Twitter was still very new: 1. Sites should forbid dots in "normal" usernames. 2. Usernames with dots can only be registered by demonstrating ownership of the corresponding DNS domain. Now you can have your favorite "brand" across all sites, nobody else can register it before you, etc. This is obviously not very non-techie friendly at this time...