“Never send encrypted messages to unverified sessions from this session” is dangerous

## Problem

We are two people, I am the sender and they are the receiver. We have each one client, and one single chat to each other. E2E is turned on by default, but we haven’t verified each other because it’s opt-in and we haven’t made use of it yet. This is as average as it can get.

One day, the receiver told me that they couldn’t read my new messages anymore. Instead, for my new messages they saw

> Waiting for the message, this may take a while

We both couldn’t remember having changed anything. I could still read their messages, but they not mine. So I was completely unable to talk to them. Of course we have a backup conversation medium. But in a world where Matrix strives to be the primary conversation medium, this would be very bad. This is the first bad sign.

The error message was not actionable. It essentially said “just wait”. So, an error message which tells you nothing. This is the second bad sign.

We found this issue in Element for Android https://github.com/vector-im/element-android/issues/1721. But they seem to be unclear about what the issue is. Assuming it has something to do with Element for Android, the receiver tried different clients and different platforms but nothing helped. They tried re-requesting the keys, but it didn't help either. Remember, this is all while our primary conversation medium was broken.

Then they turned on developer mode and saw a more specific error message

> Unable to decrypt: The sender's device has not sent us the keys for this message

So, two different error messages, where the useful one is only available to the advanced user. This is the third bad sign.

We found a lot of issues on it, which all talked about different things. Finally we found https://github.com/vector-im/element-web/issues/15112#issuecomment-688520710 which mentioned the sender’s setting

“Never send encrypted messages to unverified sessions from this session”

I looked in my settings and indeed it was turned on. I couldn’t remember if I had changed it or not. Anyways, I turned it off and the receiver could finally read my new messages from this point on after weeks of being bound to a backup conversation medium. Yay!?

But the previously unreadable messages kept being unreadable to them. They could re-request the keys but I couldn't re-send them. So, flipping one innocent switch I was able to send messages that could never been read ever of without any indication on my side whatsoever! This is the fourth bad sign.

Now, from a functional standpoint this may all be expected behavior. But from a user point of view being locked out to talking to someone so easily is B-A-D. If Matrix strives to be the primary conversation medium for the masses, this is a N-O G-O.

## Solution

I propose, in order of importance:

1. If the sender has the “Never send encrypted messages to unverified sessions from this session” setting turned on they should not be able to send messages to an unverified chat. There should be an error when trying to start a new unverified chat or trying to write a message in an existing unverified chat. I should not have been able to send messages that the recipient could never read!

2. The “Never send encrypted messages to unverified sessions from this session” setting should be explained better. It should tell the sender that turning it on breaks any unverified chat, ideally providing a list with all existing chats that will be rendered useless. For a setting that completely locks you out from talking to someone it should not be so easy to switch it on that I don’t even remember!

3. The error message in the receiver's chat should be improved. It should show an actionable error message instead of a non-actionable “wait a bit”. Note, if 1) is implemented the error message would only ever really matter in group chats since sending to an unverified single person would be prevented in the first place.

4. Remove the ability for the receiver to re-request the keys. This is useless if the sender can never re-send the keys. I don’t know if the encryption algorithm technically allows for re-sending the keys. If so, then instead of the receiver re-requesting the keys I’d argue for a way for the sender to re-send the keys. To the sender it could look like resending the message when in fact under the hood it resends only the keys since the message has already been sent. The average user should not need to know about the underlying encryption mechanism!

5. Name the setting “Allow only verified sessions to read your messages”, both for the global for-all-rooms setting and the per-room setting, across all clients. Currently, the name of the setting is a hot mess, differing between for-all-rooms or per-room and across clients.

###### Element Web:

- "Never send encrypted messages to unverified sessions from this session" (global, Settings -> Security & Privacy)

Complex negative statement, leaks abstraction about encryption, useless "from this session" since it's implied just like on iOS

- "Never send encrypted messages to unverified sessions in this room from this session" (per-room, Room Settings -> Security & Privacy).

Complex negative statement, leaks abstraction about encryption, useless "from this session" since it's implied just like on iOS

###### Element iOS

- "Never send messages to untrusted sessions" (global, Settings -> Security)

Complex negative statement

- “Encrypt to verified sessions only” (per-room, Room Details -> Settings)

Just plain wrong. It does encrypt even to unverified sessions, just that they can not decrypt it because they lack the decryption keys. It suggest that this setting makes you less secure, when in fact it makes you more secure. See https://github.com/syphon-org/syphon/issues/300 why this incorrectness has real impact in confusing users.

###### Android

I didn't check Android, though I’d be surprised if it didn't add to the inconsistencies.

These are all different wordings for the same setting! This does only further confuse users. Some leak abstractions about the encryption, some use a more complex negative statement instead of a simpler positive one, some are even plain wrong! Instead “Allow only verified sessions to read your messages” a simpler positive statement that doesn't leak abstractions about encryption (credits: @ereio in https://github.com/syphon-org/syphon/issues/300#issuecomment-887603805). It assumes the knowledge that it applies only if encryption is turned on but this can be easily guaranteed by the location of the setting in a "Encryption" section or by a short description.

#### Additional context
This issue affects all clients, Web, iOS and Android. I filled this issue on Web, assuming it’s the best place for tracking it.

Sender:
Element for iOS 1.4.5

Receiver:
Element for Android 1.1.14

Start by reviewing the cited Element Web, iOS, and Android security-setting wording and the linked Element Android decryption issue. Define consistent, actionable behavior and terminology across clients, including what happens for unverified chats and previously unreadable messages; completion requires agreement on the cross-client scope and verified wording.

Written by the indexing model from the issue text.