feat: no unencrypted chat when securejoin times out #6722
Conversation
r10s
force-pushed
the
r10s/wait-for-securejoin
branch
3 times, most recently
from
e7756c0 to
098e7c2
Compare
r10s
force-pushed
the
r10s/wait-for-securejoin
branch
from
c7a88ef to
83582e9
Compare
r10s
changed the title
r10s
requested review from
iequidoo and
link2xt
and removed request for
iequidoo
instead, show a message with further information after some timeout, but the user can send only when e2ee is actually established.
r10s
force-pushed
the
r10s/wait-for-securejoin
branch
from
83582e9 to
92f27cd
Compare
| #define DC_STR_SECUREJOIN_WAIT_TIMEOUT 191 | ||
|
|
||
| /// "This takes longer than expected, maybe devices are offline…\n\nHowever, the process continues in background, you can do something else" |
There was a problem hiding this comment.
Maybe "the peer is offline"? Otherwise it's not clear whose devices are meant and how many of them are offline
There was a problem hiding this comment.
"peer" is a less known term for non-nerds than "device".
most ppl have only one device, and the message only appears after 15 seconds, so it seems none is responding - or SELF is offline
however final wording can be discussed in an android PR where i'll make the strings also translatable.
There was a problem hiding this comment.
What about "the device is offline" or "one of the devices is offline"? The plural also surprised me when I first read this message. I think it's clear enough which device is meant.
(but yes, the discussion here doesn't need to block merging this PR here)
There was a problem hiding this comment.
I think it's clear enough which device is meant.
which one? could be Alice's device or Bob's device
but yes, i merge this PR now and will do an android PR where for the wording
There was a problem hiding this comment.
PR for the wording: deltachat/deltachat-android#3709
|
btw, the stock-jsonprc-strings - are they generated automatically? CI is green although one was removed, so i would assume so |
Revert the biggest part of #6722 in order to fix #6816. Reopens #6706. Rationale for reverting instead of fixing is that it's not trivial to implement "if the chat is encrypted, can_send() returns true": When sending a message, in order to check whether to encrypt, we load all peerstates and check whether all of them can be encrypted to (`should_encrypt()`). We could do this in `can_send()`, but this would make it quite slow for groups. With multi-transport, the ways of checking whether to encrypt will be different, so in order not to do unnecessary work now, this PR just revert parts of [https://github.com/chatmail/core/pull/6722/](https://github.com/chatmail/core/pull/6817#), so that we can make things work nicely when multi-transport is merged. As a quick mitigation, we could increase the timeout from 15s to something like 1 minute or 1 day: Long enough that usually securejoin will finish before, but short enough that it's possible to send to old chats that had a failed securejoin long in the past.
this PR leaves one-to-one chats that were created by a QR code scan unwritable until e2ee is established.
the logic of the timeout is reused to show a message with additional information:
if the secure-join finishes faster than the 15 seconds, the middle message is not shown.
closes #6706