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

Entire chat history lost #15546

Closed
vy-let opened this issue Oct 24, 2020 · 13 comments
Closed

Entire chat history lost #15546

vy-let opened this issue Oct 24, 2020 · 13 comments
Labels
A-E2EE O-Uncommon Most users are unlikely to come across this or unexpected workflow P1 S-Critical Prevents work, causes data loss and/or has no workaround T-Defect X-Needs-Info This issue is blocked awaiting information from the reporter

Comments

@vy-let
Copy link

vy-let commented Oct 24, 2020

Description

My partner's phone randomly lost its ability to decrypt my messages, across all rooms. (Element seems to do that a couple times a year, which is troublesome, but perhaps a separate issue.) In order to try and resolve this, I tried several things, to create some layers of redundancy:

Steps to Reproduce

First I walked her through setting up key backup, which appeared to go smoothly.

Next, I had her sign in to Element on her desktop (for the first time). She confirmed on her phone that the session was valid, and everything came in fine on desktop --- except messages from me, which were still "unable to decrypt." But moments later, Element on the phone said she had to sign in again. From this point forward, her phone app became unusable, stringing through seemingly-random sequences of logins, key backup passwords, verification dialogs (all of which would fail), until we resorted to deleting the app and reinstalling it out of frustration.

This is where the real trouble began. After signing into the freshly-installed app, the desktop session suddenly dropped all keys it had to previously-decrypted messages, across all contacts and all rooms. The fresh mobile session similarly had no messages visible. I can send new messages to her, which she can see, but she can't see any past history whatsoever.

I had her restore from key backup on desktop, where it said "Successfully restored 0 keys."

I then tried verifying her, which worked, but restored no messages.

Aftermath

My partner is understandably quite upset that the app dropped her entire message history. Personally I'm more interested in figuring out how to keep this from happening in the future, and figuring out how to get my devices and her friends' devices to re-encrypt all past history in shared rooms for her new login sessions.

I've tried searching past issue threads about this, but the ones that seem applicable all get into lengthy technical discussions that I can't make heads or tails of. I just want to get this problem resolved.

Version information

  • Platform: desktop app

For the desktop app:

  • OS: macOS 10.15.7
  • Version: 1.7.10

For the mobile app (in case it's relevant):

  • OS: iOS 13.6.1
  • Version: 1.0.16 master 20201013143907, Olm version 3.1.0
@ara4n
Copy link
Member

ara4n commented Oct 24, 2020

@vy-let sorry for this mess :( it's going to be a bit of a nightmare to debug this, as the logs on the phone will have been lost when the app was reinstalled.

Can you please rageshake (i.e. submit debug logs) from a) the device you were sending msgs from, b) the desktop and iPhone she was failing to receive messages on?

This will at least give us the user IDs and let us try to take a look on our servers (if you're using servers we control) to see what on earth happened.

@ara4n
Copy link
Member

ara4n commented Oct 24, 2020

Also, assuming you still have the message keys on your device(s), I strongly recommend manually exporting them as a backup. In the nearish future there should be a way to then separate export the keys for the rooms you share together so she can at least get the history of those back. (There are ugly workarounds to do this today if it's an emergency)

@vy-let
Copy link
Author

vy-let commented Oct 24, 2020

Thanks for your help! I sent logs from all three devices. The accounts are on a server I run; I can provide logs from there as well if you'd find them helpful.

There's no emergency to restore the old messages right now, as I can still see everything on my end.

@hermann-san
Copy link

@vy-let I think I had a similar problem today with the desktop-app. All my encrypted room lost it's ability to decrypt the messages after I've upgraded my Linux Mint from 19 to 20. I've opend my session on Android and Web, but the Desktop session didn't got verifiied. I've restarted my Desktop app and clicked on the message to request the verification of the session and this time it worked. I had to request session verification of few different messages (naybe I was to impatient) and the all messages got decrypted again. Problem solved for me.

@jakemoroni
Copy link

jakemoroni commented Oct 27, 2020

I've been experiencing this same issue but with the iOS app. Basically, everything will be working fine in a 1-to-1 chat, but then one party (person A) will suddenly lose the ability to decrypt any of the messages sent by the other party (person B). However, person B can still see all the messages sent by person A.

This doesn't just apply to message history either - even newly transmitted messages are unable to be decrypted by person A.

I submitted a "rage shake" bug report from the app, but I figured I'd bring it up here too since it's a pretty catastrophic failure mode. We're usually able to get it to recover, but I can't pinpoint on the exact mechanism. It's usually just a bunch of power cycles, force resets, app force kills, etc. Then eventually it will work again.

EDIT: @ara4n Let me know if I should file a bug for this, and if so, where. I'm not sure if it's an iOS app issue or a server issue. I'm running the latest Synapse, with a pretty much default config (but still using SQLite).

@manuroe
Copy link
Member

manuroe commented Oct 28, 2020

@jakemoroni. Thanks for your bug report. Can you ask the other party to submit a bug report as well, please?

@xaur
Copy link

xaur commented Nov 8, 2020

A bit off-topic to this issue but it would make such issues less bad if it was possible to recover from the loss of decryption keys if the other party is willing to cooperate. That means Alice re-sending lost messages to Bob.

@jryans jryans added P1 S-Critical Prevents work, causes data loss and/or has no workaround A-E2EE labels Nov 20, 2020
@larkly
Copy link

larkly commented Dec 10, 2020

Similar issue. Lost ability to decrypt e2e rooms on Linux desktop, Mobile and web app.

Debug logs submitted.

@jryans
Copy link
Collaborator

jryans commented Dec 14, 2020

@larkly Thanks for the debug logs. I am not so sure your issue is the same, but it will clutter this issue up if we work it out here. Please create a new issue and describe what has happened in your case.

@kittykat kittykat added the O-Occasional Affects or can be seen by some users regularly or most users rarely label Aug 2, 2021
@Palid
Copy link
Contributor

Palid commented Aug 2, 2021

@turt2live can that be related to indexedDB just wiping the keys?

@turt2live
Copy link
Member

Possibly; We introduced improved persistence and consistency checks at some point, but I can't remember if that was Winter 2020 or Winter 2019.

@Palid
Copy link
Contributor

Palid commented Aug 13, 2021

Related #18258

@novocaine novocaine added O-Uncommon Most users are unlikely to come across this or unexpected workflow X-Needs-Info This issue is blocked awaiting information from the reporter and removed O-Occasional Affects or can be seen by some users regularly or most users rarely labels Aug 25, 2021
@kittykat
Copy link
Contributor

I am going to close this issue for now as while we've not been able to confirm that it is resolved, the code base has changed to improve encryption/decryption and we have not had any new reports since last year.

If anyone else comes across a similar issue, please file a new issue against the platform that you are experiencing it on (web/desktop, Android or iOS) and submit a logs using rageshake as soon as possible (shake your mobile phone or type /rageshake into a new message on your web/desktop app).

If anyone feels that this issue should remain open, please feel welcome to reach out to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-E2EE O-Uncommon Most users are unlikely to come across this or unexpected workflow P1 S-Critical Prevents work, causes data loss and/or has no workaround T-Defect X-Needs-Info This issue is blocked awaiting information from the reporter
Projects
None yet
Development

No branches or pull requests