Migrating key backup to 4s fails

[MichaelErjemenko]

Steps to reproduce

1. Sign in with a new account via SSO at the Android-Client
2. Create a private room and send a message
3. Open the "Security & Privacy" settings, click on "Encrypted Messages Recovery" / German: "Wiederherstellung verschlüsselter Nachrichten", then select "Start Using Key Backup" / German: "Richte Schlüsselsicherung ein" and complete the setup process.
4. Sign out and sign in again with the android client.
5. After restoring the history in the settings ("Restore From Backup") all messages are decrypted and nothing indicates that there are problems. (The 4S was not setup with this process on purpose.)
6. Sign out
7. Sign in with the web-client
8. Click on Upgrade in the Encryption upgrade available dialog / modal. The Upgrade your encryption dialog opens
9. Click on Restore and enter your passphrase / recovery key.
   => The message is decrypted but the Upgrade your encryption dialog remains.
   The Security & Privacy page shows Thsi session inot backing up your keys, [...], Cross-signing is ready but keys are not backed up. and the session is not trusted.
10. Send a message.
    1.. Try to sign out
    => It is shown that this session is not backed up. So connect with the secure storage but this doesn't help. If you try to sign out it is shown again.

Images for the steps:

1-sign-in-android

2-1-create-private-room

2-2-send-message

3-1-set-up-key-backup

3-2-set-up-key-backup

3-3-set-up-key-backup

5-1-restore-from-backup

5-2-message-decrypted

7-sign-in-web

8-upgrade-encryption

9-1-upgrade-encryption

9-2-decrypted-messages-but-dialog-remains

9-3-not-backing-up-keys

9-4-unverified-session

10.1-1-sign-out

10.1-2-sign-out

Outcome

What did you expect?

After step 9: The messages should be decrypted.
At step 10: The session should be connected to the secret storage / key backup and no warning should be shown.

What happened instead?

After step 9: The message(s) are not decrypted.

Operating system

Windows

Browser information

Google Chrome 123.0.6312.124

URL for webapp

No response

Application version

Element Web v1.11.64, Android 1.6.14

Homeserver

Synapse v1.101.0

Will you send logs?

No

[richvdh]

To me, this feels like a bug in the Android client. I'm unconvinced that we should support this migration flow just to deal with the brokenness of another client. Will see what the rest of the team thinks.

[MichaelErjemenko]

Perhaps I don't know about some specifications or similar, but shouldn't the server ensure that such a situation cannot occur? I mean otherwise any client could just "break" any account by using key backups but not 4s. (While some other clients still would / could handle this situation.)
Furthermore, what is in the case that one come from a client (version) where key backups without 4s were supported and now just wants to use the web client. At the moment the user would just observ an unexpected behaviour (in the best case) and changes in the android client (or any other client) wouldn't help him/her.

[richvdh]

Perhaps I don't know about some specifications or similar, but shouldn't the server ensure that such a situation cannot occur? I mean otherwise any client could just "break" any account by using key backups but not 4s.

Possibly, though the scenario is allowed by the Matrix spec, even if Element-Web doesn't support it, so we'd need changes to the spec before we can enforce it on the server. Maybe that could be done, but it's a bunch of work nobody has time for right now.

Furthermore, what is in the case that one come from a client (version) where key backups without 4s were supported and now just wants to use the web client.

I don't really understand this question. If you're saying "Element-Web should fail gracefully in this situation", then I agree. I've opened #27455

[richvdh]

Per #27455, we intend (eventually) to remove the "upgrade your encryption" flow. This looks like a bug in the android client, so I suggest you open an issue in https://github.com/vector-im/element-android.