feat: Make one-to-one chats read-only the first seconds of a SecureJoin (#5512) #5550
Conversation
|
i did a functionality test with iOS - works nicely so far! thanks a lot for pushing that forward! i know this is a draft still, one comment anyways: if the chat is already guaranteed-e2ee, the "Messages are guaranteed e2ee from now on" information is not re-added again (this was also the case before) - however, with this PR, the "please wait ..." is stuck as the last message then, even if the secure join has finished again a long time ago:
i'd just do not add the "please wait ..." message in case the chat is already guaranteed e2ee, in this case everything would just be as before (discussing to add "Messages are guaranteed e2ee from now on" several times seems to be more time consuming and a larger change, idk, maybe that was discussed before and there were $reasons :) |
iequidoo
force-pushed
the
iequidoo/securejoin-wait
branch
2 times, most recently
from
2cf857e
to
ec1f20e
Compare
|
@r10s, thanks a lot for testing and the suggestion on how to fix the described unwanted behaviour. Now i disabled this logic for protected and "protection broken" chats. Also fixed (i hope, all) possible races with the SecureJoin finishing in parallel, now protection messages are guaranteed to be below the "please wait..." message. But i made some retreat in the implementation from what you described in the task, namely this is done:
So, i don't check if we have Alice's key, instead i just check the chat protection status. It should be checked anyway as you noted and also if we check the Alice's key, we should check that it matches the fingerprint in the QR, so i decided not to complicate things, this "please wait" state is 15 seconds anyway. EDIT: Let it be already "ready for review", i'll add Rust tests eventually (soon) in order to protect from regressions. Now i'm going to join the vCards efforts |
|
... and also added the strings to deltachat/deltachat-android#3044 - including some screenshots of the flow, if someone wants to discuss wordings, this is the chance :) |
…in (#5512) This protects Bob (the joiner) of sending unexpected-unencrypted messages during an otherwise nicely running SecureJoin. If things get stuck, however, we do not want to block communication -- the chat is just opportunistic as usual, but that needs to be communicated: 1. If Bob's chat with Alice is `Unprotected` and a SecureJoin is started, then add info-message "Establishing guaranteed end-to-end encryption, please wait..." and let `Chat::can_send()` return `false`. 2. Once the info-message "Messages are guaranteed to be e2ee from now on" is added, let `Chat::can_send()` return `true`. 3. If after SECUREJOIN_WAIT_TIMEOUT seconds `2.` did not happen, add another info-message "Could not yet establish guaranteed end-to-end encryption but you may already send a message" and also let `Chat::can_send()` return `true`. Both `2.` and `3.` require the event `ChatModified` being sent out so that UI pick up the change wrt `Chat::can_send()` (this is the same way how groups become updated wrt `can_send()` changes). SECUREJOIN_WAIT_TIMEOUT should be 10-20 seconds so that we are reasonably sure that the app remains active and receiving also on mobile devices. If the app is killed during this time then we may need to do step 3 for any pending Bob-join chats (right now, Bob can only join one chat at a time).
iequidoo
force-pushed
the
iequidoo/securejoin-wait
branch
from
ec1f20e
to
10e78b4
Compare
|
i think, we can merge that in to get real-world feedback on a soon™ android release - a test would be very cool, but can also go into a subsequent PR (eg. relaxed when vcard is done as well) |
|
k, merging this in to get an android-beta 1.45 today |
See commit messages.
Close (TODO: Add Rust tests) #5512