Element X: require acknowledgement to send to a verified user if their identity changed or a device is unverified

[andybalaam]

The purpose of this issue is to prevent people who have explicitly verified someone accidentally sending messages. We need to cover 2 cases:

1. A verified person becomes unverified
2. A verified person has a new unsigned device

in both cases, when I try to send a message, sending should fail, and an error message should be displayed.

So we expect to change the message sending code (in Rust) to throw an error in these cases, and we expect the UI to display the error and offer options.

The options in case 1 would be "withdraw verification" (mark the person as unverified and send the message) or "cancel sending" (discard the message). Note that on EX there is no "Re-verify" yet.

The options in case 2 would be "send anyway" (send the message to the unverified device and remember that we don't need to ask again for that device) or "cancel sending" (discard the message).

This will require changes in

• matrix-rust-sdk (Handled by crypto team):
  • • Track whether we've ever verified another user, and later signal when that user becomes unverified for any reason matrix-org/matrix-rust-sdk#1129
  • • Element X: Return an error when sharing a room key to a verified user, who has an unverified device  matrix-org/matrix-rust-sdk#3792
  • • Element X: Return an error when sharing a room key to a verified user, who is no longer verified matrix-org/matrix-rust-sdk#3793
• element-x-android (Handled by EX team)
• element-x-ios (Handled by EX team)

[richvdh]

matrix-org/matrix-rust-sdk#1129 is part of this, I think.

[mxandreas]

I am noting down a few questions for the session on Wed:

The options in case 1 would be "withdraw verification" (mark the person as unverified and send the message) or "cancel sending" (discard the message). Note that on EX there is no "Re-verify" yet.

1. If you do want to keep sending the messages (now or later), the only option is to "withdraw the verification", correct?
2. How to make sense of the state once the verification has been withdrawn? Will it correspond to a pinned/TOFU identity (e.g. we're already able currently to detect changes to it), or can it be then changed any time without anyone noticing?

The options in case 2 would be "send anyway" (send the message to the unverified device and remember that we don't need to ask again for that device) or "cancel sending" (discard the message).

1. I assume that if more than one device is untrusted, we handle them as a group, e.g. send to all or nothing and if send, then remember to not ask again for any of these devices.
2. Where do we remember the devices - is that something that is captured on the server or locally on the client side?

[americanrefugee]

Here are the current designs for:

1. A previously verified user reset their crypto identity
2. A regular user (NOT previously verified) reset their crypto identify

The first design covers case 1. We can probably modify the second design to cover case 2.

Comments/questions:

• My understanding was that in the future it will not be possible to send or receive messages with an unverified device. Is this still true? If so, then case 2 is only a temporary thing?
• The described behavior of "sending should fail" does not reflect the concept @pmaier1 @andybalaam and I came up with. In the design, the user can't even try sending a message until without withdrawing verification or verifying the user again. Until then, the composer is visible but disabled.

[andybalaam]

My understanding was that in the future it will not be possible to send or receive messages with an unverified device. Is this still true? If so, then case 2 is only a temporary thing?

Yes, this is temporary to make Element X ready now.

The described behavior of "sending should fail" does not reflect the concept @pmaier1 @andybalaam and I came up with. In the design, the user can't even try sending a message until without withdrawing verification or verifying the user again. Until then, the composer is visible but disabled.

Correct: this is temporary too, because in future the user should not be able to send. There is an edge case though, where the UI did not update quickly enough and the user sent the message, so this error case could still be used in rare cases.

[americanrefugee]

Here are the designs iOS and Android.

[manuroe]

I am closing this request in favor of https://github.com/element-hq/element-internal/issues/614 so that we can follow the EX team process with epic -> user stories -> tech tasks. It makes things easier for us to roll out the plan and to guarantee we do not forget a task.