Addresses are Broken
How, in this century, do I still need to manually update my address in all my accounts?
Today my friends, I wish to engage in a productive rant. To call out something as the clear nonsense that it is, but to finish up with a concrete suggestion on how to address it.
Moving Sucks
Moving is miserable. You have so many things to balance. You have to ensure that your housing overlaps, but not too much. You have to pare down possession, pack, move, organize the move or rentals, disconnect old utilities and set up new ones, and set up mail forwarding. There’s more, but the point is there is a minimum amount of work that must always be done.
Eventually, when you’re more settled you’ll begin to tackle straggler tasks. The canonical example of this is updating your address everywhere. It’s not actually that time bound because mail forwarding lasts for a long time. Some people will update in bulk, others as they use the account, others such as myself update critical items in bulk and noncritical as they go.
This is such an unforced error. Once I’ve entered my address information once, I should never need to enter it into the computer again.
How to Fix it
What we need is an open protocol for communicating a digital identification card that defines the shape of the data (such that it can be shared one-off) and a protocol for requesting the data / updates from an online originator.
By protocol, I mean in the sense of IMAP and similar for email. These are open standards which means, barring mistakes, any implementation of the protocol will work. I don’t have to use Google’s web browser app for gmail, I can use Outlook or Thunderbird. This is what truly makes email decentralized. The server is what decides what emails are sent and received. If I’m unhappy with that server, say they aren’t filtering spam well enough, I can migrate all of my data to a new server and go from there. I don’t need to change my client, it just starts connecting to a different service provider.
As an aside, being unable to “transfer” your email address is a disappointing limitation of the system that harms competition. Fun fact, did you know that used to be the same with phone numbers? If you wanted to change your service provider, you had to change your phone number. This seriously limited the ability to switch, as it was now a major disruptive event to do so. Email is unfortunately the same, but worse because it’s tied into so many accounts not just one use case (voice calls / SMS in the case of a phone number). This is a historical failing, though interestingly the opposite (anonymous alias relays) is taking off now to increase privacy. There is still a question of transferring them as an atomic group though.
Federated Contact Information
At a high level, a protocol would look like:
flowchart TD
A[App Requests Address]
A --> C{Client indicates source}
C -->|Offline| D[Data provided inline to app]
C -->|Online| E[Client designates a delegate for app to use]
Offline Activity Diagram
sequenceDiagram
App->>Client: Request Address (with version number if prior exists)
Client-->>App: Not modified || Address, tagged as offline || switch to federated
Online (Federated) Activity Diagram
sequenceDiagram
App->>Client: Request Address (first time only)
Client->>F: Request signing token
F-->>Client: Token for signing (cacheable)
Client-->>App: Federated source + token || switch to offline
participant F as Federated Provider
App->>F: Request address (with current version, signed with token)
F-->>App: Address
App->>F: Request address (with current version, signed with token)
F->>Client: Ask to approve
Client-->>F: Approve or Deny
F-->>App: Address if approved JiT || for all updates
Why it’s Better than “Sign in with”
Multiple big tech companies offer the ability to sign in using your existing account in a federated manner. The account will optionally offer access to basic information and/or APIs for deeper integrations with existing services you’re using.
This has issues:
- It’s centralized. You don’t own your data. They can delete your account for any reason, and since the service is free good luck contacting support for a resolution. Additionally, these companies aren’t implementing standard authentication protocols or formats or offering analogous features. This ties into:
- Not interoperable. If I implement sign in with Google into my website, I’ve accomplished nothing towards sign in with Apple or Meta.
No JiT (Just in Time) access. OAuth-esque models grant continuous access to information until the integration level connection is revoked by the user, effectively an uninstall operation.
This isn’t good for personal information. Does Amazon need to check if your address is up to date at 2am on a Tuesday while you sleep? Of course not, but in these models they can. In the hypothetical model proposed here, this is solved. Every version or portion of your data is marked with a version. When you go from version N to N+1, approval from the user is required. This means I get the convenience of a one time, centralized update of my information with the control of manually providing it to each application.
OpenID
In principle at least, OpenID aims to address these issues. From what I’ve seen at a cursory though, it’s usage is primarily targeting the sign in with case but in an interoperable, decentralized manner.
That said, there is a claim for a user’s physical address which gets the point across.
Hopefully then this is already in progress. You’ll notice this post is a little unusual in that I’ve done little to validate and prescribe an explicit action to take. The issue is fresh on my mind, so I wanted to write it down. My hope here is to get people thinking about the issue in their own design, and considering what solutions exist to make software easier and more secure.
It might be OpenID as is, it might be run an experiment then try to get the results included. But either way, there isn’t a clear or consistent industry solution to this problem so it’s something we all need to consider and iterate on.