Replace the "Encryption" settings with a new settings tab

[richvdh]

Currently, the "Security & Privacy" settings tab has a very confusing set of options relating to encryption. As a result of this, the UX was revisited to ensure a straightforward UX when it comes to enabling key storage and setting up recovery, as well as make sure that EW and EX are consistent. The plan is as follows:

1. A new top-level menu item Encryption:
   1. The primary purpose of this is enabling/disabling the Key storage and setting up Recovery.
   2. Since the new designs use the term Recovery Key, the term Security Key needs to be replaced with Recovery Key throughout the UI.
   3. The secondary purpose is the Advanced section which contains other encryption-related settings or actions which are already supported on EW and which we want to keep long-term but which are only used rarely or used by power-users:
      1. Show session details - power users.
      2. Export/import keys manually - power users.
      3. Reset cryptographic identity (this should reset everything - e.g. cross-signing keys and key storage) - in case of compromise of user keys.
      4. Not sending messages to unverified devices/users - power users or very paranoid users.
2. As a result of the previous point, the existing Security & Privacy menu item should no longer contain the functionality that was moved to the Encryption menu item:
   1. Remove Encryption > Secure Backup section.
   2. Remove Encryption > Cross-signing section.
   3. Remove Encryption > Cryptography section.
   4. There is also a new design for the Security & Privacy menu item due to the above but not only - it contributes to the UX of this section in other ways.

There are also 2 adjacent pieces which greatly support having a better and more consistent UX to make the crypto "invisible" and support the rollout of the exclusion of insecure devices:

1. Updating the identity reset flow, so it no longer embeds the setup of the recovery.
2. As a consequence of the above - show a toast & a red dot next to the Encryption menu item when recovery is not set up.

The work is delivered in the following iterations (in the order of priority).

Tasks

Preview Give feedback

1. Enable key backup by default #28691
   T-Enhancement +1
2. Add Recovery section in the new user settings Encryption tab #28673
   T-Enhancement +1
3. Add Advanced section to the user settings encryption tab #28804
   T-Enhancement +1
4. Implement "reset cryptographic identity" flow in new Encryption settings #28977
   A-E2EE A-E2EE-Cross-Signing T-Feature +3
5. Add key storage section
6. Add key storage out of sync toast
7. Add key backup creation toast
8. Remove Security & Privacy > Cross-signing; Security & Privacy > Cryptography.
9. Apply new design to the remainder of the Security & Privacy.

Original report

Key Backup section in User Settings is very confusing

The current UI of EW for enabling key storage and setting up recovery, is very confusing. A list of example problems:

• It implies that this is only needed "in case you lose access to your sessions". This is incorrect; it is needed so that you can get access to the messages on any new device.
• It is unclear what the "Your keys will be secured with a unique Security Key" means. What is this "security key"? Perhaps its talking about the 4S "recovery key" (cf UX: is it a Security Key or a Recovery Key element-meta#2394)?
• The buttons make no sense at all:
  • Restore from backup" wedges your entire UI (Restore keys (from secure online backup) in background rather than foreground #20694). It doesn't seem like a useful operation anyway.
  • The goal of the "Reset" button is unclear (it's probably meant to just reset the backup, but also ends up resetting 4S, and makes a mess of it).
  • The "Delete" button only deletes the most recent key backup. Its behaviour is very confusing
• The UI does not make clear whether the backup is signed with a trusted key. On the contrary, it says: "This session is not backing up your keys, but you do have an existing backup you can restore from and add to going forward." Which is incorrect.
• In the "Advanced" section:
  • What are the possible values for each of the first four entries? What do they mean?
  • Why is information about "Secret Storage" listed here? 4S is useful for things other than key backup so it's an odd place to hide info about it.

[daniellekirkwood]

I'm going to be asking the web team for sizing estimate of this one next week :)

[daniellekirkwood]

We think this is mostly UI changes and are already wrapped in to our definition of done for our Settings epic work... @dbkr would you mind taking a closer look and confirming that? then maybe also add a effort label?

[daniellekirkwood]

For internal element folks only this link should show you the new version of this screen. @richvdh / @pmaier1 / @giomfo would you confirm that the items in this issue would be addressed if we implemented the designs linked here?

[mxandreas]

The designs are now there and the EW team is also working on them, do we need to keep this ticket still open?

[richvdh]

The designs are now there and the EW team is also working on them, do we need to keep this ticket still open?

Yes please, AIUI this is the issue tracking that work.

[richvdh]

Have edited the description a bit to make it clear what's in scope here

[richvdh]

We debated at length whether the Change Recovery Key (figma) button should reset key backup.

On the one hand: the "I forgot my recovery key" flow does reset key backup (even if you already have a working backup), and it would be good to be consistent with that. It might also help avoid certain failure modes like #27806 where we create a new 4S which is missing some of the secrets.

On the other hand:

• EX does not reset key backup in the equivalent flow, and consistency is important.
• It is not necessarily the case that we want to do the same thing for "I forgot my recovery key so I can't set up this client" and "I have a working client but want to reset my key recovery key".
• If we are lacking any of the secrets, we won't even show a "change recovery key" button (instead we will force the user to enter their existing recovery key or reset: figma)
• Resetting backup comes with a whole bunch of other pitfalls (Element-R | Resetting key backup takes a long time; and blocks the whole application #26892, Megolm Backup | Client should always have a local copy of all their megolm keys to limit the possibility of key loss element-meta#2446).

In conclusion: we will not reset key backup in this situation if we already have a working key backup decryption key.

[mxandreas]

In conclusion: we will not reset key backup in this situation if we already have a working key backup decryption key.

Meaning that if you have verified device, but you have forgotten your recovery key, then you can generate a new one without losing access to your historic messages?

If so, I was just yesterday writing guidelines for how to make sure you have recovery key (for the purpose of rolling out invisible crypto) and came across this scenario as something very helpful for the user.

[richvdh]

In conclusion: we will not reset key backup in this situation if we already have a working key backup decryption key.

Meaning that if you have verified device, but you have forgotten your recovery key, then you can generate a new one without losing access to your historic messages?

Yes.

[mxandreas]

For the record, we had a sync yesterday with @andybalaam @florianduros @dbkr and @americanrefugee and confirmed that we want to include in this work some adjacent parts, since it will greatly improve the UX and consistency with EX:

• Update the identity reset flow so that it no longer embeds the setup of the recovery, for the sake of consistency with EX as well as this being the desired eventual design. It also helps to get rid of the old UX.
• As a consequence of the former, implement the toast that reminds user to set up recovery, as well as show the red dot next to the Encryption menu item when recovery is not set up.

We also agreed to revisit this, in case the related effort seems to be much higher than anticipated.