After we have an initial version of OTR working, we need to test, discuss and potentially enhance/change the behavior of the "require encryption" preference. Also, we need to decide about the default setting. For example, the old Tor Messenger had it enabled by default.

With this pref enabled, unencrypted messages are not shown. This might be confusing, if a buddy isn't configured for encryption.

• Not showing messages at all (without even notifying the user) doesn't seem like a great experience.
• For Thunderbird's expected users I suspect that "require encryption" is not the correct default, probably "opportunistic encryption" is.

Yes, I agree with the default (don't require by default).

I haven't played much yet with the pref set to "required", we should get some testing, experience and feedback.

Since libotr just landed, I think we should focus on the outstanding OTR bugs.
Patrick, as I'm not completely acquainted with the message section, would you be able to take care of this?

I agree what discussed before:

• Don't require encryption by default
• If "required" is enabled, send a notification in the chat to let the user know, instead of simple not showing anything.

I don't think I'll have time to look at this soon, sorry.

I wonder if it might make sense to show the messages but have some sort of icon or something next to them that says "hey you got this message but it wasn't encrypted and might have been tampered with".

All right, let's tackle this.
Right now we have a menulist under Connection Security in an xmpp account with 3 options:

• Require encryption
• Use encryption if available
• Allow sending the password unencrypted.

We also have a series of checkboxes in the e2e encryption tab of a chat account with this options which is unchecked by default:

• Require end-to-end encryption for one-to-one conversations.

Are those options related?
What's the different between them?

(In reply to Alessandro Castellani (:aleca) from comment #5)

Are those options related?
What's the different between them?

No, unrelated.

Alice <-> Alice's XMPP server <-> Bob's XMPP server <-> Bob

The connection security only affects the connection between Alice and her XMPP server (the server that hosts's Alice's XMPP account). It doesn't affect anything that happens behind it. The connection between both XMPP servers might be unencrypted. And Bob might use no connection security when connecting to Bob's XMPP server.

Your own XMPP server is the one that wants to see your password. So if you don't have connection security here, your account password will be sent clearly readable to everyone who can look at the wire between you and your server.

End-to-End encryption (e2ee) covers the whole distance from Alice to Bob.

Without e2ee, the XMPP servers (the people controlling the machine) along the route can read the messages that you're sending.

With e2ee, the XMPP servers only see ciphertext.

If you require end-to-end encryption, it means, only allow exchanging ciphertext, that is encrypted according to the OTR encryption mechanism. If Alice requires e2ee, but Bob's client doesn't support OTR, then Thunderbird will not allow unencrypted message to go out, and Alice can not send any message to Bob.

[deleted - accidental duplicate comment]

Nice, that makes sense, thanks for the explanation.
So, which section should we improve here? Is mostly a matter of description to improve this area and let the user know of this behaviour, or is there something else I'm missing?

I don't remember what happens if the pref is on, on one side only. I suggest to test the behavior, and decide if it's acceptable, or if additional notifications seem necessary.

Once we have checked and potentially adjusted the behavior, it could be considered to improve the wording in the e2ee chat prefs.

All right, I tested this.
If a user has the Require end-to-end encryption for one-to-one conversations option checked, the messages received from a chat buddy are written as system messages and not logged:

The following message received from alecaddd@jabb3r.org was not encrypted: test

I think this is a good behaviour as we don't prevent a message from being received, so the user knows what the chat buddy is trying to write, but since the conversation is not encrypted, those messages are only written as system messages and not logged, so if the user closes the conversation, nothing remains saved.

I also think that the format in which this system message is written is clear and easy to understand.
What do you think?

(In reply to Alessandro Castellani (:aleca) from comment #10)

I think this is a good behaviour as we don't prevent a message from being received, so the user knows what the chat buddy is trying to write, but since the conversation is not encrypted, those messages are only written as system messages and not logged, so if the user closes the conversation, nothing remains saved.

I'm not sure if I follow the logic about not logging them. Why would we not want to log them?

Also, we probably want to use a different flag, styling them the same as system messages might make sense, but they mean very different things. E.g. a system message is ALWAYS trust-worthy since it was generated by the "system", while these messages are not.

(In reply to Patrick Cloke [:clokep] from comment #11)

I'm not sure if I follow the logic about not logging them. Why would we not want to log them?

That's what I'm saying, we DON'T want to log them, so the fact that are printed as System message is good.
Differently from a regular encrypted message, which is logged if the user has that option checked.

Also, we probably want to use a different flag, styling them the same as system messages might make sense, but they mean very different things. E.g. a system message is ALWAYS trust-worthy since it was generated by the "system", while these messages are not.

That's a good call, I'll do a mock-up for a different style.
I guess this update will come right after bug 1519799, since I'm touching the style of the default TB style there.

(In reply to Alessandro Castellani (:aleca) from comment #12)

(In reply to Patrick Cloke [:clokep] from comment #11)

I'm not sure if I follow the logic about not logging them. Why would we not want to log them?

That's what I'm saying, we DON'T want to log them, so the fact that are printed as System message is good.
Differently from a regular encrypted message, which is logged if the user has that option checked.

I think my double negatives made this confusing. If I saw a message from a buddy, even if it was unencrypted and showed in some special way, I would expect it still to be logged if I'm going back through my history (instead of just disappearing).

Ah, I see, sorry I didn't understand.
That's an interesting question, which I'm not sure what might be the correct approach in terms of security.

Kai, what do you think? Should we log or not initial unencrypted messages if the user has the Require encryption option checked?

We apparently don't offer a mechanism to disable logging of unencrypted chat messages.
(I think we should, but for now, let's discuss based on what we have currently.)

If the user keeps "encrypted messages are included in logs" enabled, then obviously the user isn't worried about leaving traces. Logging unencrypted messages in addition to encrypted messages is fine.

However, if the user deliberately switches to "require end to end encryption", and in addition, switches to "don't log encrypted messages", the user expressed a strong desire for a very high privacy level.

Why do we receive unencrypted messages at all, despite "require e2ee"? That seems like a bug (but one that we cannot prevent). But clearly the user doesn't want such messages to occur. If they do, they are in violation to the "require e2ee" pref.

If the user enables "require e2ee and don't log", then I'd conclude the user doesn't want traces of their conversation to reach permanent storage.

If a received unencrypted message is saved to disk, and later on an adversary gets access to the users computer, the saved unencrypted message may give the adversary a clue what kind of topics were being discussed. I think this shouldn't be possible when "require e2ee and don't log" is configured.

We could even make the point that the unencrypted messages shouldn't even be shown on screen. But I'm OK to accept that in the special way described, not being part of the regular conversation display - assuming system messages are never recorded.

We apparently don't offer a mechanism to disable logging of unencrypted chat messages.

But we do that automatically already.
If the user has require e2e enabled, unencrypted messages are never logged, but still shown to let the user know what he received.
I think this is a correct behaviour, and adding an extra option to let the user specify "don't log unencrypted messages" might be confusing as we should do that anyway for security reason.

Maybe we could add a description underneath the "Require e2e encryption" options that says:
Unencrypted messages will not be logged, in order to not break expectation.

Why do we receive unencrypted messages at all, despite "require e2ee"?

The message is received in a form of system message that is not logged, but still visualized.
I think this is necessary to allow a form of pre-verified/pre-encrypted conversation and not completely block messages.

Anyway, my priority are shifting a bit, so I won't be able to take care of this bug unfortunately.

(In reply to Alessandro Castellani (:aleca) from comment #16)

We apparently don't offer a mechanism to disable logging of unencrypted chat messages.

But we do that automatically already.
If the user has require e2e enabled, unencrypted messages are never logged,

Right. But Patrick argued we should change that, and do log them.

My comment 15 was an attempt to explain why I think we shouldn't log.

but still shown to let the user know what he received.

That's OK with me.

I think this is a correct behaviour, and adding an extra option to let the user specify "don't log unencrypted messages" might be confusing as we should do that anyway for security reason.

My thought was unrelated to OTR. It might be nice to disable logging of chats altogether.

Maybe we could add a description underneath the "Require e2e encryption" options that says:
Unencrypted messages will not be logged, in order to not break expectation.

As a naive user, if I click "require e2ee", I'd expect that no unencrypted messages are exchanged at all, neither sent, nor received!

We can prevent sending unencrypted.
However, we cannot prevent that the other side sends unencrypted.

Why do we receive unencrypted messages at all, despite "require e2ee"?

This is a rhetorical question - that a user might ask.

We receive it, because we cannot prevent what the other side sends.
All we can do is decide what to do when receiving such messages.

Currently we display it. We could potentially decide to not display it.

We can either log it or not log in. I think we should not log it, see comment 15.

The message is received in a form of system message that is not logged, but still visualized.
I think this is necessary to allow a form of pre-verified/pre-encrypted conversation and not completely block messages.

If the local user has the "require encryption" setting enabled, then no "pre-encrypted" conversation is possible.

The local user cannot send, if the other side uses a client that doesn't support OTR.

I've tested what happens if Thunderbird (local user) has "require encryption" enabled, but the other side uses a client that doesn't support OTR.

The local user types a message "hello" and sends it.

In that scenario, we send out the OTR handshake message to the other side, which is hidden on the local Thunderbird side.

The other side doesn't complete the handshake. The other side will see the raw OTR protocol text "?OTRv2? ... requested OTR conversation ..."

Because the handshake isn't completed, we will NOT send out an encrypted version of "hello". The other side will NOT see "hello".

However, in our local chat window, the text "hello" is shown. This might give the incorrect impression that the message was actually sent. However this message is in a "pending" state. The system messages shown locally inform about the pending state:

"You attempted to send an unencrypted message to ... As a policy, unencrypted messages are not allowed.
Attempting to start a private conversation. Your message will be retransmitted when the private conversation starts."

Another difference with "require encryption" enabled. The user will NOT get a notification about the received unencrypted message (despite the message being included in the system message).

We could say that received unencrypted messages are ignored. This would be aligned with "not logging" and "not notifying".

With all of that combined, here's what an additional description/label below the "require encryption" checkbox could say:

"Messages in one-to-one conversations will not be sent unless they can be encrypted. Messages that you receive without encryption will be ignored and not logged."

(In reply to Kai Engert (:KaiE:) from comment #15)

We apparently don't offer a mechanism to disable logging of unencrypted chat messages.
(I think we should, but for now, let's discuss based on what we have currently.)

We offer a way to disable logging. (See https://searchfox.org/comm-central/source/chat/chat-prefs.js#123), I don't think we should have another option to disable just unencrypted. If you want to disable all logging we should use the existing preferences.

(In reply to Patrick Cloke [:clokep] from comment #20)

We offer a way to disable logging. (See https://searchfox.org/comm-central/source/chat/chat-prefs.js#123),

Thanks, so it's a hidden pref, no UI.

I don't think we should have another option to disable just unencrypted.

Agreed.

(In reply to Kai Engert (:KaiE:) from comment #19)

"Messages in one-to-one conversations will not be sent unless they can be encrypted. Messages that you receive without encryption will be ignored and not logged."

But currently we don't ignore them, if I understand the comments here correctly? We still show that you got a message, but not what the message was - correct? (I'd think we do not want to completely just ignore them.)

It seems we show the message. But we don't show it as part of a regular conversation message. It's shown as part of a system message (which are never logged). I think it says "the following message was received without encryption: hello".

So instead of "will be ignored and not logged" it might be more correct to say "will not be logged, and will not be shown as part of the regular conversation".

Screenshot

(I notice a typo in the id, I'll fix that)

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/bac05f98e5fe
OTR UI: Clarify behavior of "require encryption" preference. r=aleca