Consistently applied safeguard against unexpected encryption drop

[capocasa]

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, and was helpfully pointed to an existing issue 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 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 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 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.

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.

[turt2live]

The spirit of this issue is very valid, though at the spec level we work on Matrix rather than any specific client: the resulting proposal wouldn't mention or use Element as its target, instead affecting all clients (including Element).

[capocasa]

Thank you for your reply @turt2live!

I understand! Perhaps I went one step too deep in- I would guess it might be overly heavy-handed to require that all matrix clients must adhere to a certain user experience with regards to encryption, as I could for example easily imagine using the matrix protocol for communication between machines, which do not require UX safeguarding. I would further easily imagine myself using a matrix client I know to be marginally secure, yet enjoyable because of the interesting graphics. Such a client would not benefit from being required to use a certain UI that does not fit its use case.

The reason I included "element branded" is because the brand is where the promise to the end user is made, so that is, so to speak, the "trust interface" between a non-technical end-user and various experts.

I suppose one solution might be to be more general and specify that "Clients that promise 'Private Communication' or 'End-To-End Encryption' to end users" should implement mentioned safeguards, perhaps further specifiying that in this case, End-To-End encryption must be enabled by default wherever there might be an expectation of privacy. However it would of course also be possible to limit such safeguarding to the element client and leave it up to each individual matrix client to decide for themselves how far they would like to go.

I am unfamiliar though where the appropriate place would be to make my proposal seperately applying to the entire element ecosystem but not other clients.

Edit: Feature request issue regarding this added to element meta.

[uhoreg]

FWIW, I'm working on an improved end-to-end encryption implementation guide, and part of it is some improved wording on how to handle changes to the room encryption setting. It's unclear how much should actually be in the spec, but improving the guide is a step forward.