5 ms·

Also relevant https://soatok.blog/2024/08/04/against-xmppomemo/ https://soatok.blog/2024/08/04/against-xmppomemo/ recently. It's quite critical of some of the

by dngray 2y ago

Also relevant https://soatok.blog/2024/08/04/against-xmppomemo/ https://soatok.blog/2024/08/04/against-xmppomemo/ recently. It's quite critical of some of the code quality of common implementations as well as the fracturing across different clients. As for Matrix, probably element is the main client you want to use. I use Nheko on Linux.

AshamedCaptain 2y ago
I have criticized omemo in the past -- it breaks backwards compatibility way too readily resulting in XMPP clients not being able to talk to each other in levels that I hadn't seen since the Jingle debacles. However I just can't stand this article's tone (the accompanying imagery doesn't help), and then he has the balls to complain about the rude response he gets from the spec authors (even showing it off as if to elicit empathy from the reader), when if anything my impression is that his article itself is way more disrespectful. He keeps criticizing one client while trying to pass it off as criticism of the specification (said client doesn't even implement the latest version of the specification, either), complains about the protocol changing too much and the protocol changing too little, and to top it off seems to promote Signal as the better alternative, completely missing the elephant in the room -- Signal being centralized with its decisions even more whimsical at the hands of one group only. Curiously, he does that right after criticizing omemo's choice to follow Signal's choices as lacking justification.
- dngray 2y ago
  The main reason we won't list it on privacyguides.org is the encryption is not always on by default. There are two major problems, the implementations and the fact the spec isn't specific. I'm not particularly bothered by the imaginary, the dude is a furry what do you expect? Some furry bloggers do have pictures throughout their blog posts to split things up and lighten things. As for the reply from the spec author, I had a negative opinion of that. To me it looks like they just tried to copy signal's encryption so that people could claim that XMPP has E2EE, without any real design or thought of the implementation. One of the other things I hate about XMPP (and you mentioned it above with the jingle debacle), but there are other cases where there's multiple XEPs for the same thing. Some of them are widely used despite being marked as "experimental". The documents are not cohesive and is a mess which is probably why the implementations are also bad (unlike the Matrix spec). Encryption is just another one of those things, just like file transfer. If I was deciding on a new project to develop a client for XMPP would be the least attractive project for me to work on. Put it that way. Without enthusiastic developers that think this thing sounds cool there simply won't be any good software. The other thing also not mentioned is that the OMEMO encryption only applies to text messages and not all the other things, ie VOIP, status changes etc. There is a fair bit of metadata on the server side https://web.archive.org/web/20211215132539/https://infosec-handbook.eu/articles/xmpp-aitm/ https://web.archive.org/web/20211215132539/https://infosec-h... and attacks like this are just downright scary https://notes.valdikss.org.ru/jabber.ru-mitm/ https://notes.valdikss.org.ru/jabber.ru-mitm/ I used to use XMPP but haven't in about a decade. Nobody I know uses it either. (Even the couple of evangelists I knew moved to Matrix long ago)
  - AshamedCaptain 2y ago
    > the dude is a furry what do you expect? Some furry bloggers do have pictures throughout their blog posts to split things up and lighten things. Lighten things? Are you saying that putting images of cartoon characters puking at the logos of your product lightens things and provokes healthy discussion? Don't try to make this into thinking I'm criticizing furriness -- it's definitely not about that. > There is a fair bit of metadata on the server side This is much less critical when the protocol is federated. Even E2EE itself may become second priority rather than first in such an environment. > Without enthusiastic developers that think this thing sounds cool there simply won't be any good software. This is a ridiculous statement.
    - dngray 2y ago
      > This is much less critical when the protocol is federated False. Federated protocols typically have a lot more, as there is routing data between servers. The same goes for things like Matrix. The only thing that Matrix servers can see however realistically is the room id, and other participants. Unlike XMPP where they can copy your roster. In the case of ejabberd debug logs can include your password lol (or at least could in November 2021). I doubt that's changed.
      - AshamedCaptain 2y ago
        Routing data between servers and networks you literally control. There is simply no possible discussion on this point. A centralized service doesn't allow that choice. Leaking metadata to a centralized service is simply inevitable by pure physics.
        dngray 2y ago
        > Routing data between servers and networks you literally control This isn't always the case, not every user is a server admin. Also for group chats other server admins will certainly know what data your requesting. TLDR is that XMPP is not a private protocol, and that was never its intention. It was actually very centralized in it's original usage and the designers clearly envisaged similar usage to email ie $companyA.com employees talking to $companyB.com not some sort of "private messenger" competitor to Matrix or Signal which were meant to be used by the wider general population. > Leaking metadata to a centralized service is simply inevitable by pure physics Not necessarily true https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/ Signal has a lot less metadata than XMPP.
- upofadown 2y ago
  This sort of rant is unfortunately fairly common in the world of cryptography. Things can be mostly driven by what the writer feels about other people working in the same space. So they attack their technology as a way to attack them. Note that the author of the linked article complains about getting the same sort of article in reply. That is also common...
- nearlyepic 2y ago
  > He keeps criticizing one client while trying to pass it off as criticism of the specification Can you point out where this happens? I didn't come away with this impression at all.
inputmice 2y ago
> Also relevant https://soatok.blog/2024/08/04/against-xmppomemo/ https://soatok.blog/2024/08/04/against-xmppomemo/ recently. Signal, Matrix, Telegram, XMPP; Use whatever you want. But there is a lot of FUD if not outright lies in that blog post. The author looked at Conversations for all but five minutes, desperately trying to dig up some dirt.
- Kye 2y ago
  >> "But there is a lot of FUD if not outright lies in that blog post. " For example...
  - inputmice 2y ago
    * Conversations uses two different OpenPGP implementations. (It doesn’t) * The auth tag truncation was 'silently' introduced in the spec. It wasn’t. The author retracted that but only barely * ominously pointing out that Conversations has a SASL implementation (In fact Conversations can use that to detect some MITM attacks; which is pretty cool) * ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS)
    - some_furry 2y ago
      > * ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS) It's trivial to use TLS without writing your own certificate parser. Doing this means taking on a lot of unnecessary risk, such as CVE-2023-33202. Your encrypted messaging application shouldn't need to have a separate X.509 or ASN.1 parser built into it. If you're going to use them from TLS, you should rely on the library your OS vendor maintains for you, since they have an incentive to keep theirs secure anyway. "Ominously pointing out" that the Conversations project has taken on an unhealthy amount of complexity and risk isn't FUD, it's a criticism of how the project is managed. Confuse the two at your own peril.
      - inputmice 2y ago

by dngray 2y ago

AshamedCaptain 2y ago

I have criticized omemo in the past -- it breaks backwards compatibility way too readily resulting in XMPP clients not being able to talk to each other in levels that I hadn't seen since the Jingle debacles. However I just can't stand this article's tone (the accompanying imagery doesn't help), and then he has the balls to complain about the rude response he gets from the spec authors (even showing it off as if to elicit empathy from the reader), when if anything my impression is that his article itself is way more disrespectful. He keeps criticizing one client while trying to pass it off as criticism of the specification (said client doesn't even implement the latest version of the specification, either), complains about the protocol changing too much and the protocol changing too little, and to top it off seems to promote Signal as the better alternative, completely missing the elephant in the room -- Signal being centralized with its decisions even more whimsical at the hands of one group only. Curiously, he does that right after criticizing omemo's choice to follow Signal's choices as lacking justification.

dngray 2y ago
The main reason we won't list it on privacyguides.org is the encryption is not always on by default. There are two major problems, the implementations and the fact the spec isn't specific. I'm not particularly bothered by the imaginary, the dude is a furry what do you expect? Some furry bloggers do have pictures throughout their blog posts to split things up and lighten things. As for the reply from the spec author, I had a negative opinion of that. To me it looks like they just tried to copy signal's encryption so that people could claim that XMPP has E2EE, without any real design or thought of the implementation. One of the other things I hate about XMPP (and you mentioned it above with the jingle debacle), but there are other cases where there's multiple XEPs for the same thing. Some of them are widely used despite being marked as "experimental". The documents are not cohesive and is a mess which is probably why the implementations are also bad (unlike the Matrix spec). Encryption is just another one of those things, just like file transfer. If I was deciding on a new project to develop a client for XMPP would be the least attractive project for me to work on. Put it that way. Without enthusiastic developers that think this thing sounds cool there simply won't be any good software. The other thing also not mentioned is that the OMEMO encryption only applies to text messages and not all the other things, ie VOIP, status changes etc. There is a fair bit of metadata on the server side https://web.archive.org/web/20211215132539/https://infosec-handbook.eu/articles/xmpp-aitm/ https://web.archive.org/web/20211215132539/https://infosec-h... and attacks like this are just downright scary https://notes.valdikss.org.ru/jabber.ru-mitm/ https://notes.valdikss.org.ru/jabber.ru-mitm/ I used to use XMPP but haven't in about a decade. Nobody I know uses it either. (Even the couple of evangelists I knew moved to Matrix long ago)
- AshamedCaptain 2y ago
  > the dude is a furry what do you expect? Some furry bloggers do have pictures throughout their blog posts to split things up and lighten things. Lighten things? Are you saying that putting images of cartoon characters puking at the logos of your product lightens things and provokes healthy discussion? Don't try to make this into thinking I'm criticizing furriness -- it's definitely not about that. > There is a fair bit of metadata on the server side This is much less critical when the protocol is federated. Even E2EE itself may become second priority rather than first in such an environment. > Without enthusiastic developers that think this thing sounds cool there simply won't be any good software. This is a ridiculous statement.
  - dngray 2y ago
    > This is much less critical when the protocol is federated False. Federated protocols typically have a lot more, as there is routing data between servers. The same goes for things like Matrix. The only thing that Matrix servers can see however realistically is the room id, and other participants. Unlike XMPP where they can copy your roster. In the case of ejabberd debug logs can include your password lol (or at least could in November 2021). I doubt that's changed.
    - AshamedCaptain 2y ago
      Routing data between servers and networks you literally control. There is simply no possible discussion on this point. A centralized service doesn't allow that choice. Leaking metadata to a centralized service is simply inevitable by pure physics.
      - dngray 2y ago
        > Routing data between servers and networks you literally control This isn't always the case, not every user is a server admin. Also for group chats other server admins will certainly know what data your requesting. TLDR is that XMPP is not a private protocol, and that was never its intention. It was actually very centralized in it's original usage and the designers clearly envisaged similar usage to email ie $companyA.com employees talking to $companyB.com not some sort of "private messenger" competitor to Matrix or Signal which were meant to be used by the wider general population. > Leaking metadata to a centralized service is simply inevitable by pure physics Not necessarily true https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/ Signal has a lot less metadata than XMPP.
upofadown 2y ago
This sort of rant is unfortunately fairly common in the world of cryptography. Things can be mostly driven by what the writer feels about other people working in the same space. So they attack their technology as a way to attack them. Note that the author of the linked article complains about getting the same sort of article in reply. That is also common...
nearlyepic 2y ago
> He keeps criticizing one client while trying to pass it off as criticism of the specification Can you point out where this happens? I didn't come away with this impression at all.

inputmice 2y ago

> Also relevant https://soatok.blog/2024/08/04/against-xmppomemo/ https://soatok.blog/2024/08/04/against-xmppomemo/ recently. Signal, Matrix, Telegram, XMPP; Use whatever you want. But there is a lot of FUD if not outright lies in that blog post. The author looked at Conversations for all but five minutes, desperately trying to dig up some dirt.

Kye 2y ago
>> "But there is a lot of FUD if not outright lies in that blog post. " For example...
- inputmice 2y ago
  * Conversations uses two different OpenPGP implementations. (It doesn’t) * The auth tag truncation was 'silently' introduced in the spec. It wasn’t. The author retracted that but only barely * ominously pointing out that Conversations has a SASL implementation (In fact Conversations can use that to detect some MITM attacks; which is pretty cool) * ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS)
  - some_furry 2y ago
    > * ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS) It's trivial to use TLS without writing your own certificate parser. Doing this means taking on a lot of unnecessary risk, such as CVE-2023-33202. Your encrypted messaging application shouldn't need to have a separate X.509 or ASN.1 parser built into it. If you're going to use them from TLS, you should rely on the library your OS vendor maintains for you, since they have an incentive to keep theirs secure anyway. "Ominously pointing out" that the Conversations project has taken on an unhealthy amount of complexity and risk isn't FUD, it's a criticism of how the project is managed. Confuse the two at your own peril.
    - inputmice 2y ago