I want to point out that the author of that linked blog, Soatok, actually removed a response in the comments from an OMEMO developer which clarified some things, which personally I think was rather odd/bad faith of them to do. When asked about it, this was their response:
“I’ll make an edit later about the protocol version thing, but I’m not interested in having questions answered. My entire horse in this race is for evangelists to f** off and leave me alone. That’s it. That’s all I want.”
According to the OMEMO developer in his response (you can it read here), there’s nothing really wrong with OMEMO 0.3.0, as the dev considers it a stable standard that clients can safely implement, with newer versions basically being public beta releases toward a stable ‘OMEMO 2’ standard that can eventually replace 0.3.0.
I didn’t know about this response, thank you for pointing it out. However, this response fails to address the main criticism of the XMPP+ONEMO:
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.
And that’s all that I should have needed to say on the matter.
If someone’s threat model requires absolute always-on encryption, then XMPP does currently fail that standard, but each individual will have to determine if their threat model does infact require that, and contrast it with the potential benefits XMPP currently has compared to the more secure options.
As an example, all of the always-on E2EE alternatives are really only a good alternative to messengers like whatsapp, there is currently no always-on messenger that could potentially replace the feature set of Discord, where as with the XMPP Movim client, that is currently possible due to the recent implementation of Discord-like spaces (single communities/channels with groups of rooms and drop-in chats).
For a discord community or for friends that want discord-like features, XMPP is leagues better for privacy, even though it only has optional encryption. It also offers true a decentralized federated network, which allows for more control of how your encrypted or unencrypted data is shared.
Unfortunately there’s no perfect answer for all messenger needs, so each will need to have their pros and cons weighed on a case by case basis.
Ha, thanks, I’d already read that. And I do, mostly, agree; the OMEMO implementation is not great both from the security perspective discussed in the post, as well as the UX (not being able to decrypt old messages on new devices at all).
That being said, I primarily want a selfhosted, federated messenger which also takes privacy and security seriously, and at least for the former, XMPP is really refreshingly good.
Yeah no shit you already read it they post it every single time. I don’t think any of them have actually read it, the problems he is complaining about were solved ages ago or by two clicks, once. The guy actually argues for people to use Telegram because they have disabilities and software is hard. An absolute masterclass.
Unfortunately, it is not.
I want to point out that the author of that linked blog, Soatok, actually removed a response in the comments from an OMEMO developer which clarified some things, which personally I think was rather odd/bad faith of them to do. When asked about it, this was their response:
According to the OMEMO developer in his response (you can it read here), there’s nothing really wrong with OMEMO 0.3.0, as the dev considers it a stable standard that clients can safely implement, with newer versions basically being public beta releases toward a stable ‘OMEMO 2’ standard that can eventually replace 0.3.0.
Also @smiletolerantly@awful.systems.
I didn’t know about this response, thank you for pointing it out. However, this response fails to address the main criticism of the XMPP+ONEMO:
If someone’s threat model requires absolute always-on encryption, then XMPP does currently fail that standard, but each individual will have to determine if their threat model does infact require that, and contrast it with the potential benefits XMPP currently has compared to the more secure options.
As an example, all of the always-on E2EE alternatives are really only a good alternative to messengers like whatsapp, there is currently no always-on messenger that could potentially replace the feature set of Discord, where as with the XMPP Movim client, that is currently possible due to the recent implementation of Discord-like spaces (single communities/channels with groups of rooms and drop-in chats).
For a discord community or for friends that want discord-like features, XMPP is leagues better for privacy, even though it only has optional encryption. It also offers true a decentralized federated network, which allows for more control of how your encrypted or unencrypted data is shared.
Unfortunately there’s no perfect answer for all messenger needs, so each will need to have their pros and cons weighed on a case by case basis.
Ha, thanks, I’d already read that. And I do, mostly, agree; the OMEMO implementation is not great both from the security perspective discussed in the post, as well as the UX (not being able to decrypt old messages on new devices at all).
That being said, I primarily want a selfhosted, federated messenger which also takes privacy and security seriously, and at least for the former, XMPP is really refreshingly good.
Yeah no shit you already read it they post it every single time. I don’t think any of them have actually read it, the problems he is complaining about were solved ages ago or by two clicks, once. The guy actually argues for people to use Telegram because they have disabilities and software is hard. An absolute masterclass.