If a web session is closed without signing out, messages received afterwards will be unable to be decrypted #20808
Labels
A-E2EE
T-Defect
Z-Rageshake
Has attached rageshake (not for log submission process)
Z-UISI
Unable to decrypt errors
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):
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
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
The text was updated successfully, but these errors were encountered: