6 ms·

With XMPP I can run (and audit) eveything myself. You can't do this with Signal. Some proprietary messenger that's hostile to 3rd party clients aswell as also w

With XMPP I can run (and audit) eveything myself. You can't do this with Signal. Some proprietary messenger that's hostile to 3rd party clients aswell as also wanting my phone number will never compete with tried and tested open source technology like XMPP. There is a reason military and government orgs use their own infrastructure.

some_furry 2y ago
> With XMPP I can run (and audit) eveything myself. You're saying this in response a blog post where I basically did an over-the-weekend audit of Signal's cryptography. I don't know if you understand the irony of that. > Some proprietary messenger It's literally GPL free and open source software > that's hostile to 3rd party clients I disagree with Moxie on his stance about XMPP + federation, as I wrote about here (relating to my plans to build E2EE for the Fediverse): https://soatok.blog/2024/08/28/introducing-alacrity-to-federated-cryptography/ https://soatok.blog/2024/08/28/introducing-alacrity-to-feder... > aswell as also wanting my phone number I dislike this as well, but since the introduction of usernames, it's at least no longer required to give strangers your phone number to converse with them. > will never compete with tried and tested open source technology like XMPP. The converse is true: XMPP+OMEMO do not qualify as a Signal competitor. I've outlined my reasoning in the linked post. Until the entire ecosystem uses the latest version of the protocol, encryption is always on, and there is no plaintext fallback, XMPP is a poor solution for private communications. > There is a reason military and government orgs use their own infrastructure. Are you insisting that XMPP is "military grade encryption"?
- grayhatter 2y ago
  > Are you insisting that XMPP is "military grade encryption"? I don't think that's the fair implication there, and I'd also hope you'd pull out "military grade" as a red herring, as meaningless marketing speak and ignore it instead of trying to trap someone using it. (unless it was a primary point they made, critical to their position, clearly not the case here)
- alt187 2y ago
  You can't trust the server on Signal. Anything else, especially theoretical navel-gazing about plaintext fallbacks or make-believe audits of the client half of the system is inconsequential against the simple fact: You can't trust the server on Signal.
  - hmmm-i-wonder 2y ago
    You don't have to. Reproducible builds, audited E2E and the other technical details combine to remove the need to trust the server for anything other than availability. Anything else is uninformed navel-gazing about the risk without understanding the subject.
    - impossiblefork 2y ago
      But the server on signal may store who communicates with whom. The most important information of all; and they can even connect that to phone numbers, so they've basically got everbody's real names.
      - some_furry 2y ago
        You should take a closer look at Sealed Sender and the zkgroup stuff. I've explained in another comment but, it effectively hides who's actually communicating with who.
        impossiblefork 2y ago
        Neither of those have anything to do with that kind of security. The preparation process for sealed sender looks very complicated and iffy, but maybe someone has checked that the protocol is secure-- I don't see any reason for such a complicated procedure, and I see such complicated procedures as something which can only be intended to hide insecurity, but let's assume it is. You still have connect to them and deliver this to the signal servers. They'll have your IP and will know approximately where you are physically. There is no way to make this kind of thing secure without some kind of remailer system and without many peer-to-peer connections. Almost all proper anonymous remailers have been shut down. What remains, Tor for example, are insecure parodies of an anonymous remailer, and this is justified to the users as being for the sake of speed, but makes the system useless for anonymity. Even Mixminion is insecure if you can observe the full network, since you can count the packets received by the clients and there aren't dummy packets.
- deleted 2y ago
  [deleted]
mardifoufs 2y ago
Sure, if self hosting is the most important criteria for you, you can't really beat XMPP. Same goes for a richer ecosystem of 3rd party clients. But those two are completely unrelated to security. I mean a self hosted solution can be secure, but it's weird to say that Signal can't compete with XMPP on security because it's not self hostable.
- grayhatter 2y ago
  > but it's weird to say that Signal can't compete with XMPP on security because it's not self hostable. No it's not. If I could conditionally control if your messages are delivered, and when. Even if I can't see the contents, that's a huge security vulnerability!
  - hmmm-i-wonder 2y ago
    You can't control when "someones" messages are delivered, only when "all" messages are delivered. I.E Signal servers control general availability, not selective availability. Moving to a self-hosted service most likely introduces more risk at this point assuming you can keep the service and all related infrastructure up to date and monitored 24/7/365
    - grayhatter 2y ago
      > You can't control when "someones" messages are delivered, only when "all" messages are delivered. I.E Signal servers control general availability, not selective availability. this is the first I've heard this, got a source to prove this is actually true? > Moving to a self-hosted service most likely introduces more risk at this point assuming you can keep the service and all related infrastructure up to date and monitored 24/7/365 That's not how threat models work, it's not 'more' risk. It's additional work. The risk is the same, signal has to do it, or 'you' have to do it. The risk and level of effort is the same. The only thing that changes is the direct responsibile party. Depending on configuration, it might reduce the risk if you can lower the number of parties you have to trust. I.e. I can verify my servers are up to date, but I have to just trust me bro, that signal's servers are always up to date.

some_furry 2y ago

> With XMPP I can run (and audit) eveything myself. You're saying this in response a blog post where I basically did an over-the-weekend audit of Signal's cryptography. I don't know if you understand the irony of that. > Some proprietary messenger It's literally GPL free and open source software > that's hostile to 3rd party clients I disagree with Moxie on his stance about XMPP + federation, as I wrote about here (relating to my plans to build E2EE for the Fediverse): https://soatok.blog/2024/08/28/introducing-alacrity-to-federated-cryptography/ https://soatok.blog/2024/08/28/introducing-alacrity-to-feder... > aswell as also wanting my phone number I dislike this as well, but since the introduction of usernames, it's at least no longer required to give strangers your phone number to converse with them. > will never compete with tried and tested open source technology like XMPP. The converse is true: XMPP+OMEMO do not qualify as a Signal competitor. I've outlined my reasoning in the linked post. Until the entire ecosystem uses the latest version of the protocol, encryption is always on, and there is no plaintext fallback, XMPP is a poor solution for private communications. > There is a reason military and government orgs use their own infrastructure. Are you insisting that XMPP is "military grade encryption"?

grayhatter 2y ago
> Are you insisting that XMPP is "military grade encryption"? I don't think that's the fair implication there, and I'd also hope you'd pull out "military grade" as a red herring, as meaningless marketing speak and ignore it instead of trying to trap someone using it. (unless it was a primary point they made, critical to their position, clearly not the case here)
alt187 2y ago
You can't trust the server on Signal. Anything else, especially theoretical navel-gazing about plaintext fallbacks or make-believe audits of the client half of the system is inconsequential against the simple fact: You can't trust the server on Signal.
- hmmm-i-wonder 2y ago
  You don't have to. Reproducible builds, audited E2E and the other technical details combine to remove the need to trust the server for anything other than availability. Anything else is uninformed navel-gazing about the risk without understanding the subject.
  - impossiblefork 2y ago
    But the server on signal may store who communicates with whom. The most important information of all; and they can even connect that to phone numbers, so they've basically got everbody's real names.
    - some_furry 2y ago
      You should take a closer look at Sealed Sender and the zkgroup stuff. I've explained in another comment but, it effectively hides who's actually communicating with who.
      - impossiblefork 2y ago
        Neither of those have anything to do with that kind of security. The preparation process for sealed sender looks very complicated and iffy, but maybe someone has checked that the protocol is secure-- I don't see any reason for such a complicated procedure, and I see such complicated procedures as something which can only be intended to hide insecurity, but let's assume it is. You still have connect to them and deliver this to the signal servers. They'll have your IP and will know approximately where you are physically. There is no way to make this kind of thing secure without some kind of remailer system and without many peer-to-peer connections. Almost all proper anonymous remailers have been shut down. What remains, Tor for example, are insecure parodies of an anonymous remailer, and this is justified to the users as being for the sake of speed, but makes the system useless for anonymity. Even Mixminion is insecure if you can observe the full network, since you can count the packets received by the clients and there aren't dummy packets.
deleted 2y ago
[deleted]

mardifoufs 2y ago

Sure, if self hosting is the most important criteria for you, you can't really beat XMPP. Same goes for a richer ecosystem of 3rd party clients. But those two are completely unrelated to security. I mean a self hosted solution can be secure, but it's weird to say that Signal can't compete with XMPP on security because it's not self hostable.

grayhatter 2y ago
> but it's weird to say that Signal can't compete with XMPP on security because it's not self hostable. No it's not. If I could conditionally control if your messages are delivered, and when. Even if I can't see the contents, that's a huge security vulnerability!
- hmmm-i-wonder 2y ago
  You can't control when "someones" messages are delivered, only when "all" messages are delivered. I.E Signal servers control general availability, not selective availability. Moving to a self-hosted service most likely introduces more risk at this point assuming you can keep the service and all related infrastructure up to date and monitored 24/7/365
  - grayhatter 2y ago
    > You can't control when "someones" messages are delivered, only when "all" messages are delivered. I.E Signal servers control general availability, not selective availability. this is the first I've heard this, got a source to prove this is actually true? > Moving to a self-hosted service most likely introduces more risk at this point assuming you can keep the service and all related infrastructure up to date and monitored 24/7/365 That's not how threat models work, it's not 'more' risk. It's additional work. The risk is the same, signal has to do it, or 'you' have to do it. The risk and level of effort is the same. The only thing that changes is the direct responsibile party. Depending on configuration, it might reduce the risk if you can lower the number of parties you have to trust. I.e. I can verify my servers are up to date, but I have to just trust me bro, that signal's servers are always up to date.