If you log out & in without setting up E2EE, you get a surprising "Unable to verify this device" warning

[ara4n]

Steps to reproduce

1. Sign up
2. Log in
3. Immediately log out, before setting up 4S (presumably)
4. Log back in:

5. Feel angry and confused.

See https://blog.koehntopp.info/2024/02/13/the-matrix-trashfire.html

Outcome

What did you expect?

If the user has no E2EE set up, then try to set it up rather than warning about being able to verify.

Operating system

No response

Browser information

No response

URL for webapp

No response

Application version

1.11.58

Homeserver

No response

Will you send logs?

No

[BillCarsonFr]

Maybe we can lower a bit the tone of the copy. But you will have to reset the cross signing keys, this will require re-authentication.

What is happening:

When you register your account you will bootstrap cross-signing. So your identity keys will be created on the device and then the public parts are uploaded to the server (/_matrix/client/v3/keys/device_signing/upload)

After that you logout, without setting up recovery, and you have no other devices. That means that the private keys of your identity are lost forever.

Now you log in again. The client sees that you already have published an identity.

Normally you have to verify a new login by signing it using the identity keys (this is designed to be used by other people to trust this device and decide to send message keys or not).

In this case you can't verify. The private keys are lost.

Uploading cross-signing keys is a call that requires re-authentication, so it needs user interaction (some server might have a grace period depending on the auth type).

Some ideas

• On logout: Explain that it will happen if you don't set up recovery?
• Change the copy of this dialog a bit to be less scary, but still explain that history is lost
• Maybe in the same vein of MSC3967 we could allow to reset without UIA if no devices/4S on the account

An other option could be to delay the bootstraping of cross-signing keys when you setup recovery. There are some downsides: If we do so, it will prevent us to deny sending of keys to devices not signed by their owner (which is a better default security than sending to all, particularly if the identity is pinned) As a consequence we could ask users to setup recovery on onboarding, but it's a complex flow that will be presented to users on the first time they see element. It's not very user friendly, given also that at this point you haven't used the product and have no history to save anyhow. (Also "server side" recovery is optional)