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?

you are viewing a single comment's thread
view the rest of the comments

[–] cypherpunks@lemmy.ml 3 points 1 day ago (1 children)

"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.

[–] theherk@lemmy.world 2 points 23 hours ago (1 children)

Don’t mistake me for saying you’re wrong. I agree with you, mostly. But sealed sender isn’t theater, in my view. It is a best effort attempt to mitigate one potential threat. I think everybody would like that solved but actually solving it isn’t easy as I understand it. Maybe not intractable, but if you have a solution, you can implement it. That is one of the things I like about free software.

In any case, I’m only saying Signal is good for a subset of privacy concerns. Certainly not that it is the best solution in all cases.

[–] cypherpunks@lemmy.ml 1 points 23 hours ago (1 children)

sealed sender isn’t theater, in my view. It is a best effort attempt to mitigate one potential threat

But, what is the potential threat which is mitigated by sealed sender? Can you describe a specific attack scenario (eg, what are the attacker's goals, and what capabilities do you assume the attacker has) which would be possible if Signal didn't have sealed sender but which is no longer possible because sealed sender exists?

[–] theherk@lemmy.world 2 points 23 hours ago (1 children)

Sure. If a state serves a subpoena to gather logs for metadata analysis, sealed sender will prevent associating senders to receivers, making this task very difficult.

On the other hand, what it doesn’t address is if the host itself is compromised where sealed sender can be disabled allowing such analysis (not posthoc though). This is also probably sensitive to strong actors with sufficient resources via a timing attack.

But still, as long as the server is accepting sealed sender messages the mitigation is useful.

[–] cypherpunks@lemmy.ml 1 points 23 hours ago* (last edited 23 hours ago) (1 children)

Sure. If a state serves a subpoena to gather logs for metadata analysis, sealed sender will prevent associating senders to receivers, making this task very difficult.

Pre sealed-sender they already claimed not to keep metadata logs, so, complying with such a subpoena^[it would more likely be an NSL or some other legal instrument rather than a subpoena] should already have required them to change the behavior of their server software.

If a state wanted to order them to add metadata logging in a non-sealed-sender world, wouldn't they also probably ask them to log IPs for all client-server interactions (which would enable breaking sealed-sender through a trivial correlation)?

Note that defeating sealed sender doesn't require any kind of high-resolution timing or costly analysis; with an adversary-controlled server (eg, one where a state adversary has compelled the operator to alter the server's behavior via a National Security Letter or something) it is easy to simply record the IP which sent each "sealed" message and also record which account(s) are checked from which IPs at all times.

[–] theherk@lemmy.world 1 points 22 hours ago (1 children)

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.

[–] cypherpunks@lemmy.ml 1 points 1 hour ago* (last edited 1 hour ago)

So in summary. You’re right. Sealed sender is not a great solution. But

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 is a mitigation for the period where those messages are being accepted.

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.