Consistently applied safeguard against unexpected encryption drop

Nobody has claimed this yet.

I experienced my messages being sent encrypted unexpectedly on one client.

This is probably the worst experience you can have in a supposedly secure messenger- you expect security and allow yourself to speak candidly, yet you are exposed. The conversation was harmless and nothing happened, however at that moment I was extremely grateful I was not discussion something sensitive, or something that could be understood to be sensitive by third parties.

I [reported the bug](https://github.com/vector-im/element-web/issues/20865#issuecomment-1028759381), and was helpfully [pointed to an existing issue](https://github.com/vector-im/element-meta/issues/69) by element engineers.

I asked whether a safeguard could be put in place to prevent unexpected encryption drop even when client bugs occur. [It was pointed out to me](https://github.com/vector-im/element-web/issues/20865#issuecomment-1027936835) that the web and desktop versions contain such a safeguard, in that a room is locked from sending any unencrypted message if there already is at least one encrypted message in the room. That was quite reassuring.

It [was pointed out by an android client engineer](https://github.com/vector-im/element-android/issues/5068#issuecomment-1028904148) that the android client also has such a safeguard, but it failed to work in this case.

Therefore, I asked whether the [safeguarding against unexpected encryption drop](https://github.com/vector-im/element-web/issues/20865#issuecomment-1027955112) might be something that could be defined in a centralized way, since an issue in a single client degrades security for the entire element ecosystem, and was pointed to [make a "MUST"-style spec request](https://github.com/vector-im/element-web/issues/20865#issuecomment-1027978827).

I am unfamiliar with the correct way to specify behavior that all element-branded clients, so any input that will bring the phrasing closer to something that could actually go into the spec, and help for finding the correct place, is appreciated. But I hope the high-level meaning of the proposal is clear.

_Element-branded clients MUST confirm from three different information sources that an unencrypted message was indeed intended to be sent unencrypted. They MUST prevent immediate sending of the message, and can either prevent sending altogether or ask for confirmation. Information sources, of which three must be checked, can be: Room encryption state, encrypted messages present in the room, room room type set to private.

Element-branded clients MUST make every possible effort to ensure that the information relied upon to make the determination that a message may be sent unencrypted is in a fresh state and not stale.

Element-branded clients MUST determine whether messages sent in a room will be sent encrypted or unencrypted before an attempt is made by the user to send a message. Further, Element-branded clients MUST make it obvious to the user whether a composed message is going to be sent encrypted or unencrypted, through use of an appropriate GUI element, such as an open/closed lock icon of obviously different graphics and colors in the send button itself, or something equivalently obvious.

Element-branded clients MUST NOT under any circumstances send a message to a room with a different encryption state than the GUI-element announced, as this is the crucial point of trust for the user. Ideally, the same code procedure that updates the icon state should set the encrypted/unencrypted determination in a protected variable which is then read by the sending procedure before sending._

This suggestion was made in the hopes that it will be helpful to create trust of users in Element, and to enable the use of Element in situations where lives depend on the maintenance of secrecy (I am not sure if that is the case without my proposal, but with it, it likely would be).

Please note I consider the last part of the proposal the most important one. If I can be sure that the message will never be unencrypted with the lock icon on, then it is not so terrible if there is a room state bug.

Please have a look at Signal's handling of the differentiation of sending SMS or Signal messages for an example of the last part of my proposal that I would consider done well, even though even with Signal the graphics could look more obviously different.

Any questions welcome.

I am really passionate about Element because it is enabling me to communicate with my Dad a lot in a secure way. He is 80 and is a longtime computer user but has no smartphone. With Element, he is no longer shut out of modern communication- he can chat with me and reach me at any time and see his grandchildren play on video. We can also have true heart-to-heart conversations without worrying about anyone eavesdropping, which is incredibly freeing. I can truly say that Element has made my connection to my father so much better.

The issue names no specification section, files, or tests. Start by reviewing the linked Element, Element Android, and element-meta discussions, then locate the relevant Matrix client-behavior section. Done would require an agreed MUST-level requirement covering the proposed safeguards and an identified place in the specification.

Written by the indexing model from the issue text.