default setting is that admins can easily inject their own key without user noticing it.
additional to that:
gajim sends files over jingle without encryption in e2ee chats
dino does not offer reliable e2ee for group chat.
it is difficult to verify keys in conversations because these settings are hidden afaik.
This needs to be qualified a bit… if the convenience feature for enabling e2ee by default and automatically exchanging keys with other devices is enabled (which can be turned off easily in most clients), then yes a new device can be introduced by a server admin in theory, but even then most clients will clearly switch to a encrypted-but-unverified display next to each message (in Gajim for example it will show a only half-filled shield next to each message, I think in Conversations it switches from a green to a yellow sign).
As for file sending, these are (usually still transport encrypted) fall-back modes to the modern e2ee OMEMO encrypted file sending used by most popular clients. Yes it would be probably better to disable them all together and/or put a big warning, but they are not the regular way attachments are shared these days. If you make sure you use a correctly configured XMPP server then you basically never run into this issue.
I think in Conversations it switches from a green to a yellow sign).
There is no button called: verify key or something in conversations. It is a hidden setting.
Do you know how to verify a contact without using the qr code? It’s a hidden setting and most users won’t know it. Neither does it give you info that you can verify keys by scanning qr code.
How should a user know? Not. So they stick to default settings, and the default setting is, that an admin can inject keys anytime they want, without user noticing.
As for file sending, these are (usually still transport encrypted)
I’ve mentioned Gajim, not any client. Gajim uses jingle without transport encryption.
You can either make e2ee easy to use and enable it by default, or you can try to make people understand what they are doing to protect them from edge cases. Conversations does the former, while not making the latter impossible.
Could more emphasis be put on the latter? Maybe, but then people would complain about it being difficult to use and understand.
That people don’t understand e2ee and assume that it somehow makes your communication magically secure is a social problem and not a technical one. All the above things you mention are not difficult to understand or do in the Conversations GUI, but they require a basic understanding of e2ee, which you can’t teach in a GUI.
In the end IMHO it is better to have many people using e2ee even in a less secure form, as most people don’t really need strong e2ee anyways. But by having many people use e2ee, it can’t be used to single out the few people that really need higher opsec, but those few really need to understand what they are doing and teach their contacts accordingly.
You can either make e2ee easy to use and enable it by default, or you can try to make people understand what they are doing to protect them from edge cases. Conversations does the former, while not making the latter impossible.
…the “edge case” that e2ee should protect from third parties such as an admin to read the messages.
A new key could create a pop up window that informs the user. If user doesn’t care, there can be an option for “never show again”.
Having a function that says “verify key”, should also be expected from an app that argues to have secure e2ee implementation.
as most people don’t really need strong e2ee anyways.
Most people don’t need any. It’s infosec larping what people do. And then software developers build software for LARPing.
Fixed that for you. :)
As ibsaid previously my statements are based on an old experience. Much has changed today.
default setting is that admins can easily inject their own key without user noticing it.
additional to that: gajim sends files over jingle without encryption in e2ee chats dino does not offer reliable e2ee for group chat. it is difficult to verify keys in conversations because these settings are hidden afaik.
This needs to be qualified a bit… if the convenience feature for enabling e2ee by default and automatically exchanging keys with other devices is enabled (which can be turned off easily in most clients), then yes a new device can be introduced by a server admin in theory, but even then most clients will clearly switch to a encrypted-but-unverified display next to each message (in Gajim for example it will show a only half-filled shield next to each message, I think in Conversations it switches from a green to a yellow sign).
As for file sending, these are (usually still transport encrypted) fall-back modes to the modern e2ee OMEMO encrypted file sending used by most popular clients. Yes it would be probably better to disable them all together and/or put a big warning, but they are not the regular way attachments are shared these days. If you make sure you use a correctly configured XMPP server then you basically never run into this issue.
There is no button called: verify key or something in conversations. It is a hidden setting. Do you know how to verify a contact without using the qr code? It’s a hidden setting and most users won’t know it. Neither does it give you info that you can verify keys by scanning qr code. How should a user know? Not. So they stick to default settings, and the default setting is, that an admin can inject keys anytime they want, without user noticing.
I’ve mentioned Gajim, not any client. Gajim uses jingle without transport encryption.
You can either make e2ee easy to use and enable it by default, or you can try to make people understand what they are doing to protect them from edge cases. Conversations does the former, while not making the latter impossible.
Could more emphasis be put on the latter? Maybe, but then people would complain about it being difficult to use and understand.
That people don’t understand e2ee and assume that it somehow makes your communication magically secure is a social problem and not a technical one. All the above things you mention are not difficult to understand or do in the Conversations GUI, but they require a basic understanding of e2ee, which you can’t teach in a GUI.
In the end IMHO it is better to have many people using e2ee even in a less secure form, as most people don’t really need strong e2ee anyways. But by having many people use e2ee, it can’t be used to single out the few people that really need higher opsec, but those few really need to understand what they are doing and teach their contacts accordingly.
…the “edge case” that e2ee should protect from third parties such as an admin to read the messages. A new key could create a pop up window that informs the user. If user doesn’t care, there can be an option for “never show again”. Having a function that says “verify key”, should also be expected from an app that argues to have secure e2ee implementation.
Most people don’t need any. It’s infosec larping what people do. And then software developers build software for LARPing.