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

[vwkd]

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 element-hq/element-android#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 element-hq/element-web#15112 (comment) 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 syphon-org/syphon#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 syphon-org/syphon#300 (comment)). 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

[HarHarLinks]

This issue applies for web+android+ios.
I think the wording of "wait a bit" is an issue of android, I remember web telling the receiving user something like "the sender has encrypted this in a way so you can't decrypt it".

I have had a similar "problem", but in a group chat where one participant wants to use said setting but has not (yet) verified every participant. What do you suggest happens in group chats?

[vwkd]

Good point, I didn’t think about groups yet.

The case where no group members are verified is easy: prevent the sender from sending, since nobody will ever be able to read the message. The case where all are verified is easy as well: allow sending. The case where some are verified and some are not probably makes sense to be allowed. But the sender should be clearly aware of the fact that not everyone will be able to read their messages. Maybe show a warning header on the top of the chat, something along the lines of

Warning: user1, user2, and 42 more unverified contacts won't be able to read your messages. Verify them or turn of “[setting name]” in settings.

---

Thinking more about the error message for the receiver. The "wait a bit" is obviously bad. The developer mode error message is not useful to the user either, because it says WHAT is going on (decryption keys missing), but not WHY. How about something along the lines of

The sender only allows verified contacts to read their messages. Verify with the sender to read their next messages.

Or if the sender can re-send the keys (point 4. in original post), then

The sender only allows verified contacts to read their messages. Verify with the sender to read this message.

(emphasis just to clarify difference)

[HarHarLinks]

The sender only allows verified contacts to read their messages.

Question is, can the receiver actually know this for certain? I'm not 100% about the technicals here, but I can imagine there may be other cases. The error message should not make (too great) assumptions. Nevertheless it is probably OK to suggest verifying (unless the receiver already is).

Also the error message should really be consistent between platforms... which is sometimes a general problem for element.

[uhoreg]

When you have the "Never send encrypted messages to unverified sessions from this session" and you send an encrypted message, your client is supposed to send a message to unverified sessions telling them that they should not expect to receive the key because they are unverified, and the recipient's client should adjust their message to tell the user the reason why the message is not decryptable. But I don't know if the Android client implements that part yet.

Another thing that could be done is to display a warning to the user if there are unverified devices, that some devices will not be able to decrypt the message.

We are planning on improving the display of undecryptable messages in general, so hopefully this will be improved.

[karolyi]

Confirming that this is indeed dangerous.

I tried to send messages to a recipient that has all her sessions synced across her devices (assumingly, by looking at her sessions, she has no unverified ones), yet couldn't decrypt my messages because of this setting. Is it because I have to verify her once again, after she has synced sessions that are secure (verified) across her devices?

Instead of my messages, she has gotten this:

This should be improved ASAP so subscribing to this issue. It is very unclear what this option means, and what its default setting should be, lacking proper documentation.

[bkil]

I bump into newbies who fall over this hoop almost every month. Interestingly, in some of the cases, I can read their first message, but not further ones. Perhaps that's the point in time when they find this cool option that sounds so fantastic, advanced, mystic and security-boosting to them that they haven't seen on Facebook or WhatsApp before?

Some of them then ask me to click verify and just blindly accept the trust relationship as a workaround for this issue, but then verification wouldn't make sense, would it (other than LARP'ing)?

[FSG-Cat]

I fail to see why this option gets so much flak when its clearly a user education issue not a technology issue. The option exists for higher security users clearly. Now the communication around this option could be done better but the option is not a danger. The option is literally the oposite.

[v411e]

What about making this a "per room" setting?

For now it is not possible to use this while using bots/bridges, because in most cases it is not possible to verify against yout bridge/bot and they would not be able to bridge your messages anymore.

[t3chguy]

@v411e it already is.

[v411e]

Awesome, thanks for the hint ^^

Although it would be even cooler if it'd sync across sessions. Now I need to turn that on on every session and in every room where I want it to be activated