Forcefulness of encryption, switch for the every contact. That’s the thing this is missing.
in the latest version of ArcaneChat (1.54.4) by default encryption is forced (unless you disable the forcing in advanced settings) so you can be safe you never send an unencrypted message accidentally
but also in official DC, as long as the chat has a green checkmark you know your messages will be encrypted
I have often read that DC isn’t safe because a stupid user can send unencrypted messages. A search also shows me a “don’t ever send unencrypted” setting has been asked for many times.
I would also hesitate to set up DC for some computer illiterate friend. If there is a way to send unencrypted messages they will (murpheys law). Just shortly German blogger Mike Kuketz wouldn’t recommend DC (also) for this reason.
Is it really so complicated to have such a switch in the settings? You wrote the fork Arcane has it. I wouldn’t want to use a fork.
DC would really be much safer with such a switch.
If I understand it correctly encryption is already forced if you are using a chatmail server and if you are using a normail mail provider forced encryption would absolutely bomb compatibility for that use case. It is hard for me to imagine a use case where you would use a normal mail and never send unencrypted mails, but if there is one I’m not thinking about please state your specific use case.
That’s right. Chats with normal email accounts are also guaranteed encrypted if the contacts have been verified.
Unfortunately this is true. It’s too easy even for an intelligent user to accidentally send an unencrypted message, and there are a couple of different scenarios where this could happen.
I also have concerns. As I wrote here:
I completely agree. Ideally there would also be a switch to prevent anyone who scans your QR code from sending you an unencrypted message. I believe there is even a strong argument for making this the default setting. The current onboard process guides users to create an account on a chatmail server by default, and the chatmail server will reject attempts to send an unencrypted message. There is no valid use case where you want to send an unencrypted message to the server just for the server to reject your message. It makes more sense if the client never sends the unencrypted message to the server in the first place. Therefore having a “never send unencrypted messages” setting enabled by default is more consistent with the current default settings as well as more consistent with the app’s designation as a “secure messenger” and the expectations which that entails. More advanced users who choose a non-default server could easily change the setting for “never send unencrypted messages” if this is what they want.
Yes, but even with a chatmail server, the problem is that the encryption is currently forced at the server instead of at the client. Proper E2EE means no unencrypted messages should ever be leaving the client. If you are sending unencrypted messages to the server and just trusting the server not to store or forward your unencrypted message, that’s not E2EE!
Some people use Delta Chat only as a messenger and switch to a tradtional email client when they want to send and receive normal unencrypted emails. This is why Delta Chat has an option to only display chat messages and ignore/hide normal emails in the inbox. It is reasonable if these users expect their chats to be encrypted at all times, just like any other secure messaging app.
Unfortunately, as I described here, many people might reasonably but falsely assume that the connection is secure as soon as they scan a contact’s QR code, when in reality the connection is not secure until the contact sends their key and the secure join is completed. On a slow network connection, it can take several minutes until the secure join is completed, and if either person is offline at the time, it can take much longer, and Delta Chat will currently allow you to send unencrypted messages in the time between scanning a QR code and completing the secure join.
If you scan a QR code, you can send encrypted messages immediately, because the public key is already present. In my experience, the recipient only sees the new chat once the securejoin process is complete and therefore can’t write any messages beforehand.
While it seems intuitive that the public key is already present, I think in reality this is not the case.
However Delta Chat invites the person who scans the QR code to send unencrypted messages before the securejoin process is complete.
Then the message would be sent unencrypted, but this hasn’t happened to me yet, and it’s not even possible with chatmail servers.
How can the contact send messages if the chat isn’t visible yet? This isn’t possible with chatmail servers anyway.
if a QR code scan takes longer than 15 seconds, Delta Chat says “you can already send a message, even though e2ee is not established yet”. this fails on chatmail then.
the idea of the timeout comes from a time before chatmail, and was even questionable then.
next update will probably remove that timeout, see secure-join timeout is not useful for chatmail · Issue #6706 · chatmail/core · GitHub
The chat is visible to the one who scans the QR code even if guaranteed E2EE has not been established.
In my experience this does not fail on chatmail. It has happened to me several times even using a chatmail server, the first message arrives before guaranteed E2EE is established. I tested this again today. The first message showed up in my chat without a padlock before E2EE was established.
Even if chatmail does successfully reject unencrypted emails, I would argue that users should not need to trust the server not to store and forward their unencrypted message, because the fundamental expectation of E2EE is that unencrypted messages never leave the client, and so it is primarily the responsibility of the client not to send the unencrypted message. Many people who scan the QR code will intuitively assume the connection is secure (E2EE), and sending unencrypted messages to the server (even if the server rejects the messages) breaks that assumption.
I believe you, but I absolutely can’t reproduce it. For me, the chat only appears after scanning. No matter how quickly I send a message, it’s always encrypted. This also applies to regular email accounts.
Before core 1.158.0 in the inviter/Alice side the chat was created after receiving key request, but before receiving the auth code. This is now changed to always create the chat only after receiving the auth code, so on the inviter side the chat will appear even with a green checkmark.
On the scanner/Bob side, when you scan the code a non-hidden chat is created immediately, but you cannot write there. The chat is created with an “Establishing guaranteed end-to-end encryption, please wait…” message and no ability to send anything. 15 seconds later it displays “Could not yet establish guaranteed end-to-end encryption, but you may already send a message.” and allows to send a message, which may be unencrypted if even the first step of handshare did not happen. This is easily reproducible by creating two accounts, then going offline, then copying the invite link between them. This is the issue secure-join timeout is not useful for chatmail · Issue #6706 · chatmail/core · GitHub
1 Like
It looks like this has now been fixed? I’m not sure what the issue was before, maybe a race condition?
Anyway now it seems that the person who displays the QR code can see the chat and is invited to send a message before the green checkmark appears, which is not a problem from the encryption perspective because the message still gets encrypted, but it might be a bit confusing from the UI perspective.