Skip to content

secure-join timeout is not useful for chatmail #6706

@r10s

Description

@r10s
Contributor

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

Activity

added
bugSomething is not working
on Mar 26, 2025
Hocuri

Hocuri commented on Mar 27, 2025

@Hocuri
Collaborator

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

hpk42 commented on Mar 28, 2025

@hpk42
Contributor
self-assigned this
on Mar 29, 2025
link2xt

link2xt commented on Mar 30, 2025

@link2xt
Collaborator

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

r10s commented on Mar 30, 2025

@r10s
ContributorAuthor

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

link2xt commented on Mar 31, 2025

@link2xt
Collaborator

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

r10s commented on Mar 31, 2025

@r10s
ContributorAuthor

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.

added a commit that references this issue on Apr 10, 2025
ee079ce
Hocuri

Hocuri commented on Apr 23, 2025

@Hocuri
Collaborator

Reopening because #6817 reverted the fix

reopened this on Apr 23, 2025
link2xt

link2xt commented on Apr 23, 2025

@link2xt
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething is not working

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    Participants

    @hpk42@r10s@Hocuri@link2xt

    Issue actions

      secure-join timeout is not useful for chatmail · Issue #6706 · chatmail/core