Ignore download limit in protected (verified, green-checkmarked) 1:1 chats

[link2xt]

Here is a message with a large video and verified signature is received:

We don't know yet that it has a signature of a verified key. When we download it, the message appears in place but fixes the chat type, it becomes verified:

This is unexpected because a message with actually a good signature appears in the section marked as unverified, above the large green checkmark.

---

Later, we get a green checkmark back:

Then we receive a large message and don't know yet that it is signed with unverified key:

"Setup changed" is due to Autocrypt key change which comes from already downloaded Autocrypt header.

Now we download the message:

Green checkmark breaks, but the video with wrong signature appears in the "guaranteed e2e" section!

[link2xt]

No idea how to fix it easily, one option would be ignoring the download limit in verified chats and just download everything immediately for now.

[missytake]

No idea how to fix it easily, one option would be ignoring the download limit in verified chats and just download everything immediately for now.

That would probably be fine I think? iirc, most people we know of who need to watch out for their mobile data don't use encryption anyway? https://github.com/deltachat/bg-deltachat/blob/master/ux-feedback/personas.md#valentina-the-2g-communicator

[missytake]

Hm, on the other hand that is pretty invasive. What about this:

case 1 - the large message would fix the verified chat

If we are in a e2ee-broken chat, and we receive a too large message with an autocrypt header which contains a key we have verified, we show:

• Changed setup
• 1.79 MB message:

And as soon as the user clicks download, we delete the "1.79 MB message: download", show "e2ee-established", and re-insert the downloaded message, so that it looks like this:

• Changed setup
• e2ee-established
• the downloaded message

case 2 - the large message has a wrong autocrypt header, so we suspect it to break the verified chat

If we are in a e2ee-established chat, and we receive a too large message with an autocrypt header which contains a key we don't know yet, we show:

• Changed setup
• 1.79 MB message:

And as soon as the user clicks download, we delete the "1.79 MB message: download", show "e2ee-broken", and re-insert the downloaded message, so that it looks like this:

• Changed setup
• e2ee-broken
• the downloaded message

case 3 - the large message has a correct autocrypt header, but breaks the verified chat

If we are in a e2ee-established chat, and we receive a too large message with an autocrypt header which contains a key we have verified, but has a wrong signature, we obviously just show this before downloading:

• 1.79 MB message:

And as soon as the user clicks download, and we realize that the signature is wrong, we delete the "1.79 MB message: download", show "e2ee-broken", and re-insert the downloaded message, so that it looks like this:

• Changed setup
• e2ee-broken
• the downloaded message

I'm not deep enough into the code structure to know if we can easily do this... it basically boils down to ignore the large message until it is downloaded, and then reprocess all messages since then? But if there have been more messages after that, it might get more complicated. Do we re-process them?

[r10s]

This is unexpected because a message with actually a good signature appears in the section marked as unverified, above the large green checkmark.

i do not think, "too good encryption" is an issue at all. most ppl would probably not even recognise that the message is fine although the chat is declared as broken, also the user just did a download action, so this is somehow expectable. the other way round is worse:

No idea how to fix it easily, one option would be ignoring the download limit in verified chats and just download everything immediately for now.

if that would fix the issue and is easily doable, this seems a pragmatic way to go for; i do not think, it is too invasive, also it does not affect groups.

after 1.42 is out, we can reconsider and go for a more advanced option, if possible. eg. show downloaded messages that break guarantee not in place but at the end of the chat, after the "other device" message (probably not that bad as 1:1 chats are usually not that chatty and you can follow context more easily than in groups)

[missytake]

Ah, I missed that it doesn't affect groups. Then it is likely fine to just download large messages in verified 1:1 chats regardless of the setting; in 1:1 chats it's much more likely that the large message is actually interesting for you than in groups.

[link2xt]

Ok, so ignoring download limit in 1:1 chat if 1:1 chat is verified seems like a solution.

[link2xt]

It is actually not possible to know if the message belongs to a 1:1 chat before we download it. So we have no simple core solution.

[r10s]

hm, but usually, the messages are sorted to the correct chat before downloading, or? iirc, chat-changes-after-download mostly happens when the sender does not use dc. groups are detected reliable enough.

so, maybe it is good enough if we ignore the download limit if we assume by best guess a message belongs to a 1:1 chat (if this is not the case, then it's that) maybe we need to download all messages that do not have a grp-id.

or can we show downloaded messages that break guarantee not in place but at the end of the chat?

wondering also, how bad the issue would be in practise if we ignore the issue for now. the security impact would be mostly confusion iiuc