Here is what happens. Their message won’t have a padlock icon even though it’s encrypted. Your reply to them will be unencrypted.
I probably won’t file an issue for this (or at least I need to think about it first), it’s a bit weird but not necessarily wrong.
It’s messed up that Thunderbird doesn’t let its users set the “prefer-encrypt” arg to anything because they don’t support the philosophy. (I saw an older thread where people were arguing about it.)
I want to send encrypted messages to them; they don’t have it set to not prefer encrypt either and they just sent me an encrypted message so it’s weird that I can’t send one back.
I just want to padlockify my chats with more people on more MUAs♥
Lack of padlock when receiving messages from Thunderbird is caused by this bug in Delta Chat:
With this bug fixed, the padlock will be shown but the replies will still be unencrypted in 1:1 chat because of no prefer-encrypt.
(Please don’t take the following rant as me shooting the messenger; I’m grateful you told me.)
That’d be awful because if I see a padlock I know I can reply and it’ll be a padlock.
I wanna know when what I’m saying is safe and not safe.
If that behavior got changed into what you’re describing, there’d be absolutely no way to know whether or not, when I send, it’ll get encrypted. That’s a stressful horror show.
I’m starting to get a bit frustrated with the “prefer-encrypt” setting, and how all these otherwise autocrypt supporting apps like K9, Emacs, and Thunderbird default to not having it set, and in Thunderbird you can’t even turn it on, you can only manually send encrypted letters. I wanna be able to override it and be like “OK, I’ve got a fresh key from them, they’re on a misbehaving MUA, I trust them to let me know if they can’t read the message, please just make sure I send the next message encrypted”.
Here is a proposal to add an option to ignore the prefer-encrypt setting of others and override the Autocrypt recommendation:
TBH this “prefer-encrypt” setting feels a bit like a solution to a non-existent problem. The situation when user has generated the key but prefers others not to use it for encryption is probably rare, but clients default to it being disabled. And there are problems in group chats because if you have never seen a message from some user, you can’t know their encryption preference, so you should not encrypt. Delta Chat gossips encryption preference of others and uses majority vote instead of “veto” rule, but both these changes are in violation of the Autocrypt standard technically speaking.
I like how you phrased it in the merge request: other MUAs (Emacs, K9, Thunderbird) has a per-mail exposed widget setting for this. We want to come up with a Delta-appropriate solution.
Reading through the diffs (I’m not super familiar with the Delta Chat code base, and I’ve never programmed in Rust, but I became a little bit more familiar with the Autocrypt protocol this weekend) one concern is when the other person has lost their key. I.e. we imported a key from them at one point and it then got lost and then they email again and say “hey, I didn’t quite get that, can you resend?”
Unless receiving a key-less message from them updates their status in the peers structure?
That’s me just thinking out loud; I don’t wanna stand in the way of the merge ofc since I think this feature is awesome♥
If you get an email without an Autocrypt header, peerstate gets into a special “reset” state (the standard never mentions it, but it’s implied that switching to non-Autocrypt MUA removes the key). Also you can send an email with an Autocrypt header containing a new key. So this use case should work, and in the PR there is a test checking that it works.