Inconsistent recommendations about browser crypto

[weavejester]

When a user tries to verify or encrypt in the browser, we get a reasonably good warning message:

Browser crypto can be scary! Do you have a malicious extension installed? We can't tell. Further, how can you guarantee we haven't been tortured into serving you custom, targeted JavaScript? Hopefully you're not that important.

So: please only do browser crypto if (1) you feel your browser is clean and (2) a life does not depend on it.

That's not too bad, especially since your service only has my public key, and therefore incapable of doing anything a random person on the internet couldn't anyway.

But then in your setup process you give what seems like the opposite advice:

Keybase can also store a client-encrypted copy of your private key.

This is not mandatory, but it's very convenient. For safety, the Keybase servers never see your passphrase, even during login, and therefore cannot decrypt your private key.

Where's the huge warning message this time? Trusting my private key to in-browser crypto? Okay, so not everyone has a private key that protects sensitive information, but for those of us who do, this is madness!!

I really think you should reconsider how you present this. It feels very unprofessional, even for a beta, akin to having asked for the passwords to my bank accounts. I think you should at the very least assume that if a user has their own keypair already generated, they will never want to trust their key to in-browser crypto.

I also wonder whether having in-browser crypto is going to be good for you in the long run. It's convenient, but doesn't exactly engender confidence. Ideally I'd prefer you place security over convenience, rather than the other way around.

Have you considered instead a node-webkit client that wraps GPG (and maybe installs it if it doesn't exist on the system already)? You could use the same interface you have now, without the questionable security of the web browser.

[gwillen]

Browser-based crypto sucks, but usability has killed consumer encryption for at least 15 years:

https://www.usenix.org/legacy/events/sec99/whitten.html

So I think compromises must be carefully examined and deployed where there's no reasonable alternative, as historical evidence suggests is the case here.

I think it would be good to focus on usability and messaging: How do we educate the user about the risks, and give them some realistic idea of the actual dangers? If they're using their key to sign messages to their buddies, no big deal. If they're using it to authenticate to something, maybe a big deal, but almost nobody's doing that yet, and it's very difficult if you don't already know what you're doing. If you're using it to sign promissory notes for millions of dollars, very big deal, but again, nobody's doing that yet, and we've got a long way to go before we get there.

[weavejester]

I think you're underestimating how often public keys are used to sign software releases or version control commits, but I'll grant that its still a small segment of the population (though I suspect a larger proportion of early adopters).

I also wonder whether or not downloading an app that would do the same thing as your browser interface is really a huge hurdle. People download apps all the time - is it really that such huge a deal that you need in-browser crypto? Surely the act of signing up to a website is actually more hassle than downloading something?

[weavejester]

I'm deviating from the issue at hand, though, which is just a better warning message on the in-browser private key. Apologies for getting sidetracked.

[copumpkin]

I too was taken aback at the suggestion to import my private key without some pointer to the dangers of doing so. Clearly the developers are aware of these dangers since the warning on other parts of the site is pretty good.

[gwillen]

@weavejester No worries -- I think this is an important discussion to have, because this WILL get pushback, again and again, so it's important to (1) understand EXACTLY what the right tradeoff is, to allow for the best user experience while giving as much security as possible, and (2) have good messaging to deal with the criticism that's inevitably going to happen.

Have you read the paper I linked, "Why Johnny Can't Encrypt" from 1999? It makes for fascinating reading; it's about crypto usability and why PGP was basically a failure for end users.

[gwillen]

Actually, I'm going to change my tune on this slighty, after some other conversations -- I would encourage you to set out a plan for how you expect to deal with the subpoena issue, before any public launch with a key-upload feature.

(The subpoena issue: You get a subpoena or NSL for a user's key. You are forced to serve that user new JS which captures their password, decrypts their key, and sends it to you in the clear. If it's an NSL, you are forced to do this without notifying the user.)

This has happened before and will happen again, so you should at least be aware of and comfortable with the issue before proceeding.