[WIP] QR Codes

[wbobeirne]

Closes #1498. Closes #1343.

What This Does

This is some exploratory work into integrating QR codes into the recovery and backup process. Users will be able to scan QR codes to recover with their secret phrases or recovery codes. They'll be able to get these codes from the backup page, now renamed "backup & restore".

I also removed all uses of the phrase "keychain", instead opting for "Secret Recovery Key," "Magic Recovery Code," and "account" where applicable.

Screenshots / Demos

Recovery Demo

Scanning a bad code

Renamed settings page

Encrypted key & QR

Recovery key & QR

[hstove]

Will, amazing work. Love it

[yknl]

This works really well! Great job Will!

The only thing is that it doesn't seem to work with the iOS SDK. During sign up, the SDK loads the browser in a very limited Safari view that doesn't have access to camera inputs.

We can add an URL param that disables the QR code scanning buttons and have the iOS SDK load that URL. Thoughts? cc @shreyasthiagaraj

[wbobeirne]

Agh, that's super disappointing. Is there any way we can request the permission when the user clicks on the QR button? That would be ideal.

[yknl]

I think there's a potential workaround. If we can detect that the user is tapping the QR code button on the limited auth session browser, we end the auth session and return a special code to the SDK. The SDK can then natively launch the camera to scan the QR code. After it has parsed the magic recovery code from the QR code, it can trigger the Safari auth window again and pass in the code as a URL param. Then the authenticator can proceed directly to the password step and perform the rest of the restore.

The caveat here is that every time the Safari auth session is called, a prompt will appear asking if the user wants to auth with browser.blockstack.org. So in this flow, the prompt would appear twice.

Another caveat is that a malicious app might attempt to access the encrypted seed. I don't think we should pass the unencrypted recovery seed phrase back to the SDK.

Also, most of the work here would be on the iOS SDK so @shreyasthiagaraj can chime in.

[wbobeirne]

pass in the code as a URL param

I think this is a non-starter, as the param may include a mnemonic phrase. That would get sent to our server.

I'm also fine disabling this in the minimal view, and just waiting for a native authenticator for this functionality. This'll still work for non-native apps, which is the majority at the moment.

[yknl]

I think this is a non-starter, as the param may include a mnemonic phrase. That would get sent to our server.

Right, that's why we would only allow scanning of the encrypted magic recovery code via this method.

I think it's easier to disable it in the mobile view for now.

[wbobeirne]

@shreyasthiagaraj is there a way for me to detect that I'm in the SDK webview mode? Having a hard time finding bullet-proof JS-only methods.

[shreyasthiagaraj]

@yknl's earlier suggestion would technically work, but it looks like we're not going in that direction.

@wbobeirne by "SDK webview mode" do you mean the browser window that is popped up by the iOS SDK for authentication? Nothing I know of to detect this, I'm not sure whether this is possible. Perhaps I could pass a parameter indicating this?

[wbobeirne]

@shreyasthiagaraj that might be the only 100% way to do it. Looks like there are a few heuristics we can use to detect without it. Could you throw a param on top of the hash that's something like &native=ios or something like that? Never know when we might need that for other differences in the flow.

[shreyasthiagaraj]

@wbobeirne Yep, i can do that. Does &client=ios_secure work? Because this should not be needed if you end up here via Safari on iOS (only using this secure webview thing used from within other apps).

[wbobeirne]

I think the thing I want communicated with the param is that this is coming from a native auth request, not a web auth request. Whatever you feel communicates that best is fine with me. We should also get parity with it on the Android SDK.

[shreyasthiagaraj]

@wbobeirne FYI I added &client=ios_secure. Felt like this was the best label considering we can also have a version of auth on ios apps (in iOS 12 or below iOS 11) that does not have this restriction.