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

Improve the UX for messages that cannot be decrypted #5642

Closed
kaiyou opened this issue Nov 18, 2017 · 4 comments
Closed

Improve the UX for messages that cannot be decrypted #5642

kaiyou opened this issue Nov 18, 2017 · 4 comments
Assignees
Labels
A-E2EE S-Tolerable Low/no impact on users

Comments

@kaiyou
Copy link
Contributor

kaiyou commented Nov 18, 2017

Currently, messages that cannot be decrypted display an error message in Riot, mostly because they were encrypted at a previous step in the ratchet, that the current client has no access to.

One of the main complaints about E2EE in Matrix and Riot is related to new devices joining chatrooms and not being able to decrypt messages. Hopefully, working on key sharing will help this a lot, but it does not solve the UX when first joining a room that has been encrypted for some time.

An ideal UX would include a way to ask other room members (admins ?) to share a previous state of the ratchet, like "please give me access to the whole history of the room" or "please give me access to this week's history". It could even be suggested when inviting someone, a "share the entire room history" checkbox, or "share history since ..." select box.

Anyway, before these can be implemented, not being able to decrypt history is the normal behavior, so I think the UX should reflect that. Maybe we should replace the standard error message with a display similar to redacted messages, maybe turn it red, add a lock, or anything that suggests it was encrypted and the current client has no access. Hovering it could display the actual error message in a tooltip.

encrypted

This could be improved further by offering the user to simply not display them if they were sent prior to the client joined the room, or replace them with a single banner that says "encrypted history" and would later say "encrypted history, click here to request access".

@tessgadwa tessgadwa mentioned this issue Nov 18, 2017
71 tasks
@ara4n
Copy link
Member

ara4n commented Nov 18, 2017

The idea of using the more visual undecryptable UI appeals, although in practice I suspect we'd be better off hiding old history if we don't have the keys (this is #2258). Meanwhile, key-sharing to request keys that pre-date your arrival in a room is hopefully on the relatively near horizon (https://github.com/vector-im/riot-web/issues/2286) - and there's also potential to preemptively encrypt in 1:1s (#3821).

@lampholder lampholder added S-Tolerable Low/no impact on users feature P4 [OBSOLETE LABEL] Interesting — Not yet scheduled, will accept patches A-E2EE labels Nov 23, 2017
@kaiyou
Copy link
Contributor Author

kaiyou commented Nov 24, 2017

Hiding the history would indeed improve the ux, but then the user would not know that there is a history to be decrypted. I would still find interesting to display clues that the history exists but the user has to request access.

@uhoreg
Copy link
Member

uhoreg commented Jan 23, 2020

We're going with just hiding the history for now, since we don't really have a way currently for users to actually get keys to decrypt old history. If/when we fix https://github.com/vector-im/riot-web/issues/2286 then we may change it.

@jryans
Copy link
Collaborator

jryans commented Jan 28, 2020

Fixed by matrix-org/matrix-react-sdk#3881

@jryans jryans closed this as completed Jan 28, 2020
@jryans jryans added the phase:1 label Feb 12, 2020
@jryans jryans removed feature P4 [OBSOLETE LABEL] Interesting — Not yet scheduled, will accept patches labels Apr 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-E2EE S-Tolerable Low/no impact on users
Projects
None yet
Development

No branches or pull requests

5 participants