I really don’t read this attitude that others seem to be getting from this post. It seems adversarial, but not overly adversarial. Its about as adversarial as I’d expect a cryptography criticism+critique to be.
I’m a fan of this person and I think their contributions usually make a positive impact but this post was resentful and came across as having bad intent. It made it hard to read.
Do you think these responses to courts were dishonest? Signal can simultaneously disappoint our expectations about Free Software and also be trusted to not store anything beyond phone numbers and a pair of timestamps.
Among those is a mapping from the phone number to all the devices the user owns. For each of those devices, the server stores the information if it’s Google, Apple or something else (“user agent”). For Google and Apple it stores a unique push token that can be linked by Google and Apple to their respective accounts (and thus is PII under GDPR and similar legal definitions). As Signal was always able to send push notifications and still is today, we can be certain that even if they don’t use the open source version of the server in their live system (which they are known to have done in the past), we know they are storing those push tokens. They also state it in their privacy policy that they do this (but who reads those when there is a nice “we don’t store, see our published responses to gov” page that claims they don’t store anything).
As an example, in the request https://signal.org/bigbrother/cd-california-grand-jury/ the subpoena specifically included “device data” and “connected applications”. Signal had this data (as seen above), but in their reply they didn’t include it and they even explicitly claim (without any need), that they only have “the time of account creation and the date of the account’s last connection to Signal server”, which as can be seen when looking at the code, is completely wrong.
Can signal be coerced into releasing an update that weakens the privacy of a huge portion of its users?
In theory, no, because all the relevant code is open source/free software and can be built reproducibly.
In practice, probably. Who knows if people are actually auditing the code and verifying the published builds. But that’s the case for federated software, too. Or, Google Play could be compromised too and forced to distribute doctored builds (you’d still need to compromise Signal to get their signing key). But you’d have the same problem with F-Droid. F-Droid at least can’t target individuals who are using Tor to download APKs because it doesn’t require signin, but individual targeting is not what you asked about.
Looking at his blog archive, he’s been a pretty active Signal shill for a while, and with good reason if you consider the technical parts of Signal, which seems pretty good, compared to what’s out there.
(I’m not an expert in this field, but the reviews of the open-source crypto-engineering of Signal seem positive… but there are also many small weird things around the Signal Foundation.)
If I find a problem in the latest draft of the specification, some will say that’s a non-issue because the spec is “experimental” and therefore should not implemented yet.
On the contrary, experimental (which both versions in question are, so it’s not a question of new/old version) is exactly when one should be doing good-faith analysis and submitting feedback so that the spec can be changed if needed before it is widely relied upon. So finding a problem in an experimental version is good!
It’s also possible that XMPP’s ecosystem will decide to make end-to-end encryption a non-optional component for all XMPP clients.
Unfortunately, or maybe ‘fortunately’, depending on how you look at it, this is next to impossible in the XMPP ecosystem, where standardization and implementations are not under the control of a single entity.
I’m a little confused on the basic premise, which is XMPP+OMEMO isn’t a Signal competitor because it’s not as good as Signal. Where I’ve typically seen XMPP used is inside of large organizations to either power internal chat systems or as the backend for things like customer service chat. In those situations it seems like OMEMO is a good design because I control both sides of the equation (and often the client in this context is a web client).
I believe the authors point is “if you are looking at migrating off of Telegram towards a different nerdy encrypted chat, Signal is the superior choice to XMPP+OMEMO”. Which is probably true, certainly Signal was designed to do what they are discussing vs XMPP where this functionality was added on. I don’t think that the majority of XMPP users are walking in expecting encryption (but maybe I’m wrong about that).
To me a lot of the criticisms are more understandable in the light of “XMPP serves many purposes”.
XMPP+OMEMO is fine by some other blogger’s random standards, so who is right and who is wrong? Why is one right, and the other wrong?
Reminds me of people saying $X is/is not open source, based on either group-of-people-A’s opinion or group-of-people-B’s opinion, and then treating that rather militantly as valid too.
(I’d be able to comment on the rest but the site is, as of writing, outputting JSON instead of something readable, so…) oh hey it loaded again
Unfortunately, the Internet is full of cargo cults built around specific technologies […] and insist that their preferred solution is the secure one
I’m assuming this is intentionally partially hypocritical?
Though it may be tempting for some readers to assign blame
I’m assuming this is intentionally partially hypocritical? The title is “Against”, not “Why I don’t use” or the such.
The author is “against” the protocol, not “against” the developers, hence his statement on “assigning blame”. He’s not trying to get the devs attacked for, what he describes himself in that section;
XMPP was a well-intentioned open protocol and Internet Standard. OMEMO was the least-bad effort to staple encryption onto XMPP.
The biggest annoyance is when keys expire & you come back to a client you haven’t used in a couple of months & now you obviously can’t decrypt new incoming messaging but getting your keys to rotate & other clients to respect it is a giant PITA. Tho this exact problem happens with Matrix clients too being similar ways to get multiple clients communicating with multiple keys (just that the XMPP clients/servers use less resources). Not sure why the hate for PGP in that case then if it can be practically used in this context even if you don’t like the API or infrastructure.
I watched a talk a couple months ago about a post-OMEMO option being discussed & I wish I could find it…
As OMEMO protocol developer here: There is no actionable feedback from this post for developing the OMEMO standard, although I do like that someone made the effort to look into it.
The claim that versions 0.4.0-0.6.0 had 256 bit authentication tags is wrong, it was always truncated to 128 bits. Here’s the version 0.4.0 from the attic: https://xmpp.org/extensions/attic/xep-0384-0.4.0.html#protocol-double_ratchet “Authentication tags are truncated to 16 bytes/128 bits.” What changed in 0.7.0 is only some wording, to make explicit how truncating works. As is already said in the blog post, truncating to 128 bits is considered acceptable.
As a client developer however, I agree that we’re slow to migrate to the current version of OMEMO. Implementations of 0.3.0 are incompatible to 0.4.0 and later, so this would be a migration breaking the ecosystem, making it not an easy undertaking with a dozen of independent client implementations that are mostly developed by free software developers in their spare time.
Thank you for replying constructively here even as there seem to be multiple assumptions making the rounds which suggest there is no constructive response. I think this part of your comment:
As OMEMO protocol developer here: There is no actionable feedback from this post for developing the OMEMO standard, although I do like that someone made the effort to look into it.
deserves more than you gave it. IMO some of the best feedback from @soatok ’s post is:
[OMEMO/XMPP] still doesn’t meet the bar for the kind of private messaging app that Signal is, and is not a viable competitor to Signal.
To understand why this is true, you only need check whether OMEMO is on by default (it isn’t), or whether OMEMO can be turned off even if your client supports it (it can).
Both of these conditions fail the requirements I outlined under the End-to-End Encryption header in that other blog post.
Of course this is not actionable from the perspective of an OMEMO protocol developer. And by saying that, I don’t mean to suggest that their concerns are unfair. They’re just leveled at a different part of the stack than what you’re working on.
The valid point I believe they’re making is that in order to be an app that’s considered in the same bucket as Signal/a competitor to signal, that app needs to have OMEMO turned on by default and needs to be designed so that it can’t be disabled for implementations which support it. Which is to say that these are more “product” points than implementation details for the encryption protocol.
Conversations has red bubbles if you disable omemo in a previously encrypted conversation.
XMPP is not signal: It has most if not all features laypeople want, but most clients are not designed for average joe (unlike signal). Many clients as such trust that you know what to encrypt and what not (why should my personal xmpp bot be forced into using encryption, making the codebase much more complex? etc)
I generally like soatok’s writing, and as a person that likes xmpp and omemo I went into the article with a lot of added open mindedness, but starting the article with this point made it a lot harder to retain that mindset for the rest.
Conversations has red bubbles if you disable omemo in a previously encrypted conversation.
Personally, I don’t think that’s good enough. But more pertinently in the context of the articles being discussed, it 100% doesn’t meet the author’s standards that they articulated here:
when they laid out specifically what it’d take (from their perspective) for something else to constitute a reasonable competitor to signal where it pertains to their friends and family.
XMPP is absolutely not signal. But this post, coupled with the one I linked, is dedicated to explaining what the gap is between XMPP+OMEMO when it comes to soatok’s requirements for their and their friends’ communications. I might not share every one of those requirements, but I don’t think that’s an unfair position to explore when it comes to writing an article like this, at all.
This is mostly a statement on my end that the fact that encryption can be disabled does not mean that the apps make no attempt to draw your attention to this, which is an added nuance not represented in soatok’s post.
Furthermore I think some amount of manualness is needed in omemo actually. Should the default be to trust all keys of a user (or the first new keys)? Let’s say yes, now, what if the user adds a new one? Do we revoke old keys at all? Signal owns the servers so they don’t have to deal with the potential of evil server admins either, but an evil xmpp server can definitely hijack an omemo session by getting its keys trusted (mitm or just additional key).
Matrix has to deal with this to some extent too, and has abysmal encryption UX (“this message cannot be decrypted”, “waiting for this message, this might take a while” etc).
I want signal grade encryption on xmpp, but I’m not sure we can get better than the current state of omemo. If you have ideas I’d love to hear them.
When I said I don’t think it’s good enough personally, I was saying that I believe the right thing for a previously encrypted protocol to do in the face of a conversation that can no longer be encrypted is to reject communications and send you to some other channel, IMO. I think the attempt to draw your attention to it is necessary but not sufficient.
I don’t disagree that some degree of manual management will be needed for a protocol like OMEMO. I think at a product level, how much of it falls to a user vs to a trusted manager is debatable.
For key management, my default position would be that addition of a new key that can be attested by an old one should be visible (and alerted!) to both ends of the e2e communication. Decommissioning old keys should lead to revocation. That may also involve some manual effort.
TBH I’m not sure what the right answer is for the UX overall; for my own use, I liked OTR a lot. It worked like SSH and matched the model I needed. And in that spirit, I land close to the things you’re saying. But if I want my dad to send me encrypted messages, and want to be confident that it’s e2e -> me, it’s harder to find a landing spot that makes me confident it’s safe. Especially if I want to answer the question: what can I instruct him to do that will be safer than iMessage, if we both had phones that do that?
This won’t work anymore as no one will accept that their conversation is now locked to a specific device/client. When I used Facebook Messenger regularly which also had OTR, I never chose encryption for this reason since I was using it thru the browser on 3 devices with 4 OSs, Pidgin/Adium, & the Lite Android client… I would assume most user would demand multi-client support in 2024.
I agree that XMPP+OMEMO clients are probably not on par with Signal in terms of UX and security.
However, I don’t see this as easily said about the protocols. The distinction might be a bit technical, but I have never heard anyone saying “I don’t suggest using HTTPS because Internet Explorer only supports outdated versions and most clients have encryption disabled by default”.
If we focus on the client software criticism, I largely agree with what is said in the blog post and it also is actionable. However, than the story is really more about Conversations and not XMPP+OMEMO, as the title suggests.
So that you can say you have heard it: I think that one should not rely on HTTPS for securing chat, but instead use something as least at secure as SimpleX or Signal.
(Clients making it usable to disable it is only a small part, but is a part. This is my generic advice, in practice applications with comparable security do not cover all common use cases, so sadly it is not yet always possible and my advice for more specific use cases diverges. Also this is advice for a specific set of values, other people have different values, e.g. some want to forbid e2ee.)
A common failure of encryption protocols is to omit from the specification some part that is necessary for users to use them securely. This includes usability requirements on implementations.
One of the principles for secure design is “Psychological acceptability (aka easy to use). The human interface must be designed for ease of use so users will routinely and automatically use the protection mechanisms correctly.” (adapted from The Protection of Information in Computer Systems, Saltzer and Schroeder, 1975)
It seems to me that OMEMO lacks language that disallow compliant clients to send unencrypted messages. Maybe it would need to be another XEP that upgrades it from a SHOULD to a MUST to allow iterative deployment, which OMEMO links to.
As you say that version upgrade would be a “migration breaking the ecosystem”, it also lacks language for how implementations should deal with ecosystem wide protocol upgrades, without breaking it. And if that causes any security considerations. Maybe they would implement both versions for some time.
(I think there is more missing related to the OMEMO spec… and IMHO Signal is not secure enough for the current real world, which requires even more spec work beside of OMEMO, if one wants XMPP to rise to that task.)
Are there any implementations with both the interest and people time that is sufficient to implement it? I don’t know.
So yes the spec needs work (not only the implementations).
Does this make sense to you as a OMEMO protocol developer?
Presumably the tendency of Matthew Hodgson (the Element CEO) and other Matrix supporters to aggressively defend their technology in the comments whenever anyone attempts to criticize it. (I’ve seen this happening for years now, and it even happened to me once!)
The issue here, as Soatok points out, is that the evangelists aren’t willing to engage with the fact that Matrix has real issues, and thus fix them or put their efforts towards something different: instead, they dismiss users’ concerns and insist the issues will surely be fixed soon (while not doing the work or allocating budget to do so), or that the issues simply don’t exist in the first place. (This seems to lead to open source projects that adopt Matrix moving to Discord after the discontent builds, which is depressing.)
Presumably the tendency of Matthew Hodgson (the Element CEO) and other Matrix supporters to aggressively defend their technology in the comments whenever anyone attempts to criticize it. (I’ve seen this happening for years now, and it even happened to me once!)
Personally, from what I’ve observed here on Lobste.rs, HN or Github, Hodgson has always either replied politely or tried to address the criticisms. I never saw him use aggressive language or answer in bad faith. Don’t know about the others though.
The issue here, as Soatok points out, is that the evangelists aren’t willing to engage with the fact that Matrix has real issues, and thus fix them or put their efforts towards something different: instead, they dismiss users’ concerns and insist the issues will surely be fixed soon (while not doing the work or allocating budget to do so), or that the issues simply don’t exist in the first place.
I’ve been usually persuaded by Matthew’s replies, or just saw signs of insufficient manpower behind the project, as a careless observer. I can see how it could be interpreted the way you frame it though.
It is undeniable that, despite the amount of features it has over Signal, the UX is subpar to say the least. Let’s hope that the goals of Matrix 2.0 are achieved!
Presumably the tendency of Matthew Hodgson (the Element CEO) and other Matrix supporters to aggressively defend their technology in the comments whenever anyone attempts to criticize it.
There might have been cases like this but I have seen Matthew Hodgson, multiple times, address FUD. Which I appreciate.
I find some of his points valid, but the very adversarial tone really decreases from the overall technical merit of the article.
That’s what being shouted at by fans of something tends to provoke.
so it’s a good strategy because it makes critique articles less effective?
It seems to work to get attention looking at the number of comments here.
I really don’t read this attitude that others seem to be getting from this post. It seems adversarial, but not overly adversarial. Its about as adversarial as I’d expect a cryptography criticism+critique to be.
I’m a fan of this person and I think their contributions usually make a positive impact but this post was resentful and came across as having bad intent. It made it hard to read.
Yeah, and not the first time from this blogger.
They have a post providing context to this over on Fediverse, which explains the tone: https://furry.engineer/@soatok/112904652315317405
So his answer is to use signal!?
I don’t inherently trust Signal either
Do you think these responses to courts were dishonest? Signal can simultaneously disappoint our expectations about Free Software and also be trusted to not store anything beyond phone numbers and a pair of timestamps.
Yes, they were dishonest. And you can even verify it. Here’s the what the server stores about an account: https://github.com/signalapp/Signal-Server/blob/main/service/src/main/java/org/whispersystems/textsecuregcm/storage/Account.java
Among those is a mapping from the phone number to all the devices the user owns. For each of those devices, the server stores the information if it’s Google, Apple or something else (“user agent”). For Google and Apple it stores a unique push token that can be linked by Google and Apple to their respective accounts (and thus is PII under GDPR and similar legal definitions). As Signal was always able to send push notifications and still is today, we can be certain that even if they don’t use the open source version of the server in their live system (which they are known to have done in the past), we know they are storing those push tokens. They also state it in their privacy policy that they do this (but who reads those when there is a nice “we don’t store, see our published responses to gov” page that claims they don’t store anything).
As an example, in the request https://signal.org/bigbrother/cd-california-grand-jury/ the subpoena specifically included “device data” and “connected applications”. Signal had this data (as seen above), but in their reply they didn’t include it and they even explicitly claim (without any need), that they only have “the time of account creation and the date of the account’s last connection to Signal server”, which as can be seen when looking at the code, is completely wrong.
the claim is about the subset of data as requested by the subpoena, not in general.
Can signal be coerced into releasing an update that weakens the privacy of a huge portion of its users?
Can those individuals defend against it?
Can signal be found out if that happens?
NSL’s force all involved to keep very quiet about their issuance.
In theory, no, because all the relevant code is open source/free software and can be built reproducibly.
In practice, probably. Who knows if people are actually auditing the code and verifying the published builds. But that’s the case for federated software, too. Or, Google Play could be compromised too and forced to distribute doctored builds (you’d still need to compromise Signal to get their signing key). But you’d have the same problem with F-Droid. F-Droid at least can’t target individuals who are using Tor to download APKs because it doesn’t require signin, but individual targeting is not what you asked about.
[Comment removed by moderator pushcx: You two are done in this thread. It doesn't have to be a moral pissing match. Do better next time.]
[Comment removed by moderator pushcx: You two are done in this thread. It doesn't have to be a moral pissing match. Do better next time.]
[Comment removed by moderator pushcx: You two are done in this thread. It doesn't have to be a moral pissing match. Do better next time.]
[Comment removed by moderator pushcx: You two are done in this thread. It doesn't have to be a moral pissing match. Do better next time.]
[Comment removed by moderator pushcx: You two are done in this thread. It doesn't have to be a moral pissing match. Do better next time.]
[Comment removed by moderator pushcx: You two are done in this thread. It doesn't have to be a moral pissing match. Do better next time.]
[Comment removed by moderator pushcx: You two are done in this thread. It doesn't have to be a moral pissing match. Do better next time.]
[Comment removed by moderator pushcx: You two are done in this thread. It doesn't have to be a moral pissing match. Do better next time.]
Looking at his blog archive, he’s been a pretty active Signal shill for a while, and with good reason if you consider the technical parts of Signal, which seems pretty good, compared to what’s out there.
(I’m not an expert in this field, but the reviews of the open-source crypto-engineering of Signal seem positive… but there are also many small weird things around the Signal Foundation.)
(https://furry.engineer/@soatok/112904671642055801)
To me, this is too adversarial. It explains the tone to me, but not exactly justifies it.
On the contrary, experimental (which both versions in question are, so it’s not a question of new/old version) is exactly when one should be doing good-faith analysis and submitting feedback so that the spec can be changed if needed before it is widely relied upon. So finding a problem in an experimental version is good!
Unfortunately, or maybe ‘fortunately’, depending on how you look at it, this is next to impossible in the XMPP ecosystem, where standardization and implementations are not under the control of a single entity.
I’m a little confused on the basic premise, which is XMPP+OMEMO isn’t a Signal competitor because it’s not as good as Signal. Where I’ve typically seen XMPP used is inside of large organizations to either power internal chat systems or as the backend for things like customer service chat. In those situations it seems like OMEMO is a good design because I control both sides of the equation (and often the client in this context is a web client).
I believe the authors point is “if you are looking at migrating off of Telegram towards a different nerdy encrypted chat, Signal is the superior choice to XMPP+OMEMO”. Which is probably true, certainly Signal was designed to do what they are discussing vs XMPP where this functionality was added on. I don’t think that the majority of XMPP users are walking in expecting encryption (but maybe I’m wrong about that).
To me a lot of the criticisms are more understandable in the light of “XMPP serves many purposes”.
XMPP+OMEMO is fine by some other blogger’s random standards, so who is right and who is wrong? Why is one right, and the other wrong?
Reminds me of people saying $X is/is not open source, based on either group-of-people-A’s opinion or group-of-people-B’s opinion, and then treating that rather militantly as valid too.
(I’d be able to comment on the rest but the site is, as of writing, outputting JSON instead of something readable, so…)oh hey it loaded againI’m assuming this is intentionally partially hypocritical?
I’m assuming this is intentionally partially hypocritical? The title is “Against”, not “Why I don’t use” or the such.
The author is “against” the protocol, not “against” the developers, hence his statement on “assigning blame”. He’s not trying to get the devs attacked for, what he describes himself in that section;
The biggest annoyance is when keys expire & you come back to a client you haven’t used in a couple of months & now you obviously can’t decrypt new incoming messaging but getting your keys to rotate & other clients to respect it is a giant PITA. Tho this exact problem happens with Matrix clients too being similar ways to get multiple clients communicating with multiple keys (just that the XMPP clients/servers use less resources). Not sure why the hate for PGP in that case then if it can be practically used in this context even if you don’t like the API or infrastructure.
I watched a talk a couple months ago about a post-OMEMO option being discussed & I wish I could find it…
something about MLS by chance?
I didn’t immediately see the talk I was looking for, but I will at least add this to the queue (again).
lots of solid points. I’m gonna be curious if the XMPP people are as grumpy as the Matrix ones LMAO
As OMEMO protocol developer here: There is no actionable feedback from this post for developing the OMEMO standard, although I do like that someone made the effort to look into it.
The claim that versions 0.4.0-0.6.0 had 256 bit authentication tags is wrong, it was always truncated to 128 bits. Here’s the version 0.4.0 from the attic: https://xmpp.org/extensions/attic/xep-0384-0.4.0.html#protocol-double_ratchet “Authentication tags are truncated to 16 bytes/128 bits.” What changed in 0.7.0 is only some wording, to make explicit how truncating works. As is already said in the blog post, truncating to 128 bits is considered acceptable.
As a client developer however, I agree that we’re slow to migrate to the current version of OMEMO. Implementations of 0.3.0 are incompatible to 0.4.0 and later, so this would be a migration breaking the ecosystem, making it not an easy undertaking with a dozen of independent client implementations that are mostly developed by free software developers in their spare time.
Thank you for replying constructively here even as there seem to be multiple assumptions making the rounds which suggest there is no constructive response. I think this part of your comment:
deserves more than you gave it. IMO some of the best feedback from @soatok ’s post is:
Of course this is not actionable from the perspective of an OMEMO protocol developer. And by saying that, I don’t mean to suggest that their concerns are unfair. They’re just leveled at a different part of the stack than what you’re working on.
The valid point I believe they’re making is that in order to be an app that’s considered in the same bucket as Signal/a competitor to signal, that app needs to have OMEMO turned on by default and needs to be designed so that it can’t be disabled for implementations which support it. Which is to say that these are more “product” points than implementation details for the encryption protocol.
Conversations has red bubbles if you disable omemo in a previously encrypted conversation.
XMPP is not signal: It has most if not all features laypeople want, but most clients are not designed for average joe (unlike signal). Many clients as such trust that you know what to encrypt and what not (why should my personal xmpp bot be forced into using encryption, making the codebase much more complex? etc)
I generally like soatok’s writing, and as a person that likes xmpp and omemo I went into the article with a lot of added open mindedness, but starting the article with this point made it a lot harder to retain that mindset for the rest.
Personally, I don’t think that’s good enough. But more pertinently in the context of the articles being discussed, it 100% doesn’t meet the author’s standards that they articulated here:
https://soatok.blog/2024/07/31/what-does-it-mean-to-be-a-signal-competitor/
when they laid out specifically what it’d take (from their perspective) for something else to constitute a reasonable competitor to signal where it pertains to their friends and family.
XMPP is absolutely not signal. But this post, coupled with the one I linked, is dedicated to explaining what the gap is between XMPP+OMEMO when it comes to soatok’s requirements for their and their friends’ communications. I might not share every one of those requirements, but I don’t think that’s an unfair position to explore when it comes to writing an article like this, at all.
This is mostly a statement on my end that the fact that encryption can be disabled does not mean that the apps make no attempt to draw your attention to this, which is an added nuance not represented in soatok’s post.
Furthermore I think some amount of manualness is needed in omemo actually. Should the default be to trust all keys of a user (or the first new keys)? Let’s say yes, now, what if the user adds a new one? Do we revoke old keys at all? Signal owns the servers so they don’t have to deal with the potential of evil server admins either, but an evil xmpp server can definitely hijack an omemo session by getting its keys trusted (mitm or just additional key). Matrix has to deal with this to some extent too, and has abysmal encryption UX (“this message cannot be decrypted”, “waiting for this message, this might take a while” etc). I want signal grade encryption on xmpp, but I’m not sure we can get better than the current state of omemo. If you have ideas I’d love to hear them.
When I said I don’t think it’s good enough personally, I was saying that I believe the right thing for a previously encrypted protocol to do in the face of a conversation that can no longer be encrypted is to reject communications and send you to some other channel, IMO. I think the attempt to draw your attention to it is necessary but not sufficient.
I don’t disagree that some degree of manual management will be needed for a protocol like OMEMO. I think at a product level, how much of it falls to a user vs to a trusted manager is debatable.
For key management, my default position would be that addition of a new key that can be attested by an old one should be visible (and alerted!) to both ends of the e2e communication. Decommissioning old keys should lead to revocation. That may also involve some manual effort.
TBH I’m not sure what the right answer is for the UX overall; for my own use, I liked OTR a lot. It worked like SSH and matched the model I needed. And in that spirit, I land close to the things you’re saying. But if I want my dad to send me encrypted messages, and want to be confident that it’s e2e -> me, it’s harder to find a landing spot that makes me confident it’s safe. Especially if I want to answer the question: what can I instruct him to do that will be safer than iMessage, if we both had phones that do that?
This won’t work anymore as no one will accept that their conversation is now locked to a specific device/client. When I used Facebook Messenger regularly which also had OTR, I never chose encryption for this reason since I was using it thru the browser on 3 devices with 4 OSs, Pidgin/Adium, & the Lite Android client… I would assume most user would demand multi-client support in 2024.
To be clear, even I, who liked OTR, want multi-client support in 2024.
I agree that XMPP+OMEMO clients are probably not on par with Signal in terms of UX and security.
However, I don’t see this as easily said about the protocols. The distinction might be a bit technical, but I have never heard anyone saying “I don’t suggest using HTTPS because Internet Explorer only supports outdated versions and most clients have encryption disabled by default”.
If we focus on the client software criticism, I largely agree with what is said in the blog post and it also is actionable. However, than the story is really more about Conversations and not XMPP+OMEMO, as the title suggests.
I strongly agree with this.
So that you can say you have heard it: I think that one should not rely on HTTPS for securing chat, but instead use something as least at secure as SimpleX or Signal.
(Clients making it usable to disable it is only a small part, but is a part. This is my generic advice, in practice applications with comparable security do not cover all common use cases, so sadly it is not yet always possible and my advice for more specific use cases diverges. Also this is advice for a specific set of values, other people have different values, e.g. some want to forbid e2ee.)
A common failure of encryption protocols is to omit from the specification some part that is necessary for users to use them securely. This includes usability requirements on implementations.
One of the principles for secure design is “Psychological acceptability (aka easy to use). The human interface must be designed for ease of use so users will routinely and automatically use the protection mechanisms correctly.” (adapted from The Protection of Information in Computer Systems, Saltzer and Schroeder, 1975)
It seems to me that OMEMO lacks language that disallow compliant clients to send unencrypted messages. Maybe it would need to be another XEP that upgrades it from a SHOULD to a MUST to allow iterative deployment, which OMEMO links to.
As you say that version upgrade would be a “migration breaking the ecosystem”, it also lacks language for how implementations should deal with ecosystem wide protocol upgrades, without breaking it. And if that causes any security considerations. Maybe they would implement both versions for some time.
XMPP Compliance Suites 2023 Future Development has language that mentions OMEMO as not yet required, which is too weak.
(I think there is more missing related to the OMEMO spec… and IMHO Signal is not secure enough for the current real world, which requires even more spec work beside of OMEMO, if one wants XMPP to rise to that task.)
Are there any implementations with both the interest and people time that is sufficient to implement it? I don’t know.
So yes the spec needs work (not only the implementations).
Does this make sense to you as a OMEMO protocol developer?
What are you referring to when you say that “Matrix people are grumpy”?
Presumably the tendency of Matthew Hodgson (the Element CEO) and other Matrix supporters to aggressively defend their technology in the comments whenever anyone attempts to criticize it. (I’ve seen this happening for years now, and it even happened to me once!)
The issue here, as Soatok points out, is that the evangelists aren’t willing to engage with the fact that Matrix has real issues, and thus fix them or put their efforts towards something different: instead, they dismiss users’ concerns and insist the issues will surely be fixed soon (while not doing the work or allocating budget to do so), or that the issues simply don’t exist in the first place. (This seems to lead to open source projects that adopt Matrix moving to Discord after the discontent builds, which is depressing.)
Personally, from what I’ve observed here on Lobste.rs, HN or Github, Hodgson has always either replied politely or tried to address the criticisms. I never saw him use aggressive language or answer in bad faith. Don’t know about the others though.
I’ve been usually persuaded by Matthew’s replies, or just saw signs of insufficient manpower behind the project, as a careless observer. I can see how it could be interpreted the way you frame it though. It is undeniable that, despite the amount of features it has over Signal, the UX is subpar to say the least. Let’s hope that the goals of Matrix 2.0 are achieved!
There might have been cases like this but I have seen Matthew Hodgson, multiple times, address FUD. Which I appreciate.