search

element-hq / element-meta

Shared/meta documentation and project artefacts for Element clients
75 stars 12 forks source link

Expected UTDs after resetting your identity #2610

Open pmaier1 opened 2 weeks ago

pmaier1 commented 2 weeks ago

The following was tested on EXI 1.9.3. I expect to see similar behavior on Android and Web, though.

Steps to reproduce

  1. Sign-in to a new device
  2. During the FTUE process, decide to reset your identity
  3. Complete the process and sync

Expected outcome After the identity reset, existing message keys in the key storage are lost. For that reason, it is expected that your (encrypted) message history will be UTD. These UTD messages should not be a) displayed to the user b) counted in the UTD reporting

There is an adjacent scenario, where, after the identity reset, the user would re-verify another device that was still logged in and holds some message keys. This device would then upload the message keys to the new key storage which would allow the new device to actually decrypt (parts of?) the message history.

Actual outcome All encrypted rooms show your entire message history as UTD (unless the message keys were uploaded by another device as described above).

@mxandreas

andybalaam commented 1 week ago

@mxandreas : this is a valid concern, but we are not likely to work on it immediately.

davidegirardi commented 1 week ago

These UTD messages should not be a) displayed to the user ...

I think the messages should not just disappear. We should show something explaining that encrypted history before this moment is not available because you reset your crypto identity.

pmaier1 commented 1 week ago

As you've moved this to unprioritised, I just want to emphasize that I expect a huge fraction of users moving to EX will reset their identity along that way. They will all see UTDs everywhere and will report them to Posthog.

If you set up WhatsApp or others from scratch without backup, all your rooms will be empty as well. A general banner telling you that history is unavailable might be a good idea, though.