If a web session is closed without signing out, messages received afterwards will be unable to be decrypted

[woojoo666]

Steps to reproduce

I've noticed that if the user closes a web session and loses the session completely (eg it was in an incognito/private window, or the user cleared all cookies), that session will still be considered "active" by Matrix. And there are scenarios where this can cause messages to be indecipherable.

From what I've tested, the following steps will consistently reproduce this bug (I added a screenshot of the process below that should help as well):

1. User 1 and User 2 are in a room together
2. User 2 signs into Element Web in an incognito/private session, and verifies using their security phrase. This should be their only active session
3. User 1 and User 2 exchange some messages
4. User 2 closes their incognito session, without signing out of their Element Web session
5. User 1 sends a message to User 2 while they are signed out
6. User 2 signs into Element Desktop and verifies using their security phrase
7. User 1 and User 2 exchange a few messages
8. User 2 signs out of Element Desktop
9. User 1 sends a message to User 2 while they are signed out
10. User 2 signs into Element Desktop and verifies using their security phrase
11. User 2 will be unable to decrypt User 1's last message

Note that nothing User 2 does seems to help, like restoring keys from secure backup, or re-requesting keys for the message, or signing out of the old web session from element desktop and then re-requesting keys for the message. Also note that interestingly, the second time User 2 signs in, they can view the messages they received while they were gone. It's only when User 2 signs in a third time, that they can't decrypt any messages received while gone.

Now I can understand that this is probably very tricky to solve, because there's no way for Matrix to tell the difference between a web session that can be restored (eg you closed the browser but the cookies are still stored) and a web session that is lost (eg you cleared all cookies). However, I still feel like there should be a way for verified users to decrypt their messages without requesting keys from other "active" sessions. This may be related to #3822 and Matrix Olm unwedging proposal.

I am not too familiar with the double-ratchet protocol and olm sessions, but one idea I had: if a user signs into a new (verified) session and there are other "active" sessions that cannot currently respond to key requests, then we fall back to the trust from identity keys (as mentioned in #3822). But if one of those other active sessions comes back online, it can upgrade the user's current session to full trust with shared ratchet state.

I'm not sure if this "upgrade" step is possible, but even if so, I think we should still consider at least allowing the user to decrypt their messages, even if it means falling back to the trust from identity keys. Consider the following: if User 2 in the scenario above had simply signed out of their web session in the first place, then they would have no issues with decrypting subsequent messages. So in a sense, User 2 is being punished for closing the window instead of signing out of their web session. Considering entire chains of messages can be lost from such a small action (see below), this seems like a bit harsh.

Outcome

What did you expect?

Messages received while offline should be able to be decrypted.

What happened instead?

I am seeing the message

** Unable to decrypt: The sender's device has not sent us the keys for this message. **
Re-request encryption keys from your other sessions.?

Operating system

Windows

Browser information

Ungoogled Chromium Version 96.0.4664.45

URL for webapp

app.element.io

Application version

Element version: 1.9.9 Olm version: 3.2.8

Homeserver

matrix.org

Will you send logs?

Yes

[woojoo666]

perhaps this should also be added to the compilation of UISI bugs here: #2996

[t3chguy]

Duplicate of element-hq/element-meta#1893

[woojoo666]

Just wanted to mention that today I happened to open room I used for testing in this bug report, and all the messages are now decrypted. So I guess it may have just been a delay issue? Reading other threads, it seems like as long as you have at least one active session, then eventually your messages should be decrypted, which is a little reassuring but the general opaqueness of the errors is still worrying. Timely decryption is failing and users have no idea why and no recourse except to wait and hope the keys arrive someday