Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explain manual and automated key backup a little better #8751

Open
aaronraimist opened this issue Feb 17, 2019 · 8 comments
Open

Explain manual and automated key backup a little better #8751

aaronraimist opened this issue Feb 17, 2019 · 8 comments

Comments

@aaronraimist
Copy link
Collaborator

@aaronraimist aaronraimist commented Feb 17, 2019

Lots of people tend to think manual key backup is something like GPG, ie if you export the key as soon as you create your account you'll be able to decrypt all future messages that are sent after you exported the keys.

@aaronraimist

This comment has been minimized.

Copy link
Collaborator Author

@aaronraimist aaronraimist commented Feb 17, 2019

It also needs to be more clear that key backups to the server are stored on your homeserver. Not some central matrix.org server.

@drathir

This comment has been minimized.

Copy link

@drathir drathir commented Feb 19, 2019

Agree clarify of remote storage in use would be nice in description, also taking on mind if that some kind of private kinda keys would be nice as well get possibility of gpg/passphrase/one time paste style send to email address protection type i guess (theoretically speaking only, bc not checked/searched for type of data send by this feature).

@matthijskooijman

This comment has been minimized.

Copy link

@matthijskooijman matthijskooijman commented Feb 22, 2019

I just tried setting up automatic key backup and found that there's a lot of stuff that's not really well-explained through the UI. Here's some questions that crossed my mind:

  • What is stored on the server exactly? A backup of my room keys, I suppose. Encrypted using a recovery key? Or my passphrase? Or both?
  • Where is the backup decrypted? I assume in the browser, so the server never sees the actual keys? Of course, a malicious server could still easily inject malicious javascript to sniff the passphrase and keys, of course...
  • How do the recovery key and the passphrase correspond to each other? It seems these are basically equivalent in how they can be used? Or does the passphrase normally encrypt the recovery key?
  • How does key backup work with multiple devices? Normally, multiple devices seem to have their own E2E keys I believe? Does key backup allow sharing a single set of keys among devices? Or will they just have their own parallel backups? How does this interact with the key sharing feature?
  • Does the recovery key ever change? I've tried a some things with different browsers (also coming back to existing browsers) and found that I got different keys.
  • As long as your browser (or other device using key backup) remains logged in, you can always access the original keys, and also setup new backups (even if you forgot your passphrase or recovery keys), right?
  • When I enter a passphrase or recovery key, is it stored in the browser? I guess it should (or perhaps an underlying backup encryption key) since it must be able to add new keys to the backup later?
  • What does it mean for a backup to (not) have a signature from a device?
  • How are backup versions handled? Does any change to the backup (content / keys / etc) result in a new version?

I don't think all of these questions should be answered in the interface directly, but perhaps the UI could be changed to support a more useful mental model of what goes on in the background, and perhaps also link to more complete documentation (I just found https://about.riot.im/help#end-to-end-encryption which has some info already).

@lampholder

This comment has been minimized.

Copy link
Member

@lampholder lampholder commented Feb 26, 2019

Agreed - we're trying to strike a balance between informative and overwhelming, and to provide enough information to reassure encryption/privacy novices, experts and everyone in between.

This list of questions is very useful - we can take another look at the wording/UX with this in mind and see what we can change to answer more of these questions as you work your way through setup.

@turt2live

This comment has been minimized.

Copy link
Member

@turt2live turt2live commented Apr 15, 2019

This is becoming more prevalent thanks to recent events. There's numerous reports of people taking their exported keys from months/years ago and trying to import them, expecting that to work. We should fix the messaging so that in N years we don't have to tell people that export !== backup.

@cyphar

This comment has been minimized.

Copy link

@cyphar cyphar commented Apr 16, 2019

I will admit when I first turned on key backups I went to read the MSC to make sure I understood how the system actually worked -- which is far from ideal if we want the security of the system to be self-apparent (as an aside I think the design is really brilliant). I think the simplest way to improve people's understanding of how key backups work is to apply a couple of helpful tips (which might help some of @matthijskooijman's questions):

  • Add a (probably red) warning to the key export feature explaining that in encrypted rooms the session keys will roll over quite regularly and thus exported keys will not be useful for decrypting future messages soon after you've done the export. This is the biggest mistake I've seen and it's a shame we didn't have better text on this before (I know I've made this mistake before -- and only realised when I noticed the key exports were getting larger each time I did an export).

    • There should also be a button for using key backup on the key export page to hopefully explain that key export requires more work on the users' side. Most of the text on key export could probably be dropped to make it more likely people will read it.
  • Change the key backup setup flow, so that you first get the recovery key and then are asked for the passphrase (with some text on the passphrase prompt saying that it's optional -- but recommended -- that the recovery key be encrypted and saved to the homeserver so that the user doesn't have to keep track of it). This might help users understand that the recovery key is the primary recovery system and the passphrase is just there to not require you to keep track of the recovery key (the current text is "We'll store an encrypted copy of your keys on our server. Protect your backup with a passphrase to keep it secure." which is quite misleadingly-written -- arguably it's more secure to not set a passphrase since then the private key never hits the server).

  • I would suggest having a (skippable) "getting started" screen for enabling e2e encryption which might explain some of the questions that @matthijskooijman mentioned above. Since the plan is to make all private rooms e2e-only we should probably work on the onboarding flow now rather than later.

    • I think there is a fairly good "intuitive" way of explaining how key backups work (you could even do it graphically to help get the point across) -- padlocks and keys. When you set up key backups, you create a new key and a large number of corresponding padlocks. You keep this key safe, and whenever you're chatting with someone and you get a new session key you put it inside a safe box and lock it with a padlock and send it to the homeserver -- you only need the recovery key when you need to do a recovery. I bet that a lot of confusion could be avoided with some picture-based explanations (something like the Keybase art style would be great IMHO).
@jryans

This comment has been minimized.

Copy link
Member

@jryans jryans commented Apr 17, 2019

Perhaps we could restructure some of our in-app messaging to show first the simplified explanation for everyone, but then add a disclosure something like:

More details Advanced encryption explanation details go here.

so that we can still offer more detail for those who want without overwhelming those you don't.

@cyphar

This comment has been minimized.

Copy link

@cyphar cyphar commented Apr 17, 2019

That would be a good stop-gap to at least provide some sort of information to those who should be aware of things, but I think that all the E2E messaging needs to be made layperson-friendly if we want people to turn it on (or make it the default) without being surprised when the last 12 months of chat history with their loved ones has gone up in smoke (I'm a technical user and this happened to me, but it's a painful mistake to make).

I'm aware (and really grateful) that the technical side of this is being worked on very hard (and the results speak for themselves -- the new e2e features are really top-notch), but making a good on-boarding experience with encryption (or even Matrix in general) would really help users avoid some pitfalls.

I'm fairly convinced the best shot of making it reasonable is to do it graphically (I'm really not an artist but I could knock up some mock-ups to hopefully show why graphical explanations would help). Unfortunately you'd need a designer to actually make them usable -- and they are painfully hard to find within free software communities (despite how desperately we need them in most free software projects).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.