Shared publicly  - 
Rethinking Account Creation

The potential growth rate of an online service is highly determined by how easy it is for new users to create an account, especially if you need an account before you can experience what is compelling about the service.

I want our account creation to be at most clicking "Yes" for something opt-in like cloud services for the Novacut editor. And for the player (content distribution side), I want the account to be automatically created the first time the user opens the app.

We can make it this easy because the account creation will be done automatically by our apps. We initially don't care if the user can access their account through a browser, so we aren't held back by the limitations most account creation must work within. In particular, we don't need to put our users through the standard email address, password, captcha, confirmation email routine.

There is another important idea here: we initially treat the account as completely throw-away.

Account Zen

The value of having an account grows over time (for both the user and the service provider). When an account is first created, it essentially has zero value, so we want to treat it as throw-away. Like a test drive... maybe they'll buy the car, maybe they wont.

I look at an account as having two functions:

1) Authentication - a way to prove to the service that "you" are the same "you" when next you return, or when you use the account from a different device. A username+password is the standard way to do this.

2) Association - a way to associate the account "you" with the "you" in the real world, and the "you" on other online services. So things like  email address, name, mailing address, credit card number, etc.

To stick with the car metaphor, the 2nd part, association, is only needed if the user decides to buy the car. So for our automatic account creation, we completely skip (2) so there is a higher chance of them taking the test drive. The association can be done in small steps over time, as needed, and only if needed.

I think the first part, authentication, is a place where most account creation processes face their biggest usability friction. If you must choose a username (say on Twitter), there is a certain stress and commitment there. What if you choose a username you don't like? And passwords can only provide so-so security or so-so usability, and you must trade one for the other.

Fortunately, (1) happens to be the part that is exceedingly easy for an app to do automatically. It's easy to provide both excellent security (no shared secrets), and excellent usability (require no user interaction at all).

I am me

Novacut will create an account using what I like to call the "I am me" protocol. In a nutshell, the app creates an RSA key-pair and then uploads the public key (as a self-signed SSL cert) to the Novacut account server as a way of saying, "I have private key, therefor I am" :P

Our servers can then easily verify that this "me" is the same "me" when it returns. For all sorts of reasons this is far more secure than having the user chose, remember, and frequently type a password. But most importantly, it's not a chore that must be completed before you can take that test drive.

I am human

After a lot of thought, I decided not to subject our users to a captcha or similar means of attempting to prevent bots from registering accounts. These days a captcha is only moderately effective at preventing bots from registering accounts. And worse, a captcha is quite good at discouraging humans from creating accounts.

So the account is treated as potentially throw-away by the service also, partly because it very well could have been created by a bot. A better way to decided this is by looking at the usage pattern over a longer window of time after the account is created.

Also, Novacut isn't a social network or an email account. There is probably little advantage to a bot creating an account, because it can't really be used for spam. And we don't need to let an account do everything out of the gate. For certain features, we can require the user to complete some of those association steps first (email, SMS to a mobile, etc).

If you have a great car...

Make sure it's easy for potential user to test drive it :)
Chad MILLER's profile photoJason DeRose's profile photoMatteo Ronchetti's profile photoJon Åslund's profile photo
What about a second machine?

Also suppose the credentials from the first machine are lost.
+Chad MILLER so the self-signed cert sent to the novacut account server is what I call the "user CA". To add a new machine, that machine generates a CSR and then the user CA issues the machine a cert. The novacut service will allow any machine with at cert signed by the user CA to authenticate as that user. We probably want a whitelist also to make it sane to un-authorize a machine. Still thinking on that.

As far as credentials getting lost, on a short timescale my thought is "so what" :P That's the initially throw-away part: at first you embrace the idea that they might get lost for the sake wowing them with the test drive ASAP. And then you can walk the user through a more conventional account creation process, which would give them some out-of-band account recovery options (like their email address, etc).

This is something that the client end probably needs smarts about. For example, we don't trust the service for data backup till there is some recovery option (added a 2nd machine, or email and password, something like that).
So from a user point of view I create an account just with a button and then if I want to add another machine to my account I have to copy the certificate right?
+Matteo Ronchetti - I'm working on a peering protocol... you have both device side by side, one displays a short random code which you type into the other, and it securely peers them without manually copying anything.

but manual copying would work too, it's just sucky UX wise.
I like this way of thinking a lot. In the beginning, the account creation and authentication could be completely invisible, then after attaching more things to the account and getting a larger important history, you could give more and more hints in forms of different UI elements to the user of the advantages of creating more association and different authentication methods, without being in-your-face until they decide to do something that really requires it.
Add a comment...