In this topic I want to start the conversation and I’ll update the requirements here if I get any feedback.
Last week at the NFCB conference in Denver Mike Lupica of WPRB reported that the current login options are insufficient, especially for younger users. The problem was discussed also in one of the sessions. I agree. The question is therefore: What auth methods to add and how exactly should they work?
We could add more apps like maybe TikTok or whatever and that might help but it isn’t really satisfying for a number of reasons I can’t be bothered to elaborate here. What else might we do? Trick question! Serious engineers prefer to elaborate requirements before suggesting solutions.
Requirements
-
Sock puppet mitigation
We want a solid connection between a chat user’s display name and a real-life person. We don’t want to encourage chatters to play the identity games that are typical with anonymous chat apps.
Facebook is strict at this. They are so diligent at verifying a person’s identity they demand a real name, home address and head shot to create an account. (That’s why I’m not on FB!)
Google is less strict (I use four Google logins for different things) but connecting chat to your Gmail login and public profile is still a good “skin in the game” precondition to participating in chat.
Both present some resistance to setting up sock puppets
-
Low friction. It must be easy to chat for the first time and to resume chatting.
Google and FB logins are persistent and regular users of those services are already logged in so joining chat for the first time and resuming are very low friction … so long as you don’t mind using those logins for chat.
-
Chat with one display name over multiple devices and browsers
Resuming chat as you move from one device to another must also present low friction.
-
Phishing mitigation
I’m not sure what this means for login but Bitwarden brags about it.
-
Spam mitigation
I don’t see what login systems can do about spam. If you can log in to chat then you can push your influencer channels and meditation retreats. We’ll have to continue to rely on DJs to delete spam and ban repeat spammers.
-
No passwords
Too much trouble for us to implement and too much friction. Passwords suck. If WhatsApp can manage without them so can we, right?
Phones for ID and auth
That last point about WhatsApp made me think. Let’s require phones for auth and use the phone number for ID.
Since we rolled out chat it’s become normal to require mobile phones for participating in much of real life, or at least for convenient participation. Flying without a phone these days is way harder than submitting to the tyranny of the app.
We’re not proposing to get rid of FB/Google auth so if you want not to use a phone directly with Spinitron, you can.
Phone number → pass code → cookie functional spec
We’re mostly quite familiar with getting a 6-digit code via a text/SMS message and entering it into a web app. Can we apply this to chat and meet our requirements? A possible app flow:
- In Spinitron chat, choose Log in with text message (or something)
- Spinitron prompts for a phone number, which user enters
- Spinitron sends a pass code in a text message and prompts for it
- User enters the pass code
- Spinitron validates the pass code
- If Spinitron has no display name saved for that phone number, prompts for a chat display name, otherwise skip this prompt and use the saved name
- Set a cookie for, say, 1 month
- You’re in!
On another device or browser or in a new private browser window you’ll need to log in again with text message and pass code and then you’ll be in for a month with that cookie in that browsing context.
As with existing chat login, the display name will be reserved to your ID (phone number in this case) for a few more months after your last login.
-
Pros
- Easy enough to implement 100% in Spinitron except we need a text/SMS service provider, of which there are many.
-
Cons
- Users have to enter 10 digits and then transfer 6 digits from text to web form and enter those. (I find using phone “keyboards” ridiculously hard but maybe that’s just me.)
- Users might not want to give their phone number to Spinitron.
- We need an admin channel to delete phone numbers on demand.
- We have to save phone numbers on Spinitron, which I don’t like. Perhaps a one-way hash of phone number would suffice, idk.
Bitwarden passwordless.dev
Bitwarden sells a password manager app/service (like Lastpass, Dashlane, KeePass etc.). They are relatively new and open source. They also offer a login service called Bitwarden passwordless.dev which is their commercial implementation of FIDO2 Web Authentication.
Their service comprises auth servers “in the cloud” and a client library that we could incorporate into Spinitron. I haven’t read much about it yet but it seems to provide the kind of ID and auth that meets our requirements set out above.
Afaict, relative to phone number → pass code → cookie described above we have…
-
Pros
- You don’t have to tell Spinitron your phone number and Spinitron doesn’t have to store it
- Less typing, avoiding the 10-digit phone number and 6-digit passcode entry
- Less friction resuming your chat on another device using QR code to authorize the new device
-
Cons
- Depends on Bitwarden’s backend in the cloud. (As Yves Smith is wont to say, if your business depends on a platform, you don’t own a business.)
- Costs Spinitron 5¢ per chat user per month
I suppose we could develop our own FIDO2 WebAuthn based on published specs and reference code if we wanted to avoid these two cons.