secure-join timeout is not useful for chatmail

[r10s]

when scanning a QR code, the chat does not allow to send messages, as they cannot be encrypted yet.

however, if the other side does not respond within 15 seconds (grep for SECUREJOIN_WAIT_TIMEOUT), a message is added to the chat, saying that you can already send a message, even though e2ee is not established yet:

the reason for the timeout being introduced that time was to not let ppl send accidentally an unencrypted message (doing a qr code scan and sending the message a second before e2ee is established)

with chatmail, however, things have changed, as sending unencrypted messages is not possible at all.

possible fixes:

1. as a quick-fix we could maybe tweak the wording (how?)
2. probably better, remove the timeout at least for chatmail
3. maybe remove the timeout alltogether, to not offer more "e2ee but" vectors - non-chatmail users can start a conversation also by entering the email address - and scanning a QR code would always result in e2ee

for reference: the timeout was introduced at #5512 / #5550

[Hocuri]

I'm in favor of fix 2. or 3.

Edit: I tend a bit towards fix 3, removing the timeout altogether. In DC-DC usage it's usually not useful because mostly, both sides will use Chatmail. In DC->Email usage it's not useful because there are no QR codes you can scan there. The only case where it's useful is when Alice uses DC with a classical account (or a self-hosted chatmail account where she is able to send messages), and Bob also uses DC, and the securejoin messages are delayed a lot or don't arrive at all (in which case the messaging experience isn't going to be great, anyway - and Alice is going to have a bad time when she notices that she can't add Bob to verified groups).

And getting rid of complexity is always great.

[hpk42]

On Thu, Mar 27, 2025 at 06:34 -0700, Hocuri wrote: Hocuri left a comment (chatmail/core#6706) I'm in favor of fix 2. or 3.

I am for 3. (wait indefinitely) plus changed wording that indicates that this will only finish when the other side gets online. Have a deterministic result of securejoin-tapping indeed helps to avoid the "it's encrypted except ..." problem.

[link2xt]

If we remove timeout, users will still be able to send unencrypted message. For setup contact protocol (not joining the group), 1:1 chat is created immediately but is blocked for 15 seconds by why_cant_send_ex. If we simply remove the timeout-related code, then why_cant_send_ex will allow to send immediately. Do we just want to block the 1:1 chat forever somehow? Then showing a wrong QR code for email address to someone will block the chat with this email address forever because the email address have no key.

[r10s]

my idea is to

1. unconditionally block the chat until e2ee is established

2. after ~15 seconds, instead of letting can_write() return true, only add a message with further information ("NAME is not reachable. you can leave this chat now. e2ee will be established in background as soon as both devices are online.")

for the mentioned "forever blocking when showing wrong qr code for an address" (however this can happen):

shouldn't a new scan remove the old, blocked process?
so should the deletion of the chat

[link2xt]

shouldn't a new scan remove the old, blocked process?

We have multiple Bob processes now and old processes are not removed if they still have a chance to finish. Starting a new process with a working QR code will result in encrypted chat.

The only problem is that if you don't have a working QR code (e.g. because the address does not use DC anymore) you can no longer send unencrypted message.

Receiving an unencrypted message from this address should fix the problem I think. On desktop we have a "reset encryption" button in the encryption info as well, it should help in resolving this if you really want to drop to unencrypted.

[r10s]

We have multiple Bob processes now and old processes are not removed if they still have a chance to finish. Starting a new process with a working QR code will result in encrypted chat.

i can confirm, this works as expected with the PR #6722 - if Bob scans a bad QR code of Alice, things are stuck, but when Bob scans later a working one, things are fine

The only problem is that if you don't have a working QR code (e.g. because the address does not use DC anymore) you can no longer send unencrypted message.

so, this is a situation that is interesting only for non-chatmail, right?
you can also fix that by just deleting the chat and then creating a new one manually, you can then send unencrypted. as this seems to be a cornercase, it's probably good enough.

[Hocuri]

Reopening because #6817 reverted the fix

[link2xt]

We should revert the revert from #6817 after PGP-contacts (#6796). It adds is_encrypted() which makes it possible to see that the chat is encrypted, then there is no need to ever block sending there. Worst case the message is not sent because you don't have keys.