• SwooshBakery624 [they/them]@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    19 hours ago

    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.

    • ProdigalFrog@slrpnk.net
      link
      fedilink
      English
      arrow-up
      1
      ·
      14 hours ago

      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.