Magic Links & Privacy

There were a few reasons we decided to start AnuChat with a magic-link system of login rather than the old username & password pair, but we didn’t anticipate some of the user experience patterns we would be facing with that choice. This is a story of people, engineers, and why it’s not enough to have a UX expert or a good product writeup – the people actually building the product need to see how it’s used in the wild. It’s also a tale of the absurd.

We found out there’s a problem with our third or fourth Alpha participants. They were personal friends of mine which I invited onto AnuChat, fully embarrassed about the state of the product, but real registrations have to start somewhere and good feedback-givers are hard to come by. The first one texted me that they signed up but didn’t get a verification email. The second said they’ve been waiting for it for an hour, and it’s not in spam. “Is there a problem with our email service?” I clicked the link, followed the instructions on screen, and wham! Got an email, no problem.

Huh. It was staring me right in the face. People don’t follow instructions. Neither my friends who clicked the link, nor the engineers who implemented the signup logic. I called them up to ask about it.

“You said you sent the link to a few people to verify platform-invites work, right?” I asked the team-lead.
“Yeah, it works like a charm. Here, I can show you we’re friends on AnuChat.”
I paused. “Ok. And when you sent them the link, they had no problems, everyone got onboarded?”
“Yes. Of course.” She looked back at one of her teammates. “Well, eventually. We had an issue with the first person, but they solved it.”
I looked at her and said “Let me guess, they didn’t choose ‘create account’?”
“Exactly!” She replied, “It was so silly.”
I was curious, “So that didn’t happen to anyone else?”
“Of course not. We just told them to press it when they used the link. Duh.”
I started laughing. “And you didn’t think it might be a problem?”
She stared at me and started laughing too. “It crossed my mind, but you know, that’s how it works everywhere. When you go to the login page, you’re asked to log-in. You can create an account if you want…”
I was wiping the tears from my eyes. “You’re right, you’re right. We benchmark with other apps, but they have a username and password login, not ones that use magic-links. It’s easy to miss. But…”
She was serious again, “But?”
“Why do we tell people to check their emails if we’re not sending an email?”
For this she conceded the stage to the engineer that made that specific implementation. “Well, we’re not sending an email because they don’t have an account, right?” He started. “And we’re not telling them that they don’t have an account because we care about privacy. No Account Enumeration. You don’t want malicious actors phishing for emails, it was in the spec!”
I looked at them and said, “I know I said privacy through obscurity is good, but I didn’t mean the obscure part to be our product.”
This time the laughter was contagious.

The workarounds were pretty simple. However, we still had the deeper issue on the culture side, since tribal knowledge was pushing aside written acceptance criteria. I let the team-lead take the conversation and she got her team to agree that before they start a project they will first write tests based on our product ACs (and thank LLMs for making engineers suddenly amendable to the idea of TDD). It was quite smooth to get buy-in from everyone, since no one wanted to repeat the blunder.
Especially me. I had to ask my friends to sign up again. But trust me, everything worked afterwards. Until you read our next post, anyway.