Skip to content

Element is not a functioning messaging application at low live session counts #1894

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

Closed
pfdint opened this issue Apr 17, 2021 · 4 comments
Closed
Labels
P2 S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect X-Needs-Community-Testing

Comments

@pfdint
Copy link

pfdint commented Apr 17, 2021

Encrypted messages cannot be received (decrypted) when the number of living sessions is zero.

What I expect from a messaging application:
I log in and read messages sent to me.
I log out and go do things.
I log back in and read the messages sent to me while I was away.

Element does not actualize this basic functionality.

  1. When I log out, meaning when I kill the final living session, messages sent to me are never able to be decrypted. I log in and verify using security phrase, but the messages sent while the number of living sessions was zero are lost forever. Those messages have a link to request keys from other sessions. But there are no other sessions.

  2. The same effect is true when zombie sessions exist. When a user closes Element but does not sign out, the session lives on but becomes inaccessible, creating a zombie session. Restoring using security phrase does not decrypt the messages. Those messages have a link to request keys from other sessions. But the other sessions are all permanently lost. Whether invoking the security phrase fails because a decryption action simply isn't triggered or whether the relevant keys are not in the backup I cannot say.


To reproduce 1):

  • Create new account
  • Set security phrase
  • Enter a private chat with a second-account. Messages are sent and received as normal here.
  • Log out, killing the only session in existence.
  • Have a second-account send the new account messages.
  • Have the new account log in and verify by security phrase.
  • Observe that messages received while logged out are permanently inaccessible.

To reproduce 2), which is likely a variation on 1):

  • Create new account in an incognito tab.
  • Set security phrase
  • Enter a private chat with a second-account. Messages are sent and received as normal here.
  • Close chrome without logging out.
  • Have a second-account send the new account messages.
  • Have the new account log in and verify by security phrase.
  • Observe that all messages received before this login are permanently inaccessible.

This occurs on the web client on at least chrome 90 and firefox 89, archlinux.
app.element.io

This may be what element-hq/element-web#16184 refers to.

@pfdint
Copy link
Author

pfdint commented Apr 17, 2021

@BrenBarn
Copy link

#310 is also related. But I think you have stated the issue succinctly and I quite agree. The way people expect a messaging app to work is that when you log in with your username and password you have access to every message ever sent to that username, period. Element does not conform to that expectation (and neither does Matrix as a whole, since as far as I can tell no other client even handles encryption as well as Element does, let alone as well as Element should).

@richvdh
Copy link
Member

richvdh commented Apr 30, 2025

This seems mostly to be a rant. I appreciate you're frustrated, but walls of text like this don't really help anyone.

The way people expect a messaging app to work is that when you log in with your username and password you have access to
every message ever sent to that username, period.

That's not what you get from plenty of other messaging applications, including WhatsApp and Signal, to name but two, so I'm not sure it is the way people "expect" a messaging app to work.

Anyway, dehydrated devices (#922) should fix the problems reported by the OP. Closing as a duplicate of that.

@richvdh richvdh closed this as completed Apr 30, 2025
@RokeJulianLockhart
Copy link

RokeJulianLockhart commented Apr 30, 2025

#issuecomment-2841857448

That's not what you get from plenty of other messaging applications, including WhatsApp and Signal, to name but two, so I'm not sure it is the way people "expect" a messaging app to work.

@richvdh, I have a distinct example of that being untrue:

  1. Until I joined the Army in 2022, I'd never used Signal. Until I joined my local neighbourhood in 2024, I'd never used WA. I lost my Signal messages when switching devices, and it came to me as a very unpleasant surprise, causing me to lose important documents.

  2. My parents have never used Signal, and they've never switched devices since they began using WA. When they do, losing their WA messages shall come as a serious and unwelcome surprise.

There are a great many people used to Discord and Messenger who have never even considered that their messages wouldn't be stored on a server with the decryption key tied to their account.

#event-17472332735

closed this as completed

This should be invalid/not planned, or marked as a duplicate of issues/922#issue-1550511101.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect X-Needs-Community-Testing
Projects
None yet
Development

No branches or pull requests

7 participants