search

deltachat / deltachat-core

Delta.Chat C-Library with e2e chat-over-email functionality & Python bindings
https://c.delta.chat
Other
304 stars 27 forks source link

add a function that shows the encryption state of the chat? #343

Closed r10s closed 5 years ago

r10s commented 6 years ago

if addition to dc_msg_get_showpadlock() we need sth. as dc_chat_get_showpadlock() to check out if a lock should be draw on the "send" button.

in older versions, dc_msg_get_showpadlock() imply that subsequent messages are also encrypted, however, this was not really understood by the users. also, this has the confusing disadvantage that the state of a messages changes if the user disables the e2ee-setting (as subsequent messages are no longer encrypted then ...).

hpk42 commented 6 years ago

in opportunistic chats there might be small dragons here UI-wise ... if i am starting to type a message and just before i hit "send" the send button changes from default-encrypt to default-not-encrypt because there was a new non-autocrypt message coming in -- it's a bit surprising/annoying maybe. But it's an edge case, admittedly. So maybe when "send" is actually clicked, it should tell the underlying code what to do (encrypt/not-encrypt) even though the opportunistic autocrypt states for the recipients might have changed meanwhile ...

r10s commented 6 years ago

we already have an internal flag "guarantee e2e" in the core. currently the flag is set "if e2e is available and the last message was encrypted" [1] when dc_send_msg() is called. it guarantees that the message won't be sent unencrypted - eg. if it is delayed by a flaky network an in between keys or settings do change.

we could use the criterion [1] to show the state of the send button then.

but, as you said, this does not help in the situation where the state changes while the user is typing just before hitting "send".

also, maybe users won't be happy if the button switches from "has a lock" to "has no lock" here and there.

maybe it is better to show just "no lock" for opportunistic. and a long press shows options for "force encrypted" and "force unencrypted", however, as this will overwrite the autocrypt state, maybe only for the next message. not sure. will also make things complicated; we should also keep in mind that whatever we imagine here may result in work of android/desktop/ios/whatever.

or, we leave all this out and point to the verified chats for advanced security.

i've added a question mark to the title of this issue.

r10s commented 5 years ago

closing this for now, changes in this area should be driven by ui/ux, not necessarily function-wise.