Email addresses are not good 'permanent' identifiers for accounts
utcc.utoronto.ca
utcc.utoronto.ca
Emails change, people lose access to old emails.
People dislike usernames, they want to be able to choose non-unique ones rather than end up with user53267 or something inane.
People lose devices, just storing a secret UUID in their cookie, or using a passkey from their device isn't going to work.
There is no ideal solution except to blend a variety of things together, for some people email is pretty stable for long time and they like it as the identity, for others their usernames are stable and they prefer that as the identity... though I know of no-one that has had the same primary device for more than years (not decades) so perhaps that one will never work.
I do think this is important though, where it comes up a lot is a work email account, a first.last@company.com, and how all of the vendor software utilises "Sign in with Google", and it's the email address they then store in the vendor app as the identifier...
People get married, people get divorced, people transition, people move culture and choose new names... names change, and so do email addresses.
Perhaps OIDC and the like needs a new extension: a standard API to change a username, and a standard API to change an email address.
And even those change
As someone that once faced serious jail time for plants, I think that would have been a nice option, but I wasted two years of my life in court/etc.
Either we are giving people second chance without stigma or we are tracking everyone forever. I'm fine with both.
Of course this means that an ID token should not contain an e-mail address under `sub`.
This is extra fun when the company in question does a lot of their business offering complicated accounts to customers, and has an external facing identity solution that deals with all of this easily: just not for their own workers, including those maintaining the external-facing identity system.
The shoemaker's children always go barefoot
Because it was trivial to impersonate someone. The old usernames supported full UTF-8, enabling a wide variety of attacks.
And by paying for nitro, you could choose the numbers too, so step 1. Find someone you want to impersonate, copy their username, and replace one character with a visually identical one, but a different one. Step 2 - pay for nitro, and choose the numbers too.
As usual, malicious actors are the reason why we can’t have nice things.
As far as I can tell, this hasn't been a big problem in practice. Calls can forge caller ID. Emails can forge the From field. It's irritating but isn't exactly halting society.
I am really not sure why Discord made the change. Wanted to prune inactive users? Wanted to sell Nitro Super Mega Premium to jump ahead in line to get your username of choice? Just bored?
But you can’t have a username that looks exactly the same anymore.
I’m in some 140 discord servers. The amount of spam from people impersonating someone popular has reduced drastically since this change.
I wouldn’t call “one click” an investigation.
1. Use a guid-like value as your internal identifier. All internal references in your databases to a user should use that.
2. Use a second user friendly identifier for the user to login (i.e. Email). Feel free to rebind this if the user needs to change it. Keep a 1-to-1 relationship between the two.
I remember losing cell service after a storm, but the internet still worked. I couldn't login to gmail (~10-12 years ago when this was the only 2fa) because my phone couldn't receive text messages with the 2fa code.
Even if you lose all the keys to your house, you'll need to get new locks. If the locksmith who is going to let you into your house does everything by the book, they'll need you to prove you actually live there. I had a friend thrown in jail for a day because his ID, keys, etc. were lost in a kayaking trip, and was arrested for attempting to break into his own house.
My point is, there really isn't a good answer here. The platform equivalent to hiding keys in the bushes is printing out one-time passwords. That works pretty well, but also has its own drawbacks.
I'm the only one to blame because I changed my password at 2 in the morning when notified that someone in another country used it. I didn't put my info into a password manager or remember it because I wasn't truly awake at the time.
When recovering I had to go through a bunch of steps and did great up until the email one. Well, Google was firm about wanting access to that email. Odd, considering the domain wasn't registered at the time of requesting a password reset and so I would consider it a security violation to accept that.
Needless to say, I am much more stringent on making sure this stuff is set up correctly now.
Not sure what the gripe is here, especially with a one year notification period.
P.S. not a gripe, just adding an anecdata.
The real problem, though, is that we seem to need digital identity solutions to be perfect as opposed to “good enough”. No solution is perfect and we’ll be stuck on email as long as the enterprise security nuts (who need everything device-bound and vendor attested) and anon-in-the-ether privacy schoolers (who think any stable identifier whatsoever is a heinous crime) are part of the conversation.
Imagine if everyone just used mobile drivers licenses issued to whatever self-sovereign wallet the user chooses. Identity issuing, revocation, and recovery is then handled by all the things society has already built to handle meatspace identity. Account recovery involves a trip to your local gov’t office to re-issue your ID credential. Which means you need some chain of trust to your birth certificate. You’re going to treat your mDL credential wallet with a lot more reverence if that’s the recovery flow, so some of these problems solve themselves if we stop using punk short-names everywhere online.
Relying parties that need human uniqueness, age, and/or nationality guarantees use the mDL verifiable credential. Law probibits relying parties from aggregating and selling/transferring information obtained for purposes of authentication from a VC. Ad-tech privacy problem solved.
Services that don’t need proof of human uniqueness etc. can just skip the VC part of the equation and use basic passkeys and implement short-name reclamation.
A permanent identity comes with many additional mechanics, far beyond just a stable identifier. The biggest one is post karma (including likes): IMO it's at the core of almost everything what's wrong with the modern web. It introduces vile personal and group incentives and leads to an eventual destruction of any honest conversation. While this mechanic exists on public forums, I won't use a permanent identity.
But why do you need to tie it to your driver's license? Tie it to whatever kind of account recovery token you like, put that in a safety deposit box at a bank (available for ~$20/year), and then you can get access to that with your government ID if all else fails.
This requires no new infrastructure to screw up or get broken into and doesn't tie your internet activity to your name while still allowing you to use your name to recover your accounts.
> Relying parties that need human uniqueness, age, and/or nationality guarantees use the mDL verifiable credential.
This is variously unnecessary and ineffective.
The correct way to do age verification is to ask the client's browser if the user is a minor. If the user is a minor, either their parents will have configured the device to answer truthfully or the minor has access to an adult willing to allow it, against which no remote system is secure anyway because the adult has an adult ID.
This is the same reason human verification doesn't work like that. You still have no idea if you're talking to a human, all you know is the device on the other end has somebody's ID attached. Individuals who aren't supposed to be using AI still have a human ID and criminal organizations not only have their own IDs but also any they can steal.
It's not clear why proving nationality over the internet is necessary but most of the obvious use cases are dystopian and requiring you to visit a physical office once in your life to prove your nationality to some bureaucracy (after which you can use your account) seems like a minor burden -- and more secure -- than trying to do this.
That kind of system is not worth the candle. The tracking risk is large, the benefit is small, there are too many ways to screw it up and it would inevitably be politically compromised and hard to change.
All I’m arguing is that we should extend the concept of your state ID cryptographically into cyberspace. Amd that it should be used for recovery flows where real identity matters. There’s nothing new here (society already works this way) other than the protocols and specs to agree on document and signature format, which is luckily something we happen to excel at managing.
None of your counter suggestions solve any practical problems. A liquor store isn’t going to simply “ask the user” whether they’re of age. They need more formal proof. Users don’t rent safe deposit boxes at banks, and even if they did that would be chained back to your physical ID anyway so your apparent solution isn't a real solution.
The dystopian worries are hyperbolic and mostly FUD. If a service needs your info and you need the service, you’ll give it to them.
Anyway mobile DL is already happening. I’d rather a state that I have at least a modicum of control over be the root of my digital identity than some corporate run email system than can evict me without cause.
Nearly every institution trusts the credentials that it issues. Your employer trusts your ID badge that they issued. Your bank trusts your bank card that they issued. Why does anything else even need to exist?
> All I’m arguing is that we should extend the concept of your state ID cryptographically into cyberspace.
And then it will be designed poorly but everything will start requiring it because the poor design will allow it to be used as a tracking ID (even if it was claimed not to, because malicious corporations are clever), but once everything is using it the poor design will be difficult to change. See social security numbers (which never should have been public).
> A liquor store isn’t going to simply “ask the user” whether they’re of age.
A liquor store doesn't need to verify identity over the internet because you're standing in the liquor store. Unless it's an internet liquor store in which case they already have your identity because you've provided them with payment info and a shipping address, and checking ID at the point of sale is useless when it's the point of delivery you care about, i.e. you need the delivery driver to check it. Otherwise minors can just buy alcohol with an adult's ID unbeknownst to both the seller and the adult, and have it delivered to themselves where nobody checks who receives the package.
You can't verify age over the internet because you have no way to know if the credentials being used are those of the user or someone else. In person you compare the picture on the ID to their face, or can notice if they're clearly a child.
> Users don’t rent safe deposit boxes at banks, and even if they did that would be chained back to your physical ID anyway so your apparent solution isn't a real solution.
The bank doesn't even know what's in the box, and you're not required to use a bank if you don't want to. You can use any safe place you'll still be able to access even if your house burns down etc. A safety deposit box is an example of such a place which is relatively inexpensive. Many people do in fact use them to store important documents -- that's one of the main things they're for.
> The dystopian worries are hyperbolic and mostly FUD. If a service needs your info and you need the service, you’ll give it to them.
If you make it easy to demand then services that don't need the info will demand it, and then you'll give it to them because you need the service. Which is the evil to be prevented, by making it hard to demand, so only services that actually need it will demand it.
> Anyway mobile DL is already happening.
That which is made can be unmade. Easier if done sooner.
> I’d rather a state that I have at least a modicum of control over be the root of my digital identity than some corporate run email system than can evict me without cause.
So buy a domain name for $15/year to use for your email, which you can point to any third party email service if you don't want to host it yourself, and you can point somewhere else if they disappear or become adversarial. Or make it easier for the average person to do this (though it's really not that hard).
Depends on the implementation. Some passkeys are device bound. The free ones, typically. Unless you trust Apple and Google to preserve and protect private keys.
Is there anywhere to follow progress on this? I don't think anyone actually implements import/export of passkeys yet.
There are ways to set passkeys as non-exportable from device I think but that is not the default.
What does legacy mean to you? The usual meaning of outdated is inapplicable in this case.
It will be worse than the WEI framework in terms of restricting access to a certain class of people. If you're already disadvantaged and don't have the ability to provide documents to the DOL proving who you are, how are you supposed to get access to your online identity again to get into a mail account and try to apply for work or housing?
Imagine someone steals your real world wallet and gets your online identity credentials, goes posting revenge porn and crypto spam and gets you booted off every platform. You get cancelled and lose your job because your online identity is tied explicitly to meat space and the court of public opinion operates on guilty even after proving innocence.
Meanwhile you're trying to recover your life--social, physical, and digital--, but can't get into any platforms online. None of your accounts work anymore. You can't access your backups, or get into your contacts because your device is no longer trusted because it's tied to a blocked Microsoft/Google/Apple account. You can't access your house because your IoT security is tied to your online accounts which have been disabled. You can't access your physical documents safe. You have to break into your house. You can't scan the QR code or NFC to verify identity after providing the alarm code. Police come, and arrest you because you can't prove who you are. You're crazed about your situation, babbling because of the insanity of it all and look like someone trying to steal a nice homeowner's documents.
I realize that's a pretty extreme Black Mirror level example a bit like Nosedive, but it's in the realm of possibility if we go down that route knowing that corporations are already trying to do device attestations. Maybe you'd have the prescience to have a physical security layer 0 for your IoT security, but many products people purchase won't because having to carry a key defeats the purpose of having the tech solution.
The scary enough reality is that if there is a single government provided signifier for an individual online, we will inevitably see sweeping tracking and censorship. They do as much as they can possibly do now. Why on Earth would anyone ever think they wouldn't do more?
No, thanks.
Ideally in a perfect world we'd have governments run OIDC systems similar to the US login.gov and these would delegate from an international master OIDC system at the UN. Everyone would have their citizenship passport ID and their UN ID, and the latter could serve as a "break glass" master key to support immigration and also limit the ability of countries to "digital death penalty" people.
I can think of some dystopian outcomes here, but IMHO they are not worse than the dystopian outcomes that come from corporate monopolist control of digital identity. At least in democracies one has some nominal influence over one's government and the latter is bound by the rule of law, and if you don't live in a democracy you can (or should be able to) leave.
You're right that identity is hard, and I think most of why it's hard is human rather than technical. One could create a decentralized identity layer from a block chain fairly easily but people would lose their keys etc.
Fake ids are a thing and the quality depends on how much you spend. Governments also have reasons to lie about identity themselves (think spies).
A true identity solution means being able to cross reference your identity across multiple entities (federal government, state and municipal, employers you’ve worked for, businesses you’ve interacted with, etc etc).
I'll reconsider once the corporate death counts begin to match the governmental ones but until then I'll take my chances.
Also in the UK various government types have tried to bring in national ID and the people rebel. People eh?
Immigration doesn’t work that way. You don’t lose or transition from one identity federation to another. You maintain both, typically for the rest of your life.
My personal wishlist is that decision makers and designers of identity systems must include people with real world experience of multiple nationalities, tax residencies, migration and so on.
Currently, these systems are already built on false premises and immigrants suffer a lot – not only because of malice but to a large extent because the bureaucrats didn’t think like security-minded engineers. The edge cases are extremely important when it comes to identity, because identity is required for a lot of basic needs. As the world is become more globalized, these issues are a lot more prevalent.
> and I think most of why it's hard is human rather than technical
Yes but I don’t see why that’s so surprising. It’s the identity of humans that’s the problem.
FWIW I think email is fantastic as identity, compared to the abysmal state of the alternatives. It doesn’t change when you cross a border like phone numbers. It’s not perfect when it comes to self-sovereignty and account recovery.
Umm, I'm not they're not that great as a primary identity either.
One edge case is that you can have have more than one valid passport for the one nationality. Another is of course that one can have more than one nationality.
The same thing risks happening with this government-approved online identity, I mean, how will the EU bureaucrats “handle” people like me that are openly against the West’s take in Ukraine? Will we get our accounts banned from posting pro-Russia content online?
Don't forget the Covid QR codes.
They restrict people to a single immutable identity, that may not conform to other governments, that may not accommodate different languages and character sets, that are not flexible of gender, that do not reflect relationship types that aren't typically monogamous... the list goes on.
They offer a poor base implementation that is only sufficient due to the legal identity seldom actually being needed online. Which is a good thing, because identity theft would be so much worse if that was everywhere.
In the UK we don't have as fixed an idea of an identity as people think, Cherie Blair is also Cherie Booth Q.C. , Elton John is also Reginald Dwight, and for both people, both identities are real identities and sufficient to get bank accounts in the name of, it's only when it comes to a tax record and passport that you are reduced to a single identifier, but who is to say that the name on that is the preferred name of a person?
My bank account, bank card, accounts on most of my things, do not match my passport and birth certificate.
This is a good thing because this is what people have, one single immutable identity.
What you've identified are problems with assumptions about the relationship between various things and identity.
A key one is the relationship between name and identity. Two people can have the same name but aren't the same person. A person ca change their name but they haven't become a new person.
I can do anything I want to myself honestly. I can color my hair, have a sex change, lose weight, gain weight, have height augmentation surgery, get piercings grow a beard, change my name, whatever, but I'm still the same person. That is immutable. I still have the same mother and father, the same birthdate, lived in the same places, attended the same schools, studied the same things, etc.
My identity as far as the government is concerned is still tied to a single number. Yeah, they make it hard to change a lot of the other stuff related to that number (for good reason), but ultimately they are pretty good at knowing who I am based on that number.
I don't actually like governments owning the identity layer, but then again I am of the "necessary evil" school of thought regarding most of what governments do. It's marginally better than having corporate monopolies own it.
I'm a giant fan of decentralized identity, but there are two insanely hard problems with it:
(1) People lose keys, forget passwords, or get them stolen. They also lose or break security key hardware. I've heard stories of people paying people to actually excavate dumps to find lost Bitcoin keys for example.
(2) There's a chicken or egg problem of getting sites to support any decentralized login scheme without a monopolist like Google pushing it, and the latter have no reason to do so since they want to monopolize the identity layer.
Problem (1) is solvable to some extent by having companies that escrow keys for you. Escrowing with them would not be mandatory but they'd offer a "break glass" service for people who are willing to trade a bit of (potential) privacy for it. A good escrowing service would have a terms of service that forbids misuse of your identity.
Problem (2) is probably harder. Big tech will actively refuse to support any system that doesn't hand them a monopoly or at least an oligopoly.
BTW this is one area where cryptocurrency could have found an actual bona fide beneficial use case! But it's not as profitable as running scams and casinos so nobody did it.
Example: https://instantusername.com
I've seen quite personal details being leaked because sometimes even smart people don't realise how easy it is to cross-reference given a unique username.
Google doesn't reuse usernames so if they are still around - in a few decades pretty much all unique usernames will belong to dead people.
For important stuff like banks and pensions they also have phone and physical address, so there’s a way to reconcile things like email changes, as rare as they are.
Login.gov is very good from a federal gov idp perspective, and I’m hoping it slowly develops into supporting a national ID and ubiquitous identity proofing to squash identity fraud but also streamline gov digital service delivery.
Government has failed to adapt with modern times and technology and has failed to provide modern and secure identification and authentication services for citizens.
I log in with my bank credentials to access my government tax account, talk about a total failure to do your job from the people still using SIN as an important piece of identity for some of the most important aspects of life.
This is a solvable problem. Governments can adapt and use modern technology to provide identity and authentication services, but they do not.
In my opinion this is a failure to be responsible for core government services, and I can only speculate why.
At least in many EU countries, they are adapting. I'm a fairly happy user of Irish myGovID (OIDC) and ROS (X509 "sign this message with your private key" challenge), and Polish Profil Zaufany (I think OIDC or CAS?).
The issues I see are:
- Each country has its own system, some documented, some not so much, some use OIDC, some SAML, some something more obscure.
- As an individual who moved countries, you end up with multiple accounts.
- As a developer you cannot easily register your own OIDC app. Send an email to some ministry and hope for the best. If you aren't part of government yourself, you may be out of luck.
It's tricky because you often need to let people reference username/emails for mentions and etc, so you just have to index all of em and translate to UUIDs for references behind the scenes.
It gets extra tricky with APIs. Consider AirPlane.dev which let's you specificy approvers via email. Now a user changes their name and their email. Well, that "IaC" suddenly references an invalid email or worse a different user because jane.doe joined after jane.doe-brown got their new email.
For login, it can help to have multiple methods. Then people can change from OIDC to password, or between providers.
Being a tolerated guest who pays little to none in someone’s servers is another issue.
Most large email providers are more like digital identity providers, and being a citizen of one of these big digital countries is neither democratic or setup for your long term preferences.
> It’s useful to have your own domain with your own email
A more permanent way to buy - not rent - domain names would solve many of these issues. And changing ownership of domains should be just as difficult as changing ownership of real estate, the only people benefiting from the current ease of changing domain ownership are speculators.
I had no idea or time to figure this out and luckily we weren’t the first to come across this :)
A domain that important is worth putting multiple recurring yearly calendar reminders up.
An email serving your identity is probably worth a bit more investing in.
It’s possible to leave a credit card on file to auto renew, renew for maximum years at a time, And lock down the domain enough to prevent hijacking.
Having too many active domains can be a pain tho
I think it could be something to start seeing instead like not paying a cell phone bill.
The impermanence of which isn’t the greatest.
The only “safe” email host is the one you run yourself or pay for with actual dollars, not data.
The hard part is taking your second paragraph to action. Most people are not ready for that conversation because the major freemail providers have been in service for such a long time that most people really can’t grasp the concept that email is something you have to pay for.
I really blame a lot of that on Google from the very beginning. Gmail, and essentially all free mail providers, are what they are today because of the precedent Google set and the only way companies were going to be able to compete with that was to also make their email services free.
You can easily lose access any particular email address, even if it's on your own domain. Losing access to all your email addresses and phone numbers at the same time is far less likely.
In which scenario would this happen, except for loss of ownership of the domain itself?
For instance, my main email address is on a domain that is now owned by my company (it wasn't originally). If I ever sell the company, I lose access to the domain as well. My wife's email address is on that domain too.
It solves the identity problem with decentralized identifiers though the secret sauce is the fractionally weighted multisig for enabling multi-device signing and account recovery with key rotation.
See the specification for more details: https://www.ietf.org/id/draft-ssmith-keri-00.html
Or the whitepaper: https://github.com/SmithSamuelM/Papers/blob/master/whitepape...
I think it's a good solution.
This is why I think email addresses are "good enough" - you can always spin up a new one for each identity you want to inhabit.
There absolutely is a good identity, and it's one provided by countries.
Conceptually there is ZIFO (Basic ID of natural person), that should be globally unique, but this is known only to a subcomponent of the central registry that is run by different govarnment entity than rest of the system. At same time the design of that subcomponent contains provisions for allocating new ID, mainly for handling the cases when that ID was allocated wrong (both multiple IDs for one person and multiple persons sharing same ID), so even that is not necessarily stable ID.
Users of that data refer to persons using AIFO, which is specific and meaningful only for particular database (called AIS) and if different databases need to identify particular person as having the same identity they have to call the central translation subcomponent (the API surfaces are designed such that the translation the calling system will not get the result of the translation, which is only sent to the destination system). Even that the AIFOs are meaningless, they are required to be not disclosed to anybody. Alternative IDs that can be used are broadly serial numbers of government issued identitty/travel documents, but these are necessarily both revocable and have limited time validity (the aforementioned technically deprecated RČ is essentially a special case of this).
I believe that this design comes from some pan-EU initiative related to GDPR. For example according to Wikipedia Austria uses broadly similar, but less fine-grained system.
This has interesting issue with regard to things like eIDAS as there is no sane ID that could be included in the qualified personal certificate. One Czech QCA (PostSignum) does not include any kind of personal ID in its personal certificates, second one (I.CA) can optionally include the serial number of identity document that was used for identification. Apparently you can get Swedish qualified certificate that includes Czech RČ in its CN form Zealid. You are supposed to register your certificate into the resident registry yourself, which creates the link between the certificate and your identity. The slight issue with that is that there is no sane way how a third party outside the architecture of these registers can validate that link (you can send them a signed PDF with your data from the resident register, which is apparently what you are supposed to do, but "sane" would look different).
If my country did not like your country I will not be able to connect to your stuff?
A never ending must of problems ahead.
There's also a large number of stateless people who don't have citizenship at all.
There's also people who are not technically stateless, but cannot return to their country or obtain any identity documents from it.
Exactly the analogy I had in mind. email primary keys are "serial monogamy". Or if you want a mathematical analogy, piecewise constant :)
Disagreed. I'm 39. I've known hundreds of people (HS, college, etc) and many close friends who willingly made email accounts like "brijacks85" (their birth year) or "sammichelson212" even when their actual names were still fully available on yahoo/gmail/hotmail, etc. I used to regularly create email accounts for these people using just their names and then ask "why didn't you just check your own name first?" and they'd usually just shrug with total indifference and never use the account I made for them.
But some also large number of people are not.
Similarly, I get a small fraction of the mail of a texas lawyer, because her email address string is a super set of mine, and some percentage of her clients don’t bother or notice the need to add the extra suffix.
Can you explain why it shouldn't be?
To answer the question more directly, it’s treating the identifier like a password that is problematic.
There are also some ugly edge cases - what happens if somebody is too young to get a SSN equivalent (e.g NI numbers in the UK), or somebody expatriates, or if some government allows people to request a change to their SSN-equivalent, or if a customer is a refugee without an SSN equivalent?
I do think SSN-equivalent identifiers may be useful for services which are inherently for tax paying adults like some accounting/banking services or marketplaces.
See for example UK id cards scrapped in 1952 and again in 2010
>...very unpopular with the public, and was regarded as an alien imposition on the British way of life. https://www.politics.co.uk/reference/identity-cards/
Gmail? You might randomly get locked by some AI algorithm (or you might get banned!), or something else goes wrong, and there's no recourse.
Yahoo? I recently lost access to mine because they decided to start demanding verification with a deactivated email I haven't had access to for 15 years in order to login. Luckily, I had access in an email client, so I was able to migrate all the important accounts off of it.
Yahoo/AOL/Tutanota/Protonmail/Many others? These ones will auto-delete your account if you don't login frequently enough (not protonmail yet, but they allow it in their TOS)
Self-host? All self-hosting infrastructure requires an email in the first place. Lose access to that email, lose access to payment reminders, potentially your hosting account. I nearly lost my domain since the payment reminders went to an email that I rarely check because it doesn't support IMAP. And there is a greater increase of hacking unless you're a professional sysadmin and have plenty of time for maintenance.
Duo push? Your phone breaks.
SMS verification? Phone breaks, lose access to your plan, compromised employee gives your codes away, etc.
I've settled on using my university gmail address since (1) they promise alumni can keep it and (2) if something goes wrong with it (likely losing 2-factor by losing my phone), there is a good alumni support center. There really needs to be a human I can talk to somewhere. Still not sure if this is the best approach; am I still at risk from Google here?
I agree that there should be some non-forfeitable right to a permanent personal domain though.
There's tons of exceptional circumstances where people can lose access to their domain. Some TLDs have no grace period at all and it can be fairly easy to lose access. For others it's larger, but even there, it's not that hard to see how people can lose access for one reason or the other.
Or in the spaghetti parsing, obviously nobody is going to have swear words in their email. Go ahead and blanket ban all of that. And then @JohnsonAssociates.com gets banned.
I’ve also seen email parsing rules get applied to login screens too. So the valid email rules get updated and suddenly you fail validation trying to log into your already existing account. Ran into this today actually.
So having your own domain might solve some problems but you may still end up needing multiple accounts with devs refusing to use correct parsing rules.
And by untrusted you mean everyone's work email that uses a bespoke domain?
Source? In my experience as long as you follow basic email authentication protocols (DMARC...) you'll get through anything just fine.
1. Apple’s spam filtering can be very proactive, and the only way to (allegedly) influence it is to move false positives back to the inbox. There are no settings to whitelist addresses (having them in Contacts doesn’t work reliably) or to turn off spam filtering altogether. As often with Apple, you have to accept their design choices of how they think stuff should work, and can’t do much about it.
2. If you’re transferring or forwarding emails from another account, Apple has a 20 MB email size limit while it’s 25 MB for GMail, which means there may be emails that can’t be transferred.
In any case, I would recommend having your own domain and choosing email providers that support custom domains. That way, you can switch email providers at will while retaining your existing email address(es).
Apple is a long-time, reliable email provider, and the transition from Google Workspace to iCloud+ custom domains was straightforward with `imapsync`: https://blah.cloud/miscellaneous/migrating-google-workspaces...
I am currently paying a ~$150 per month "tax" to AT&T to keep my US number while living abroad just so I can get login codes for websites that still have that number, and out of fear that if I dump it I'll lose access to some occasionally vital service that I've forgotten to update, or I can't because you need to have a US number.
Port it to a VoIP company like DIDww, spend $2.50/month, and received SMS can end up in your inbox if you wish.
If you ever want the number on a mobile account again, port it back out to your choice of carrier.
I don't know why you're paying so much - you can just port the number to a VIOP provider and pay a few bucks a month.
Even for a normal phone service that's exorbitant - I pay less than $100/month for two lines.
Like it sucks that getting a permanent identifier is an annoying technical process but DNS is the closest thing to a universal global identifier you can own in a meaningful sense.
Switch to a FLOSS OTP solution and/or Fido2 key. If you’re service providers don’t accept them, replace them with one who does.
Not even then (at least not great). Companies change domains, primaries become aliases etc..
Most natural keys that identify dimensions of your data are slowly changing anyway - an address isn't a permanent fixture of a building, an area code splits, nations go to war, daylight savings changes on a whim, laws change, rules change, our understanding of the universe changes.
1. Built-in Deduplication. If your ID describes the "thing that it is" handling deduplication is much easier. Of course you can try to enforce it by enforcing uniqueness on other columns (but that's not always possible / can get tricky).
2. Save a DB trip on updates/some creations / make indexing more explicit. E.g. say you are user with email address and you want to update some info. Either you run an update using the email directly (in which case you are treating it as a PK essentially even if you don't call it that) or you first retrieve the relevant PK by whatever logic (say indexing by email and name or whatever) at which point you do have an implicit natural key.
In my experience every time I have seen a "corporate" DB with non natural key you get a LOT of duplication and all sorts of services to try to resolve entities running in a batch way (the horror..).
And 2 leads to a lot of bugs because of the implicit nature where you accidentally update the wrong or multiple rows because you didn't know what the implicit uniqueness "key" entailed.
2) Usually, the update does not happen in the blue. It's often done after a load operation, for optimistic locking. In that case, the PK is available for free.
Random strings fit the bill perfectly. Sequential integers also work fine, except they are easy to guess, so you might need additional security measures.
Obviously, we'd want some sort of aliasing process so we can have a convenient name, but we probably want mail clients to map those addresses or at least track them with their public key.
Could even end up being a shoehorn for E2E encrypted e-mail, which never really seems to have caught on in any big way.
This would require some big players to support it to get anywhere, but from a brief thinking about it, it seems solid. Other than that nobody has support for it yet...
There are efforts underway to create new ways of identifying and communicating via web where you own your identity, and are not depending on a provider or central authority.
When I moved and tried to “set up” my online account I kept getting HTTP 500s when trying to view details about my current address. On the phone they told me “sorry, you can’t use the same email address for multiple [postal] addresses”, even with closed energy accounts from previous addresses.
One of the main reasons for this is that we provide a student discount for people, and the easiest way to apply that to an account is by checking if their email is an educational one (.edu, .ac.uk, etc). However most people don't seem to want to actually signup with that email. So by allowing multiple emails we can have the best of both worlds! Wish we had done it this way in the beginning.
I give out my edu address to very few people in any case.
Currently we actually require manual verification (sending in a student ID to our Intercom) if you didn't sign up with a educational email, and I'm deliberately overlooking the proofs that are clearly invalid. I barely even glance at them. The other day day someone sent me a student ID that was 4 years expired and I just applied the discount and moved on with my day haha. If you send me a PDF called "student_id.pdf" I'll probably give you the student discount. That's part of the reason we're adding this system – we've gotten so lazy that requiring people to go the email verification route will probably be a stricter improvement on the status quo if most users go that route.
I'm paying a domain, this way i have 100% control of my e-mail alias, even if my current provider (google) goes south, i'm still able to host the mail on my own server to retrieve accounts, and maintain ownership or the alias
But mistakes can never be completely avoided.
What if you accidentally transfer this domain to someone instead of another domain you sold them? What if you accidentally lose access to the registrar's website? What if.....
It's a huge pain to deal with, since it's 100% unrecoverable since there's no one to really appeal to and you're just forced to update your e-mail everywhere.
What exactly do you think happens to anything of yours after you die if you don't prep for it? With many organizations or property your heirs can use a death certificate or court order to get stuff, in other cases they may just be out of luck. You may even wish it to be so, do you actually want them to have access to your old data? All of it or only some? If you actually care then like anything you need to prep for that while you're still alive in any one of the numerous ways available. If you don't then tough shit, that's why there is constant reminders about setting up wills/trusts and keeping relatives/friends/colleagues in the loop as needed and so on and so forth.
Is anyone still doing this? It’s like the most basic db design issue to not use things like email as the identifier and instead have a lookup table that maps things to a truly unique id (uuid or maybe auto increment from a sequence).
The article doesn’t really make this distinction so it almost reads like how users should be aware of this abstraction.
When I was in college, academics were just starting to grudgingly accept artificial primary keys (like UUID or auto-incrementing integers) as a concession to reality.
To a modern developer natural primary keys sound insane. Artificial keys are faster in almost every way due to index size. You’re storing compact, fixed-size binary data instead of strings.
Socials change. Emails change. Seemingly natural, unchanging things change and mess up all the foreign key relationships.
Email addresses are reliably unique (for a reasonably long time), which is why they are chosen for this purpose.
Phone numbers are now more "sticky" than they used to be and are now similar to email addresses at being useful identifiers.
Both emails and phone numbers are frequently lost, often at the same time.
Backup email addresses are the way to go.
Github does a good job at identity, I think, but they still use passwords (which are bad).
There is only social attestation.
Any identity system that fails to recognize this will fail to model societal constructs.
The problem of identification, which is assigning a unique identity to each human being, has pretty much been solved. You have names, emails, id cards, really any unique string or number that's tied to a human being. It's not flawless, but in theory it works.
The real issue is authenticating an identity, how do you know the person is actually who they claim to be? This is one of the biggest issues facing modern technology, and it has not been solved. We generally use a combination of passwords, geolocation, IP addresses, emails, phone numbers, security tokens and certificates to create systems that are "good enough". However, these systems are regularly breached, and tightening their security generally has a negative effect on legitimate users.
A private id is probably just the best, whether it is a UUID, or another type of sufficiently collision resistant id, kept away from the user for the most part.
Let said person have an email or username, and let other people tag or friend them, but only use said username/email when doing the initial connection. Base said connections off of, the private id
As far as I can tell, the only way to have an actually good identifier is for a user to generate a public/private keypair.
Yes, there are challenges with account recovery but we have tools for that like multisig and and n of m schemes and a bunch of other stuff I don't know about.
Email is digital post cards handed off between two dozen untrusted couriers. Why on earth are we overloading this tool for identity, notifications, conversations, subscriptions, etc?
Until this year, quite a few people would've also lost their AWS access that way.
I wish we would move to a Permissioned Messaging Provider model, where a standardized API allows a user to issue tokens to specific parties to send messages, which is revocable, and where the user can control the destination and medium of those messages. You want your airline to be able to send you status updates about your flight? Great -- you can choose whether those messages arrive as emails, text messages, whatsapp messages, etc, and you can remove those permissions later if you like. Permissioned Messaging Providers will also change sometimes. I think a keybase-like mechanism could be used for asserting that you're the same person across two services, but knowledge that @user1@providerA is the same as @user2@providerB wouldn't allow anyone to send messages to either, since you still need a token (unlike announcing publicly that you're moving from myname@emailprovider.com to myname2@email2.net).
* Person used their real name, got married, changed last name
* Person used their real name, transitioned, changed their first name
* Person used characters that you no longer want to accept in nicknames
* Person used a nickname that you now want to reserve (e.g. "admin", "contact", "help", ...)
* Person used a very silly name and grew up or started using your service at their job
Why would you refuse certain characters? My last name contains a dash and one letter with a diacritic. I am beyond tired of playing whack-a-mole trying to guess what rule I violated with my "invalid name."
And fuck companies who have the gall to call my name "invalid" to my face, too. Have some thought before you write an error message. "Contains an invalid character" wouldn't be insulting, for example.
If nicknames appear in URLs for example, or are a way to direct messages at someone (e.g. github.com/<nick>, @<nick>), using non-ASCII characters is a bad idea.
Left-wing nutsoes will be repelled by the blanket association of "free speech" with the right wing, and right-wing nutsoes will be repelled because they want to use their speech to be a dick.
Let's relax with the generalizations no one invited on the last day of the year.
At some point I was in contact with an admin who noticed that the original firstname.lastname@company wasn't working there anymore, so he thought he'd be nice and give me that email address now. That was a terrible idea.
Apparently, the original firstname.lastname was watching a couple of Confluence pages so he'd be notified when they changed. Those emails went nowhere because the address didn't exist anymore. But now it suddenly did again, so I started to receive all those notifications. I visited those pages to see if I could turn the notifications off, but they were controlled by the original guy's Confluence account, which I had no access to of course.
Ideally, it would be something like a guid.
True for some cases, surely, but I will be surprised if I don't go to the grave in ~40 years with my current gmail account still intact (assuming email is still a thing).
I assume this is true for some appreciable fraction of email users, although I couldn't hazard a guess of what fraction.
Just having a random ID isn't good enough, unless you want the user to remember this ID.
Google accounts include purchase ownerships and the like. Dropping an old one and starting a new one is non-trivial. And most reasonable people make their email accounts their names, and names do change. Marriages, transfolk, etc.
When moving countries it can be difficult if not impossible to retain your existing phone number. In some parts of the world moving states means changing your mobile number.
Most telcos “recycle” deactivated numbers after a period of time. This often as short as 6 to 12 months after the owner’s credit expires. I’ve found it increasingly common for a prepaid local SIM number to be tied to a previous owner’s accounts on popular services.
I cannot imagine how it cos be possible in the first place.
I have a French number: +33 and 9 digits. In Germany it is +49 and 10 digits. In Poland +48 and again 9 digits.
How do you imagine porting a national phone number abroad?
The specter of having a "permanent ID" (contextless), is something which has never really existed nor ever will. Identity only exists in context to some environment, even in blockchain.
It's quite odd to see a dead link from a post made literally today.
Edit: Oh right, you asked what the famous saying actually says. Since you're apparently not familiar with it, it's a joke of the following form:
> Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.
Here, obviously, it's being applied to something other than regular expressions, but this sort of thing is what "now you have two problems" refers to.
The actual linked article is looking into the origins of this joke.
> Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.
Ah! I remember this saying. Now I get it.
Thank you!
The reason is that we want to keep as little PID as possible, and that should be as innocuous as possible.
So we use emails, including obfuscated Sign In with Apple proxies, or even temporary DEAs. The only requirement is that the email be one that will receive emails.
So, either have an identity in your community that is specifically not linked to definitive people, or realize you ultimately need a way to link to whatever the local government uses, at some level.
Right?
Yes, there might be collisions in a DNA hash-code (such as identical twins), but there can be protocols for that.
> DIDs can replace ORCIDs - which you can also just generate a new one of - for academics seeking to group their ScholarlyArticles by a better identifier than a transient university email address.
DIDs are typically (or always) the public key part of a public/private (asymmetric) keypair.
> When would a DID be a better choice than a UUID? [or an email address]
This is the solution.
The rest is an implementation detail ;)
Emails would change. Same with phone numbers.
I've never seen it, it is usually lives in a column in the table and is used to login. But internal ids are UUIDs or integers in the relational DB.
I've seen people use phone number as an ID, but it is bad for GDPR and privacy reasons... I've seen people use incrementing ID and expose it to the user inside URLs (leaking the account registration time and the total number of users).
No s~~H Sherlock!