4 ms·
> 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 cryp
by 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 agoYou 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 agoYou 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 agoBut 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 agoYou 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 agoNeither 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.
- 2y ago
- deleted 2y ago[deleted]