XMPP and metadata
30 points by nicoco
30 points by nicoco
giving friends xmpp boxes with prosody and https://modules.prosody.im/mod_onions has been extremely good just wish clients had better support for http upload with it
Yay, now I have a thing to link to instead of explaining a subset of this every time someone advocates XMPP as a replacement for Signal because 'OMEMO uses the same encryption as Signal'.
For context, the blog author is the maintainer of the most popular python XMPP lib and a TUI client based on it. So if you read this as a "we should bury XMPP" post, you read too fast. ;-)
One of the reason I prefer advocating for XMPP rather than Signal, is that the XMPP enthusiasts are capable of saying out loud what sucks about XMPP. There is no perfect solution, it's always tradeoffs. Anybody can participate in making the protocol and its extensions better, it all happens in the open. Also, and that is the most important point for me, I can host a server on a raspberry pi 2 at home if I want.
ime https://soatok.blog/2024/08/04/against-xmppomemo/ is also a good resource
there's more learning opportunity when you introduce people to well documented protocols, this comment strikes me as anti programmer, rather I don't see many signal users contributing to https://github.com/mollyim/flatline-platform
Nice, I did not know about such ongoing effort. I wish they manage to get an easily runnable service, so I can add some nice automated integration tests to slidgnal. :-)
it's going to take some time, but hopefully I can end up using an alternative server to the main signal ones. They've made it extremely hard to deploy their back end because microservices on aws and azure. https://github.com/mollyim/flatline-platform/blob/main/docs/architecture.md
One thing that's somewhat frustrating is with signal it's extremely hard to get users to learn about how the messaging protocol works because at this point it might as well be black magic. Also signal requires you to use a key generated on your phone as the main key.
Also signal requires you to use a key generated on your phone as the main key.
It is possible to generate such key via signal-cli which can act as the main device.
Did I misread? EDIT: yes I did. Reader mode cut out a lot of the text!
I took away that mathieui is arguing XMPP metadata is problem of server trust -- same as it is for signal (and it's AWS/Azure hosting).
"passive" threats on metadata for XMPP: A server compromise [present + future ....] an attacker present on the server network; An attacker on the client (your) network
[.......]
Nonetheless, their [Signal's] messenger is centralized, with systems running on AWS and Azure (as far as I can tell), which makes them very dependent on the US political wasteland as well as the tech landlords’ whims.
[...] I trust them for now, their servers certainly have a lot of opportunities to collect and store a ton of metadata, simply due to the fact that this is a centralized system
I thought this article was very useful. I would have also appreciated a brief discussion of what metadata leakage XEP-0420: Stanza Content Encryption would and would not reduce.
XEP-0420 would make it possible to encrypt everything that is not in the <body> of a message. It practice, with current classic usage, AFAIK, it would mostly encrypt reactions (XEP-0444).
A lot of it. But not to/from (since not even signal can operate without those in practise. Though an onion routing protocol could) and not certain timing things.