EW still prompts you to "Set up Secure Backup" and "Enter a security phrase"

[richvdh]

We're phasing out the term "security phrase", and indeed the ability to choose your own secret (cf element-hq/element-meta#2394). Also, this is about setting up recovery, not "secure backup".

Steps to reproduce

1. Register a new account
2. Create a new room
3. Observe "Set up Recovery" toast
4. Click "Continue" on the toast

[andybalaam]

Yes, this dialog should go away, and the toast from #29232 should open Settings -> Encryption instead of a separate dialog.

[uhoreg]

This dialog comes from CreateSecretStorageDialog, which is called by accessSecretStorage in SecurityManager.ts. So I should also update CreateSecretStorageDialog to use the new designs (probably by replacing the contents of the dialog with the components from the Encryption settings), in case it gets called in some other way.

@mxandreas do you still want the toast to open Settings -> Encryption, or should I have it open the dialog with the new designs?

[uhoreg]

Oh, CreateSecretStorageDialog is a fun file. I may take this opportunity to do some refactoring...

[mxandreas]

do you still want the toast to open Settings -> Encryption, or should I have it open the dialog with the new designs?

Open Settings -> Encryption. Because then it is consistent with EX. But also, because (I assume) it would not require anything else to be done about the legacy modals (besides just removing the code code).

So I should also update CreateSecretStorageDialog to use the new designs (probably by replacing the contents of the dialog with the components from the Encryption settings), in case it gets called in some other way.

I do not think so, because there should not be any other way to call it (because we decoupled setting up recovery from reset).

[uhoreg]

I do not think so, because there should not be any other way to call it (because we decoupled setting up recovery from reset).

It's called by the accessSecretStorage function, which is called in several places (basically, any time Element wants to do anything with Secret Storage). I'd like to say that the old design shouldn't show up, but the only way to make sure is to replace it. I also don't want to keep CreateSecretStorageDialog around if it isn't being used, because it contains logic that makes future maintenance harder.

[uhoreg]

I've done a survey of the places where accessSecretStorage is called. Some of them call it when Secret Storage should already be set up, so shouldn't call CreateSecretStorageDialog. Some of them call it in order to get accessSecretStorage to create Secret Storage/key backup/cross-signing keys. Most of those can be converted to bringing the user to the Encryption settings tab instead. But two places that are problematic are:

• NewRecoveryMethodDialog, calling RestoreKeyBackupDialog. To trigger this:
  1. open two instances of Element, logged into the same account.
  2. In instance 1, set up key backup and recovery.
  3. In instance 2, turn off key backup and then turn it back on.
  4. In instance 1, in an encrypted room, type /discardsession, and then send a message.
  5. After a bit (Element will try to upload the key to backup, and then fail), a dialog will pop up saying that there is a "New Recovery Method"
     
  6. Click on "Set Up Secure Messages" button, which will pop up a new dialog behind(!) the "New Recovery Method" dialog
  7. Click on the dialog to bring it to the front
  8. Click on "set up new recovery options" at the bottom, which will bring up the "Set up Secure Backup" dialog
     Here, we could bring the user to the Encryption settings page, but in order to create a new backup, the user needs to turn off Key storage, and then turn it on again, which isn't very intuitive. Moreover, that page just shows that Key storage is enabled, but doesn't give any indication that the client isn't able to use it. I think that we may still want to bring the user to the Encryption settings page, but improve that page to better handle the case where Key storage (and/or Recovery) exists, but the client isn't using it (e.g. show the correct state, and allow the user to enter their key).
     (Note that if in step 3, you also turn on Recovery, then the "New Recovery Method" will bring you to a different dialog, that asks you to enter your recovery key, but doesn't give the option of resetting)
• verification.ts has a function for verifying another user verifyUser that uses accessSecretStorage to create the cross-signing keys if they don't exist. I'm not sure if it's possible, nowadays, to reach that state without having cross-signing keys, so we might be able to just get rid of that bit?