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?
Yes, subpoena was poorly worded. NSL is more likely. But still it is a time-forward threat, which means there is value while the server is or was accepting sealed sender.
And I wasn’t suggesting timing attack is required to defeat sealed sender. I was, on the contrary, pointing out that was a threat even with sealed sender. Though that is non-trivial, especially with CGNAT.
So in summary. You’re right. Sealed sender is not a great solution. But it is a mitigation for the period where those messages are being accepted. A better solution is probably out there. I hope somebody implements it. In the meantime, for somebody who needs that level of metadata privacy, Signal isn’t the solution; maybe cwtch or briar.
Thanks :)
But, I still maintain it is entirely useless - its only actual use is to give users the false impression that the server is unable to learn the social graph. It is 100% snake oil.
It sounds like you’re assuming that, prior to sealed sender, they were actually storing the server-visible sender information rather than immediately discarding it after using it to authenticate the sender? They’ve always said that they weren’t doing that, but, if they were, they could have simply stopped storing that information rather than inventing their “sealed sender” cryptographic construction.
To recap: Sealed sender ostensibly exists specifically to allow the server to verify the sender’s permission to send without needing to know the sender identity. It isn’t about what is being stored (as they could simply not store the sender information), it is about what is being sent. As far as I can tell it only makes any sense if one imagines that a malicious server somehow would not simply infer the senders’ identities from their (obviously already identified) receiver connections from the same IPs.