Замечательно, спасибо, Даниэль! Можешь ли ты настроить так, чтобы Conversations и Quicksy по умолчанию активировали привязку канала?

И ещё один вопрос: в какой версии Conversations появится возможность выбирать только TLS 1.3, как на скриншоте?

Let's consider how deltachat, in its default mode of operations, works.

What is the purpose of Channel Binding ? It seems to me to be mitm-resistance, but considering that in deltachat, contrary to Conversations, the user doesn't even know their password I don't see how they're going to be phished on a scam website. The only way to connect from another client is starting from an already legit one that will consciously share credentials. The app, like conversations, doesn't make typos when calling the server, so if mitm didn't happen through mistyping the address it happens behind TLS, so it's the same for Conversations.

What happens in the case of a mitm ? In deltachat chats are not mitm-able: the only thing a mitm box will see is gpg-encrypted emails. Recall that in its default setting email addresses are pseudonymous (i.e they have no human meaning and it is expected that one person will use many addresses) so what a mitm will see is that some random address sent some other random address something, and the date. The real mitm that can have an impact is one that can intercept the qr code, or the link it contains, out of band. Nothing can be intercepted in-band. Note that this is true even in the non-default way of using deltachat, with your own account on another server, as long as you use deltachat.
In Conversations, because the server is important, they will be able to do everything the user can do: see/set presence, change omemo keys, publish/subscribe, read and send unencrypted stanzas. The only thing they won't be able to do is to read the content of encrypted content, but they will still see who sent it in which room.

Deltachat massively downgraded the importance of server to the point they are just relays of content. It is parting ways with the 80's and 90's era of a server capable of doing everything and clients only ordering them to; xmpp hasn't. The result of a mitm is catastrophic in that mindset, but for a more p2p app it's more of an inconvenience.

So, no, deltachat doesn't implement channel binding, but contrary to others including Conversations deltachat actually doesn't need to. So that's ok.

It's a bit disingenuous to talk down on other libre and decentralized messengers, especially when xmpp in its current design and deployment is arguably worse on the security aspect, not talking about the metadata aspect that the xmpp world still hasn't heard of somehow. They are not the enemy, Whatsapp and Messenger are. (note: this is also valid for delta fans)

(I might have made some mistakes, feel free to tell me)
@matrix @delta

yes, you can verify keys, but that's just it: only keys are verified. Everything else can't, and there are many things not protected by e2ee.

I don't understand the part about YOLOing the transport though, or is that another subject ?

@delta @matrix

I've got two XMPP accounts, one at Conversations the other on another server.
If I activate it, do you know it it will just be ignored or "break" something when it comes to the other server.

PS. Thanks for a great app! Been using XMPP since early Jabber days, Conversations is my favourite client for it.

Hello Daniel,
Can we verify whether the server and local hash are consistent during the process of determining the known certificate?

The current implementation location of related functions *isCertKnown* is in

src/main/java/eu/siacs/conversations/services/MemorizingTrustManager.java

Adjusted pseudocode
pastebin.com/raw/FFXwMNVX

The reason behind wanting this modification is to obtain an alert following the SSL certificate's update, Even if it is issued by the same CA and subject DN remains unchanged.