2018-03-08 Mobile Blockstack ID creation / onboarding update

[jeffd]

Meeting with: Ken, Chase, Larry, Jude

Previous discussion:

Blockstack Mobile Plans

Below is a brief overview of our plan for Blockstack on mobile devices: Phase 1: Software Developer Kit (SDK) Estimated ship date: Late Q2 2018 We plan to build software developer kits for both Android and iOS that provide the functionality currently available in blockstack.js and easy-to-use, in-app sign with Blockstack integration tools. The SDK will make it easy for app developers to on-board users to Blockstack in a low friction manner without leaving their own app. In-app authentication A…

2018-02-16 Product Meeting

Attendees Jeff Ryan Larry Chase Ken Website Background: Blockstack.org Roadmap Larry: concern that we don’t yet have a large number of high quality apps Jeff: if there are apps people will want to use, they’ll find them Decision: Chase is building a scaled down version of this for before Berlin that will be integrated into the current website. Scaled down scope: Using the mockup shown in Blockstack.org Roadmap, create a simplified coded version. This version will not use the sitenav sho…

Progress

• Full prototype of user onboarding on mobile
• Evaluated 3 approaches outlined by Larry (killed two because they contain a failure state where user is easily locked out)
• Met with engineering team to validate the approach is possible and avoids any big security pitfalls.

Open questions / ideas

• Can/should we require all new IDs to have a subdomain ID?
• Can/should we allow users to store recovery phrase someplace else (iOS keychain, save to files, dropbox, etc)?

Key next steps

• User test prototype with 5 users who have never created a blockstack ID

Overall goal and approach

• Allow new users to create a complete ID on mobile.
• Minimize the time/friction/complexity.
• Allow users to defer the password and seed record steps (get into app faster, realize value faster)

Step by step UX

• User clicks on app
• User clicks “Login or signup with Blockstack”
• User creates unique ID
• User enters email/phone
• User sees confirmation message, for specific app asking for access to ID.
• User sees/starts using app
• User gets email stating “your identity isn’t backed up"
• User opens email client and clicks on link (can be days/weeks later)
• Browser/app opens, user is prompted to backup their account.
• User is prompted to create/enter password. User types in password. Clicks done. Confirms. Clicks done.
• User sees seed in plaintext and is prompted to write down seed. User records seed.
• User is prompted to type in the seed to confirm they recorded it. User enters seed.
• User sees a message: “You’re all secure”
• User gets email with two URLs
  • Restore via seed
  • Restore via link + password

Prototype screens

• https://xd.adobe.com/view/073c711f-2457-4758-8f84-be91f9cecbb8
• WIP. Will share revised screens soon.

[adam]

Hey Guys,

Really digging this flow, only part i would change is ‘Login or signup w Blockstack’ is a bit awkward, what about ‘Continue with Blockstack’ ?

Also, will this flow work on mobile web as well?

Adam

[jeffd]

Thanks Adam. Yeah, mobile web + native is the intention. @larry @yukan feel free to chime in.

[hologram]

@jeffd loving this!

Just thinking,… can we make this a mobile responsive application so that we can share the code with our web onboarding flow?

[aaron]

@ryan raised a couple of “failure” conditions we may want to think about when it comes to losing the private key:

1. Private-browsing mode (I think when you use a webkit widget from an application, this isn’t an issue, but we should look into it)
2. Cookie resets – users may not actually be aware that a cookie wipe on their device will discard that private key
3. Loss of device – not sure that’s solvable.

I think (2) is kind of important to think about, and (1) is also important for users who hit this via their web browser rather than mobile native.

[ryan]

Overall goal and approach

Allow new users to create a complete ID on mobile.
Minimize the time/friction/complexity.
Allow users to defer the password and seed record steps (get into app faster, realize value faster)

Oh hell yeah, very well done. Loving this flow. See my comments below.

Can/should we require all new IDs to have a subdomain ID?

This is an interesting question and I believe the answer is yes and yes.

Can/should we allow users to store recovery phrase someplace else (iOS keychain, save to files, dropbox, etc)?

There are a few questions here so I’ll answer them separately:

Q: Can we have the user download a file or save a file to Dropbox?

A: On iOS the file could be saved to a note in the Notes app. I think the file needs to be encrypted, but I’m not sure, we’ll have to investigate this. I do know that the Notes app can password protect note files. On desktop, the file can be downloaded as long as it is encrypted with a strength-tested password. This same encrypted file could also be emailed to the user.

Q: Can the phrase be saved to the iOS keychain?

A: Yes I believe this can be done on iOS and locked with Face ID or a fingerprint or your pin. This could also be done on your Mac.

Both of these should be very promising.

User clicks “Login or signup with Blockstack”

We had earlier discussions where we favored “sign in” and “register/join” as a pair vs. “log in” and “sign up”, inspired by the following UX posting: https://ux.stackexchange.com/questions/1080/using-sign-in-vs-using-log-in. Also you’re literally signing a message to enter the app so there’s some interesting meaning behind it. That said you may have a good reason for going with this pair so curious what you think.

Really digging this flow, only part i would change is ‘Login or signup w Blockstack’ is a bit awkward, what about ‘Continue with Blockstack’ ?

Interesting. Maybe a single verb like “continue” or “enter” could work. Found this one for Facebook that one website used:

Prototype screens

https://xd.adobe.com/view/073c711f-2457-4758-8f84-be91f9cecbb8

Main questions I have are the following:

#1 Should we also have users enter a password on the initial sign up so that we can send them an encrypted copy of their passphrase? Or is it acceptable for us to only have the key stored in local storage initially and then do the backup process later? This ties into the concerns that @aaron just posted.

#2 For the backup process, can we include something other than writing down the 12-word phrase and storing a file in the keychain?

One option is to use a social recovery option where you enter the email addresses of 2-3 of your friends and we send them a piece of your key that can be recombined with a piece we send to your email.

#3 How do we communicate to the user that the phrase needs to be written down on paper and cannot be screenshotted or included in a file on the device?

Here’s some interesting copy inspiration from login.gov:

#4 How do we internationalize the 12-word phrase process?

Can we use different languages for the word sets like some apps do? Or should we have people write down a numeric or alphanumeric phrase if their language isn’t english?

Here’s a list of word lists in different languages:

bitcoinjs/bip39

Also here’s some inspiration from 1password and how they do secret keys and emergency kits:

[jeffd]

Thx @aaron these came up in earlier discussions and seem kind of endemic to the process itself, if there are true solutions to those would love to hear more:

1. There are ways to detect when someone is private-browsing/incognito correct? I’m guessing we should not allow or maybe discourage this since it’s likely to lead to a account the user can’t recover.

2. There’s nothing we can do to stop this, so all we can do is encourage them to have their seed recorded or send it to them in a variety of ways. Anything else to consider here?

3. Kind of the same as #2.

[jeffd]

#1 Should we also have users enter a password on the initial sign up so that we can send them an encrypted copy of their passphrase? Or is it acceptable for us to only have the key stored in local storage initially and then do the backup process later? This ties into the concerns that @aaron just posted.

That approach seems safer, but might be worse actually, since forgetting ones password means you’re completely locked out. We know that happens millions of times every day. My first reaction is to say lets user test, but doubt we can get a realistic read on that scenario. Best might be to present a couple scenarios to users and see what reactions come up.

[aaron]

There’s nothing we can do to stop this, so all we can do is encourage them to have their seed recorded or send it to them in a variety of ways. Anything else to consider here?

My point in #2 is that a user won’t necessarily be aware that resetting their browser history will have this result— this isn’t how most user account sign up processes work, so the user wouldn’t have a reasonable expectation that they could lose their account this way. I agree that there isn’t necessarily anything we can do to stop this, but I think we should try to make users aware of the potential problem.

[hologram]

@jeffd

1. Can we start thinking about this as the onboarding flow for browser.blockstack.org for both web and mobile? Am I missing anything here that would prevent this @larry or @yukan?
2. Based on the current flow, it’s not clear to me why the app needs Blockstack to work and why I should create a Blockstack account. There are some good suggestions in @digitalwaveride’s wireframes
3. Maybe capturing the user email address + password would be a better first step since its more familiar. We could then also leverage the user’s email handle to prepopulate the identity field. For instance, if my email is [email protected], my identity autofills to cwackerfuss

[jeffd]

Allowing users to start using, or test out, an app before an ID is created has some obvious advantages. But I also assume that for many apps that will be a non-starter. No ID also means no storage and so apps like Stealthy are not usable (you can only chat with yourself) in a non-ID state. Do I have that correct?

[hologram]

I also assume that for many apps that will be a non-starter

100% agree – we need to capture the ID, I was suggesting we move ID creation to the step after email and password. I think the flow might be a bit better since A) users already feel comfortable with email/password registration, and B) we could then also leverage the user’s email handle to prepopulate the identity field and check if its available.

[digitalwaveride]

Technically there would be an ID, with a default storage … it’s just that it is “sold” as temporary thing with a weird hash as username, and it is not perfectly secure yet, cause the user has not verified the keychain etc.

You raised a good point for direct communication apps like Stealthy, which are a special case for sure.
They have to define their explore and growth loops in a different way then probably most of the apps . Meaning they very likely have to grow via direct invitation from one user to friends and snowballing from there.
Though they have the huge advantage that if a friend sends me a direct invitation and sells me on the advantages of a secure and decentralized communication channel, then I have a huge incentive and maybe even group pressure to sign up. Apps like these might convert fine, even with a personal ID creation process in the beginning.

One spontaneous thought for a case like Stealthy … not sure if it might work…
If I get invited by you to Stealthy, then I can finish a temporary signup process in 4 steps, and afterwards can chat immediately with you… all works fine… but the moment I want to contact others, invite other friends, import my contact book whatever, then I have to complete the personal ID.
Just a thought…

[yukan]

@jeffd @larry @ryan What do you guys think about skipping the email confirmation step in the onboarding flow for now. On mobile, it’s going to be complicated to redirect back to the app from the email link. Especially in iOS, as there’s no way I’m aware of to push data into an already open Safari authentication session view. If the only thing we’re doing here is making sure they’ve entered the correct email, then I think there are better ways of doing that without adding an extra onboarding step. Taking the user out of the app adds quite a bit of friction to the onboarding process. It’s also not the UX we agreed on with some of our developers.

A few alternate options I’m proposing:

1. Remind users after onboarding that they haven’t clicked on the email, and maybe give the option to resend the email to a different address if they haven’t received it.

2. Have the mandatory email confirmation step for desktop only.

3. Ask for email as the last step in the onboarding. Once they’ve entered the email, we can show a message asking if they’ve received it and remind them of its importance. Provide 2 buttons, one for resend, and another to continue to the authenticate the app. For mobile, if the user has push notifications set up for their email, they should be able to see the notification banner and can confirm without having to leave the app.

Currently the first step in onboarding:

[larry]

What do you guys think about skipping the email confirmation step in the onboarding flow for now. On mobile, it’s going to be complicated to redirect back to the app from the email link.

I also think we should skip email confirmation - it’s a huge point of friction and complexity. We promised developers that they would be able to on-board users without leaving their apps.

I like 3 - would be nice to see a mockup of it. If 3 doesn’t work I’d lean towards option 1. Don’t think option 2 really helps.

[prabhaav]

Since it’s mobile, what about sending them a security code?

[larry]

Since it’s mobile, what about sending them a security code?

This is a great idea and a good reminder that we need to support phone number since some markets don’t have wide email usage!

[jeffd]

Go ahead and remove it Ken. Please don’t add anything else or make any specific changes for desktop/mobile, just remove. We can test other stuff in the next round of testing.

[jeffd]

@yukan @larry @hank I’ve been contemplating this deep link issue and feeling like even if we get 1/2 there our solution will be brittle and will behave differently on different devices. This is weird and tedious for users and for us to maintain. And could be bad for support as well. Would prefer a simple solution that works in all cases and acts the same in all cases.

We never tested this, but I’m wondering if we should scrap the notion of links on that feature all together and just ask users to copy/paste a string or scan a QR code. More tedious than a link and more confusing, but will get the job done more reliably. Just seems like the cost/benefit trade off of the links finally tipped to “not worth it”.

Thoughts?

[digitalwaveride]

Since it’s mobile, what about sending them a security code?

If a main selling point of Blockstack and affiliated apps is “owning your data” and privacy issues, then I would generally avoid to work in the sign up process with requiring any sensible data like a telephone number.

But as Blockstack maybe should go on this topic the extra mile, please forgive me to ask the question:
Why do you require the email address at all?

Shouldn’t it be possible to sign up with Blockstack without any additional data required?
If so, you could for recovery purposes offer users several ways to provide some data in an extra step, like email, phone and maybe other channels as well, but you would not make it mandatory.

That way you have less friction cause users can skip the step easily, and even if users decide to use a recovery option, users will see it less annoying as it is their own deliberate decision.

Most importantly though you signal to users what Blockstack is about:
“You are in control of your own data.”