[Epic] ER-268: Key storage out of sync UX upgrade

[mxandreas]

Problem

It has been discovered that the current UI/designs are not covering all scenarios and offer the best guidance for the users to cure the issue when user is missing some crypto secrets locally and/or in the storage. Some examples are:

• when secrets are missing only in the storage, the user can fix it by changing their recovery key if they have forgotten it
• when secrets are missing both in the storage and locally, there is no point to ask for the recovery key as it won't fix the situation.

The following diagram documents the scenarios and the corresponding responses:

The UI/designs have been updated accordingly and the goal of this epic to make the apps, both mobile & web, to behave accordingly:

• iOS & Android | Web

TODO: Outline user stories to reflect the desired behavior for tracking implementation and testing.

---

• Web:
  • [ ] https://github.com/element-hq/element-web/issues/30438
  • [ ] https://github.com/element-hq/element-web/issues/30622
• [ ] EX Android
• [ ] EX iOS

[andybalaam]

@richvdh will check this against EW and EX and see what the delta is from current behaviour.

[richvdh]

I have updated https://github.com/element-hq/element-web/issues/30438 to reflect the work to be done in EW. Figuring this out for EX is significantly more difficult.

[uhoreg]

The different cases are:

• keys missing both locally and in 4S (incl. case where there is no 4S): needs reset
• keys missing locally, but present in 4S: needs reset if user has forgotten their 4S key, otherwise can fetch from 4S
• keys missing from 4S but present locally: needs to change recovery key if the user has forgotten their 4S key, but doesn't need reset
• keys present locally and in 4S: everything fine (hope that the user has their 4S key, but we have no reason to ask them)

If it is only key backup that needs resetting, we can silently do the reset when we prompt the user to enter their recovery key, or when the user changes their recovery key because they've forgotten it.

If the cross-signing key needs resetting, we should show a notice, so that when other people get notified of the identity change, the user can confirm that it was something they did. If the keys are missing both locally and in 4S, we can show the notice right away (e.g. in the toast). If the key is missing locally but present in 4S, we can show the normal toast and prompt the user to enter their recovery key, but if the user indicates that they have forgotten their recovery key, then show the notice.

[mxandreas]

The different cases are:

@uhoreg I'd like to update the flowchart accordingly, if there is anything to be updated. We can do that also together next week.

Edit: I have checked and the cases you listed, and the behaviour matches what we already had on the flow chart. If you see any differences, please point it out.

[uhoreg]

Some differences between the flow chart and what I implemented in Web:

• if the backup key is missing locally and from 4S, we don't need to notify the user that they need to reset. We ask the user to enter their recovery key, and silently create a new backup, and store the key in 4S. If they don't have their recovery key, they need to reset their recovery key. (If a cross-signing key is missing locally and from 4S, rather than the backup key, we do prompt the user to reset, rather than silently creating a new identity.)
• I have not yet implemented the "Is everything now OK" -- No -> "Sorry but we could not fix your issue. You still need to reset." logic.

I think that everything else matches what I've implemented.

[mxandreas]

We ask the user to enter their recovery key, and silently create a new backup, and store the key in 4S.

I think this is fine eventually, but I wonder if it causes more problems at this moment when we do not yet have https://github.com/element-hq/element-meta/issues/2865 ?

For example,

Starting point: working backup key on device B, no backup key on device A and 4S.

1. Device A detects it does not have backup key and 4S also does not have it.
2. User enters their recovery key and new backup is created on device A, backup key get stored in 4S.
3. But now backup on device B stops working because device B still has the old backup key. Also, no "Key storage out of sync" toast is shown (to get the new backup key from 4S), because device B still has the backup key, it is just wrong/old.

[mxandreas]

As per our discussion today, I have updated the flow diagram to also include the special response for fixing a missing or wrong backup decryption key. In such a case, we still need the user to enter their recovery key, but the response is specific (e.g. not just syncing a secret):

1. Create new backup.
2. Put the new backup key to 4S.
3. Push new backup key to other devices.

@uhoreg please double check the flow diagram so I did not miss anything.