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

Can't verify, encrypted messages broken #16184

Open
dcz-self opened this issue Jan 17, 2021 · 7 comments
Open

Can't verify, encrypted messages broken #16184

dcz-self opened this issue Jan 17, 2021 · 7 comments
Labels
A-E2EE-Key-Backup A-Storage Storage layer of the app, including IndexedDB, local storage, etc. O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Impairs non-critical functionality or suitable workarounds exist T-Defect

Comments

@dcz-self
Copy link

This is a usability issue, but not reproducible, so sorry for no pictures.

Description

At some point, Matrix started to ask to verify on login, which isn't possible. All encrypted messages come in as a notification that they can't be decrypted.

What happened exactly

  1. I logged in to Element (not the official instance)
  2. Firefox popped up a notification that the site wants to save some data.
  3. Dialog was dismissed with "no".
  4. Element showed some introduction to encryption.
  5. Closed the browser.
  6. Started the browser again.
  7. Logged in to Element. The following happens at each login.
  8. Element asks to verify using a web session (this is what I'm using), or an Android one (never existed).
  9. Element will let me know that messages can't be decrypted whenever they come encrypted.

Describe how what happens differs from what you expected.

I would have expected some way to leave this impasse.

I suspect Element lost my private key that it generated before it showed me the encryption screen. I would have expected a warning not to throw away the key before I had a chance to do it.

I suspect that my browser cleans cookies aggressively doesn't let Element keep any new keys. I would have expected some information to allow permanent storage if that is the case.

I would expect Element not to ask to verify when it's not possible.

Version information

  • Platform: web
  • Browser: Firefox 82.0.2
  • OS: Fedora
  • version: 1.7.10
  • olm version: 3.2.1

Extra info

  • Browser configured to drop cookies/storage on close
  • Quaternion also used as a client, but doesn't offer any verification that I can find

This can be argued is not an issue due to the user deliberately dropping storage, but the UI doesn't do anything to warn against it.

@jryans jryans added defect A-E2EE-Cross-Signing A-E2EE-Key-Backup P1 S-Minor Impairs non-critical functionality or suitable workarounds exist labels Jan 25, 2021
@jryans
Copy link
Collaborator

jryans commented Jan 25, 2021

@dcz-self Thanks for the detailed feedback, I believe there may indeed be some UX gaps here.

I do have one question though... Since you say you are just closing the browser tab (presumably not signing out in the Element UI), when would you expect warnings or prompts to appear?

@jryans
Copy link
Collaborator

jryans commented Jan 25, 2021

Related to #16123

@greve

This comment has been minimized.

@jryans

This comment has been minimized.

@greve

This comment has been minimized.

@dcz-self
Copy link
Author

dcz-self commented Feb 9, 2021

I do have one question though... Since you say you are just closing the browser tab (presumably not signing out in the Element UI), when would you expect warnings or prompts to appear?

I don't think I have a good answer to that, but here's what I have. I would definitely stop and pay attention if I got a message "we'll generate your encryption key now. Make sure to accept the next dialog" before Firefox prompted me about storing data. The downside is that this adds another step to the process, and not everyone might have a clue about encryption.

Another thing that would have definitely worked for me is it Element detected that the keys did not get saved permanently and gave me access to the plain text, along with instructions for importing them again. Or some way to retry the process.

If there's no way to detect if the user accepted the data storage, then I might have gave it a thought if I got told something along the lines of "now you can use end to end encryption!". I might then realize that it doesn't quite click without a permanent place for keys, and would click any "learn more" button hoping that it tells me where the keys are stored.

@jryans jryans removed defect labels Mar 4, 2021
@uhoreg uhoreg added A-Storage Storage layer of the app, including IndexedDB, local storage, etc. O-Occasional Affects or can be seen by some users regularly or most users rarely and removed P1 labels Aug 15, 2022
@uhoreg
Copy link
Member

uhoreg commented Aug 15, 2022

It sounds like the main issue here is that Element should detect if it is able to use IndexedDB, and if not, display some sort of warning that things may not work properly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-E2EE-Key-Backup A-Storage Storage layer of the app, including IndexedDB, local storage, etc. O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Impairs non-critical functionality or suitable workarounds exist T-Defect
Projects
None yet
Development

No branches or pull requests

4 participants