I actually think that duplicated 1:1 chats are a big usability problem in and of themselves, so simply prompting to “switch” to an encrypted chat would not quite cut it in my opinion. As I already mentioned in UX regression when onboarding new users, I feel that having two different 1:1 conversations with the same PEER adds quite a bit of UI complexity. I do not think that this kind of UI complexity is worth it. Especially since the benefits it provides in terms of enabling end-to-end encryption could be provided just as easily by the UI I propose below.
With duplicated conversations, users need to decide which of the two conversations with PEER they should use in which case. In order to do that, they need a good understanding of what the difference is. As far as I realize, this understanding can only be gained by following the discussion in this forum, which most users do not do. The current UI gives hints about the difference between the e2ee and non-e2ee versions of the “same” conversation, but those hints are hardly enough to give users a good understanding of what is going on in the background. Especially if these users do not know anything about the underlying data structures or about the recent switch from address-contacts to key-contacts. If users do not have a good understanding of the difference between the two versions of the “same” conversation, they need to make an uninformed choice about which one to use. Consequently, they might easily choose the non-e2ee-enabled
version even if there is no reason not to prefer the e2ee-enabled one.
My alternative proposition would be this: The UI should not be about switching between two different versions of a 1:1 conversation with the same PEER. Instead, it should be about upgrading a conversation with PEER to e2ee. This would make it clear to users that they are still talking to the same PEER – but now in a “better” way. It would also remove the decision of which conversation to choose to communicate with PEER (as there is only one 1:1 conversation with PEER at any one time). This would reduce the cognitive load required for using Delta Chat; and as a side effect it would protect users from accidentally choosing the “wrong” conversation. (I.e. choosing the non-e2ee conversation when there is really no reason not to use e2ee.)
A concrete proposal for an upgrade path
When a non-e2ee message arrives from an unknown sender, the user can decide to accept that message or to block the sender. If the user accepts the message, a new envelope-style 1:1 chat with PEER is created. This is already the current behaviour.
As soon as a key becomes available for PEER, the envelope-style 1:1 chat can be transformed into a non-envelope-style 1:1 chat. I would propose that this new non-envelope-style 1:1 chat should still contain all the old envelope-style messages to make it clear that the user is still talking to the same PEER. Below those old messages, it should contain a system message explaining that the chat has become end-to-end encrypted. Afterwards, it contains non-envelope-style messages that are exchanged using e2ee.
There are currently two ways in which a key for PEER could become available:
- I do a QR-Scan with PEER and SecureJoin happens. Doing the QR-Scan with PEER is already a very clear indication that I want to upgrade our conversation to e2ee, so in this case the envelope-style 1:1 chat should be transformed into a non-envelope-style 1:1 chat automatically. Also, performing SecureJoin will already create a system message that says:
“Messages are end-to-end encrypted. Tap to learn more.”
This system message makes it very clear to the user what has happened. It confirms that SecureJoin worked as intended. And it serves to explain why the messages above this system message are envelope-style, while the messages below this system messages are non-envelope-style.
- Alternatively, the key for PEER could become available through autocrypt headers. In contrast to the QR-Scan described above, this is not a particularly strong indication that a user wants to upgrade the conversation. However, the fact that both USER and PEER are apparently using autocrypt-capable email clients can at least serve as a weak indication that they might want to use e2ee. There are multiple ways Delta Chat could react to this weak indication.
a) Delta Chat could simply pretend it did not notice. This is the current behaviour, but I think taking a more proactive stance towards enabling e2ee would be desirable.
b) Delta Chat could tentatively perform an automatic upgrade to e2ee – and then always keep an eye out for non-e2ee messages that would trigger a subsequent downgrade. This would be in line with the current autocrypt spec; and this is also what Delta Chat did in early 1.x versions. The drawbacks of this have already been discussed, I believe.
c) Delta Chat could take a strong stance towards enabling e2ee and just perform the upgrade to e2ee as soon as it discovers an autocrypt key. This approach could be seen as rather aggressive, and it would be a little further from the current autocrypt spec. Also, this is what Delta Chat did in later 1.x versions. I myself was initially surprised that Delta Chat would automatically upgrade my conversations to use e2ee. But after overcoming this initial surprise, I started to appreciate this behaviour. So I myself would be happy if Delta Chat took this approach again.
d) Delta Chat could inform the user that a key has become available and ask if the user wants to upgrade the conversation. Some of the implications of using this approach have already been discussed above.
Downgrading a conversation
Where there is an upgrade path, there should probably also be a downgrade path. Currently, this downgrade path works like this:
-
I have an e2ee-enabled 1:1 conversation with PEER. E.g. because we did SecureJoin.
-
PEER (for whatever reason) sends me a single non-e2ee message. Now I have a second, non-e2ee 1:1 conversation with PEER. If I reply to the non-e2ee message, my reply will not be end-to-end encrypted either. (By the way: I would argue that this existing behaviour makes it too easy to downgrade a 1:1 conversation to non-e2ee.)
If Delta Chat would deduplicate 1:1 conversations like I propose, this existing downgrade path would no longer be available (more on that below). Making downgrades hard is probably a good thing, as it also guards against things like accidental downgrades or even against possible downgrade attacks. Still, there could be valid reasons why a user wants to disable e2ee again. There are multiple ways this could be implemented. A user could manually delete the 1:1 conversation with PEER. Afterwards, the next non-e2ee message from PEER could appear as a new request for a non-e2ee conversation. Alternatively, one could add a toggle that is hidden in the encryption settings for a given PEER. Users could go to the “Contact” screen, select “… – Encryption” and then maybe select something like “Disable end-to-end encryption for this contact”. Using a toggle instead of a destructive action like delete would allow users to change
their mind again. Performing a new QR-Scan after toggling encryption off should obviously reenable it. And there might be other edge cases worth discussing – like what to do if, after a downgrade, PEER resumes sending autocrypt headers; or if after a downgrade, PEER starts using a new key.
Edge cases to keep in mind
PEER occasionally sends non-e2ee messages
One edge case to keep in mind would be presented by the following scenario:
-
I have an e2ee-enabled 1:1 conversation with PEER.
-
PEER sends me a non-e2ee message M.
Currently, message M would appear in a new 1:1 conversation with PEER. However, if Delta Chat deduplicates 1:1 conversations like I propose, this would no longer be possible. In the 1.x versions of Delta Chat, where 1:1 conversations were also deduplicated, there were two ways to handle this issue:
a) If I understand this correctly, early 1.x versions would simply display message M in the conversation with PEER but omit the padlock. Afterwards, they would use certain heuristics to determine whether the presence of non-e2ee M should trigger a deactivation of e2ee for subsequent outgoing messages to PEER.
b) Later 1.x versions would (if I remember correctly) also display M in the conversation with PEER and omit the padlock. However, they would never trigger a deactivation of e2ee for subsequent outgoing messages.
If Delta Chat were to deduplicate 1:1 conversations like I propose, the most reasonable thing to do in the edge-case of receiving M would be to reintroduce option b). That is, display M in the e2ee-enabled 1:1 conversation with PEER, but use an envelope in the bottom right corner of the message to indicate that this particular message did not use e2ee. Do not automatically deactivate e2ee for outgoing messages under any circumstances.
One might argue that placing the non-e2ee message M within a “guaranteed end-to-end encrypted conversation” would break this guarantee. However, I would argue that the “damage” to this guarantee is already done by the fact that PEER sent M without using e2ee. Placing M in one conversation or another would not change this fact. Furthermore, there is no way that Delta Chat could possibly guarantee that PEER will use e2ee. The only thing Delta Chat can reasonably guarantee is that outgoing messages will use e2ee. For incoming messages, PEER could even Bcc a public mailing list, for all I know, and Delta Chat would have no way of even noticing this; much less of doing anything to prevent it.
Also, there might be valid reasons why PEER would occasionally send me non-e2ee messages. Maybe PEER is using a device where they have access to their email (maybe through webmail) but not to their keys. Maybe their battery died and they just want to let me know that they are fine and will be back online in a few hours. Maybe they are using a public computer in a library and just want to quickly share a link or a screenshot. In cases like these, I would want ot see the non-e2ee message M in the same 1:1 conversation with PEER that I always use, but I would still want to reply using e2ee, since I am confident enough that PEER will be able to decrypt my reply later on.
PEER shares an address with other people
This possibility has been mentioned in Prompt to switch to encrypted chat when it is available - #5 by link2xt. I suppose that the switch from address-contacts to key-contacts in meant to enable certain new features. Such as switching email providers without giving up the cryptographic identity. Or maybe even improved anonymity by sending messages through strangers’ accounts, which would hide peoples’ social networks from their email providers through a combination of sealed sending and noise.
I must admit that I am very much ignorant about those future plans. Also, while I am very much in favour of strengthening the autonomy and anonymity of users, those two issues are currently a little removed from my personal use case. (I have a rather high degree of trust in my email provider; and I generally use my real name in all email-based conversations.) Therefore, I am probably ill equipped to offer any profound thoughts on this particular edge case. Still, I would hope that this new use case – using permanent keys but changing addresses – could be implemented in a way that would not foreclose the old use case of using permanent addresses but possilby changing keys. I suppose that both these approaches would each have their own benefits and drawbacks for different situations and use cases.
