UI: No indication on how to resolve missing E2EE history

[LEdoian]

Description

When a user cannot decrypt older history, the history does not show at all, leaving the user without any obvious clue why that happens.

This is more problematic when migrating between accounts and the old account also sees that history should be visible (#13349). In this case the user is able to help themself by exporting and importing E2EE keys, but there is no hint that they need to do that.

Steps to reproduce

• Have an E2EE conversation, with some messages that should be visible to anyone
• Invite another account
• Accept the invitation

The invited account does not see the messages, nor any information that they are not visible and why. Also, the original (inviting) account has no feedback that the new account will not be able to see those messages, yet that could be presumed by the client (i.e. do not expect the invitee to have the keys already imported).

Logs being sent: no

Version: 1.6.2 web
Related: #1287

[bwindels]

Hi @LEdoian. Indeed, migrating accounts is not something that is well supported currently, but it looks like you found the workaround already by importing E2EE keys from your other user.

We purposefully hide decryption errors from before you joined to not confuse users that just joined a conversation. In this case, there is no resolution as the messages weren't encrypted for them, so decided to avoid unhelpful noise.

Your case of migrating an account is something less common and indeed it can be a bit confusing that you need to export key. We'll take this feedback into account if we decide to rework this part of the UI.

[Nokayn]

@LEdoian mentions the migration case as a specific example, but the bug is not limited to this case, and the bug is in my opinion severe. To see this, try ignoring the "Description" section of @LEdoian's report, and reading only from "Steps to reproduce".

In other words, any user who is invited to an E2EE room will be unable to see any pre-existing history in the room. This occurs to me (or rather, my contacts) every time I invite someone to an E2EE room.

My typical case is that I have a room for some sort of collaboration, with some number of initial members. Then, later, we need to invite someone new, and they need to see the room's history as well. Just as per this bug, the history will not be shown, and the UI offers no explanation as to why. To even further confuse the user, the setting "Who can read history?" is, in my typical case, shown as "Members only (since the point in time of selecting this option)" for all users in the room - including the newly joined who is quite unable to see any history, in contradiction of this setting. The room was indeed created with this setting, but it is clearly not having the stated effect.

Unless I am missing something obvious, this ought to be a prioritized bug, no?

[Bumbadawg]

+1 for pre-existing history not appearing when joining E2EE room. Dunno if it's a bug or a feature at this point =D

[t3chguy]

+1 for pre-existing history not appearing when joining E2EE room.

That is the current behaviour on Web and Desktop.

[Bumbadawg]

You mean on Android or exotically Weechat there is the pre-existing history in E2EE rooms ?

[t3chguy]

no idea about Weechat but most clients will just show you a wall of unable-to-decrypt errors from before your join instead of hiding them sensibly.

[Bumbadawg]

So if i understand the protocol from what you say: (maybe a dev would answer better)
A and B are discussing in the room.

• before C joins: the room is E2EE with keypair X for A and B
• after C joins: the room a new keypair Y is used for A, B and C.
  The protocol documentation isn't clear about the E2EE key exchanges.

[JonathanReifer]

+1 I get the same issue, basically in an e2ee room, the Who can read history? option,
Members only (since the point in time of selecting this option) <- doesn't work, behaves the same as Members only (since they were invited)
Confirmed in element-web (from app.element.io) and Element electron, and element-ios.

[sebastian-peter]

I experience the exact same behavior as @JonathanReifer stated, any news on this? Members only (since the point in time of selecting this option) works as if Members only (since they were invited) had been selected on E2EE rooms

[yamrzou]

Encountering the same issue as @JonathanReifer described. Any idea how to solve this?

[MadLittleMods]

Has this been helped at all by the Decryption failure bar (DecryptionFailureBar.tsx)? Does it properly explain the possibilities and resolve situations that people have experienced here? cc @duxovni

(screenshots taken from our Percy screenshot tests in CI)

[MadLittleMods]

For everyone talking about the Members only (since the point in time of selecting this option) history visibility option not working as expected in encrypted rooms, I think this reply sums up the situation:

The room history settings do work as you expect them to in unencrypted rooms. And at a technical level, they "work" in an encrypted room: new users actually can receive the old encrypted messages, but they will be missing keys to decrypt them.

At the moment, Element Web hides these undecryptable messages to avoid presenting you with an ocean of error messages that you can't do anything to fix.

-- @jryans, element-hq/element-web#15965 (comment)

To expand further and document the current state of all of this (mostly derived from reading #647), here is what works and doesn't work:

• ✅ Sharing decryption keys from your own devices, Implement sharing of megolm keys matrix-org/matrix-js-sdk#454. This doesn't help in join/invite scenarios because you weren't ever in the room to get the keys. It does help onboard your new devices or when your devices try to catch-up though.
• ✔* Users being invited into E2EE rooms with sharable history. *The inviter has to be from Element Web or Element Desktop in order for this mechanism to work. And it seems like only "only sessions created by Web & Desktop correctly flag the megolm sessions as sharable at this time.". This requires Implement MSC3061: Sharing room keys for past messages on Invite #39 in order for this to work without caveats.
  • Add function to share megolm keys for historical messages, take 2 matrix-org/matrix-js-sdk#1640
  • Share keys for historical messages when inviting users to encrypted rooms matrix-org/matrix-react-sdk#5763
  • Enable sharing historical keys on invite matrix-org/matrix-react-sdk#5839
• ❌ Joining or peeking in a E2EE room with sharable history does not work to see the room history. In this case, people are joining without an invite so they never get the encryption keys for historical messages as described in the previous point.
  • ❌ This also applies to rooms with restricted membership based on spaces and people join on their own.

Give some indication of why history is missing

It would be good to add a warning to the top of the timeline explaining what's going on to the users experiencing the missing history. Perhaps an extra case in the DecryptionFailureBar.tsx but more likely updating this block that appears:

And warnings in room settings for combinations of enabling encryption and the history visibility options, see #1356

A full solution

To fix this problem, sharing room keys for past messages on invite is tracked by #749

Relevant MSC: MSC3061

Related issues:

• Implement MSC3061: Sharing room keys for past messages on Invite #39
• Let devices request keys to decrypt past history for a room. #647