Hello. I am looking for an alternative to Telegram and I prefer an application that uses decentralised servers. My question is: why is the xmpp+omemo protocol not recommended on websites when it is open source and decentralised? The privacyguides.org website does not list xmpp+omemo as a recommended messaging service. Nor does this website include it in its comparison of private messaging services.

https://www.privacyguides.org/en/assets/img/cover/real-time-communication.webp

Why do you think xmpp and its messaging clients such as Conversations, Movim, Gajim, etc. do not appear in these guides?

  • theherk@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    15 days ago

    It isn’t a meme. It is a fact of modern cryptography in many settings. For example TLS, which is a huge bulk of the traffic, guarantees again privacy not anonymity. I’m not saying one shouldn’t care about metadata privacy. Every communication one engages in requires risk benefit analysis. If your threat modeling shows that for a given message, anonymity is required, then signal, and nearly every single other protocol out there is insufficient.

    That doesn’t mean TLS or lib signal, or any other cryptographic tool is not useful, especially in conjunction with other tools.

    There are many cases where I want my messages to be private and the cost of entry for the message receiver to be low. Signal is great for that. But I’m not saying no other tools should be considered, just that signal is good at what it does.

    • Arthur Besse@lemmy.ml
      link
      fedilink
      English
      arrow-up
      1
      ·
      15 days ago

      “Anonymity” is a vague term which you introduced to this discussion; I’m talking about metadata privacy which is a much clearer concept.

      TLS cannot prevent an observer from seeing the source and destination IPs, but it does include some actually-useful metadata mitigations such as Encrypted Client Hello, which encrypts (among other things) the Server Name Indicator. ECH a very mild mitigation, since the source and destination IPs are intrinsically out of scope for protection by TLS, but unlike Sealed Sender it is not an entirely theatrical use of cryptography: it does actually prevent an on-path observer from learning the server hostname (at least, if used alongside some DNS privacy system).

      The on path part is also an important detail here: the entire world’s encrypted TLS traffic is not observable from a single choke point the way that the entire world’s Signal traffic is.