[HN Gopher] Identity Beyond Usernames
___________________________________________________________________
Identity Beyond Usernames
Author : polm23
Score : 52 points
Date : 2020-07-08 06:09 UTC (16 hours ago)
(HTM) web link (lord.io)
(TXT) w3m dump (lord.io)
| tsimionescu wrote:
| 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 wrote:
| 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 wrote:
| 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.
| csande17 wrote:
| I'm pretty sure the ID that Discord and Blizzard use as the
| "true" source of identity (as in, the key they store in the
| database to keep track of who's on your buddy list) is
| different from the "#1234" number used to disambiguate
| people with the same username.
|
| In particular, that number is only four base-10 digits
| long, and I'm pretty sure there are more than 10,000 people
| in the world who have ever played Hearthstone.
| tonyarkles wrote:
| 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 wrote:
| Still remember my ICQ number even though it got account
| hijacked LONG ago.
| miki123211 wrote:
| 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 "eris". of course you, a screen reader user, aren't
| fooled."
|
| Btw, most people would just label that "screenshot", which is
| extremely infuriating.
| memexy wrote:
| > 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.
| [deleted]
| akersten wrote:
| 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 the
| king , 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 wrote:
| 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 wrote:
| In that case, the email is the username, and the problem
| remains: are josh@gmail.com and josh@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.
| inetknght wrote:
| > _are josh@gmail.com and josh@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%20
| 237743...
|
| [1]: https://security.stackexchange.com/q/39118/47800
| [deleted]
| msla wrote:
| 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 wrote:
| 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.
| mc32 wrote:
| 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 wrote:
| > _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 wrote:
| 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.
| ryukafalz wrote:
| 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
| memexy wrote:
| 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
| User23 wrote:
| This is why I like hexl-mode[1].
|
| [1] https://www.emacswiki.org/emacs/HexlMode
| notJim wrote:
| 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.
___________________________________________________________________
(page generated 2020-07-08 23:00 UTC)