49 ms·

XMPP: The secure communication protocol that respects privacy

284 points by neustradamus 5y ago

edhelas 5y ago
Hi! Glad to see XMPP on the HN first page this morning :) I'm working on a social-network and IM web platform (for 12 years already!), fully built on XMPP https://movim.eu/ https://movim.eu/. Thanks to its extensibility and the PubSub XMPP standard (see https://xmpp.org/extensions/xep-0060.html https://xmpp.org/extensions/xep-0060.html) you can easily build social-network like features. The standard is pretty simple, it's Atom 1.0 transport within PubSub (see https://xmpp.org/extensions/xep-0277.html https://xmpp.org/extensions/xep-0277.html). For those that likes RSS/Atom you can also easily publish Atom newsfeed to PubSub (see https://github.com/edhelas/atomtopubsub https://github.com/edhelas/atomtopubsub) and follow your favorite website using your XMPP account and with real-time pushed articles. Here is ArsTechnica as an example https://mov.im/?node/news.movim.eu/ArsTechnica https://mov.im/?node/news.movim.eu/ArsTechnica XMPP is not only for IM, but way more than that ;)
- yosamino 5y ago
  I've seen movim around but I have never actually tried it. This post gave me the push. So thank you for that. I do have a question though: On https://mov.im/?login https://mov.im/?login it says: "Login using any XMPP account or create a new one" But it only shows me a login form where I can enter my xmpp address and a password. This signals to me that I can log into my existing non-movim-xmpp account, but I have to enter my password on there? That can't be right. What am I misunderstanding ?
  - MattJ100 5y ago
    Movim is a social-oriented XMPP client, so yes, it needs to log in to your account. You don't have to use the mov.im instance - in an ideal world your own server can run a copy of Movim, but you can also self-host, or even run it locally on your system. This year I'm also going to be working on account access delegation for XMPP as part of a funded project, resulting in implementation in Prosody (server software) and publishing/updating related standards. That's the kind of thing Movim would be able to take advantage of so you can grant (restricted) account access to a remote Movim instance without sharing your password.
    - yosamino 5y ago
      > This year I'm also going to be working on account access delegation for XMPP as part of a funded project, resulting in implementation in Prosody (server software) and publishing/updating related standards. So that I can do something along the lines of "Log in with XMPP" and then my client asks me "hey do you wanna allow movim.eu to access foo/do bar on your behalf" ? That sounds very useful. Sharing my password like this does not seem a great idea.
      - southerntofu 5y ago
        This is already possible! https://xmpp.org/extensions/xep-0070.html https://xmpp.org/extensions/xep-0070.html
        MattJ100 5y ago
        That's slightly different. XEP-0070 is about allowing someone to verify that you own a given XMPP address. That is indeed often all you need for a "Log in with XMPP" functionality. Just how many sites allow you to log in with an email + verification link today. However it does not grant someone the ability to connect to your account and perform any actions. Movim is an XMPP client. It interacts with the XMPP network as you, not as a third-party. That's very different to what XEP-0070 is for. Currently the only practical way to allow someone access to your XMPP account is to give them your credentials. But if you do that, there's no way to restrict, monitor or revoke their access (apart from changing your password - something they would also be able to do!). Many XMPP server implementations already implement some of the building blocks for something better (e.g. Prosody and ejabberd both support OAuth in some form already). But there are a number of important missing pieces before we can get it usable and adopted, and that's what I will be focusing on this year. Again, in Movim's case it's fully open-source. You can self-host it or run it on your laptop, so you're never forced to hand over your credentials to any third party today. But many people would find a mechanism to grant a third-party limited access to their account an acceptable solution, so they can use Movim instances hosted by others.
        5y ago
- m4lvin 5y ago
  I wanted to try it out, but this is annoying: - registration happens on https://api.movim.eu/register https://api.movim.eu/register and firefox provides me a way to generate a password and save it linked to that domain. - now I want to log in at https://mov.im/?login https://mov.im/?login but firefox has no idea that it should use my api.movim.eu account for that.
  - edhelas 5y ago
    Yes this is perfectly normal. The XMPP account (so movim.eu) is decorelated from the mov.im pod we deployed as a public instance to show up the project. You can connect on Movim (and mov.im, the official pod/instance) using any XMPP account. movim.eu is just one amongs all the others. You have to differenciate Movim as a project that particular instance deployed as mov.im and the Movim XMPP server that we deployed from the project. I know it might be a bit confusing so if you have some ideas to clarify things up do not hesitate :)
    - judge2020 5y ago
      I think this is the same problem matrix has: you end up entering your login details on foreign domains. There's really nothing stopping them from capturing that login via malicious javascript and using it for some malicious mitm, or just saving it to try on other services (you can't expect everyone to use a randomly-generated password). I don't see why you couldn't just enter 'server.com' (your xmpp server) and have an OIDC flow performed (the same complaint goes for matrix).
    - marwis 5y ago
      Login should happen on a single domain (same one that was used for sign up). Just redirect from mov.im to movim.eu and back, same as Oauth.
    - m4lvin 5y ago
      I have my own XMPP server ;-) and I understand the underlying problem here. I mostly wanted to point out that for a new person to quickly try out Movim this might be a stumbling block. As another comment suggested using something like OAuth to smooth this out might help.
a3w 5y ago
Encryption is "activily bein worked on", sound about right - I never got encryption to work across two of my own devices with a third party. Yet I do not understand why a rewrite of messaging as [matrix] was necessary, when XMPP was already there and matrix did not even have an edit-message feature on release, perhaps not even now.
- _zooted 5y ago
  Matrix supports encryption out-of-the-box without any strange key exchange problems. Most of the time the way key exchange is done in XMPP is very insecure.
  - zaik 5y ago
    > Most of the time the way key exchange is done in XMPP is very insecure. How so?
  - f1refly 5y ago
    > Most of the time the way key exchange is done in XMPP is very insecure. We have OMEMO now, key exchange is paranoia-level secure.
    - gefhfffh 5y ago
      How resistant to MITM is it though? Currently, verification seems to work on a session basis and not just per user, which makes it very tedious to have everything verified e.g. a group chat. If it is not almost impossible given peoples sessions change with time. Add a new session in the browser -> meet every contact to verify their sessions with your new browser session? Doesn't seem very practical, and reminds me of the old times in [matrix]. This opens room for MITM attacks
      - f1refly 5y ago
        Security is always a tradeoff with convenience. How should a "per user" verification work in your opinion? A single master key that signs subkeys? Would the master key be secured with yet another password? What happens with already signed keys if a user loses access to the master key? Will I have to explain to my auntie over the phone that her master key password is somehow different to her account password and that it's very important she remembers both? Will I have to tell my uncle to sign his new key in the browser session with his master key that was generated on the phone and now has to be transmitted to the computer because it wasn't password protected and thus can't be stored on the providers server for syncing? When existing keys are used to sign new ones, what happens when the old one gets dropped? Will the conversation just break out of nowhere? Also you don't have to meet with everyone to verify new keys, you can just use a known good key for that. Essentially, if you want 100% security by comparing keys in a meetup, you can do that once and then use that known good channel to verify every new key. In reality, cryptonerds will be happy to verify every single new key, everyone else will never bother to even open the key signature view and I will get a confused call should it be opened by accident. > This opens room for MITM attacks Yes, in your constructed strawman world xmpp is prone to MITM. In reality it's equally or less prone than its competitors.
KaiserPro 5y ago
XMPP is many thing, but I doubt it could be described as secure. Yes it has SASL auth, TLS and you can run it on an intranet, but thats not the same as secure.
- rakoo 5y ago
  XMPP has had e2ee for years. What are your criterias for calling it not secure ?
- f1refly 5y ago
  XMPP is as secure as Signal nowadays, it implements the same encryption scheme and is still completely federated: https://conversations.im/omemo/ https://conversations.im/omemo/ Omemo is a relatively recent effort though and many people still remember the days when gpg and otr where the sad state of the art in the xmpp world.
  - rakoo 5y ago
    XMPP leaves a lot of metadata and user information around, so it does have a privacy issue that's probably not solvable. Whether it's a security issue is a completely different discussion though.
    - f1refly 5y ago
      That's got nothing to do with the security problems OP complained about though. Are there even working solutions to those metadata problems apart from sending dummy decoy messages and purposeful delays on the server side to make correlating message relaying hard?
      - southerntofu 5y ago
        The metadata leaks are more about correlating pseudonymous identities to the same accounts than network leaks (for which we employ VPN/SSH tunnels or Tor). If you'd like to know more about the threat model of XMPP: https://joinjabber.org/faqs/security/ https://joinjabber.org/faqs/security/ (critique welcome)
folex 5y ago
How about XMPP performance on low-performance networks like mobile ones? I believe poor networking performance was one of the reasons XMPP had to be customised in WhatsApp and overall didn't become as widely used as I'd like it to be :) Is it still the case? Or was that problem addressed at standard level somehow?
- southerntofu 5y ago
  Some extensions like XEP-0352 Client State Indication have been developed to fit the mobile world. XMPP on mobile is nowadays very reliable, except for iOS preventing 3rd party notifications.
- rakoo 5y ago
  That is a situation documented by people years ago, and has been wrong for years. See https://gultsch.de/xmpp_2016.html https://gultsch.de/xmpp_2016.html. Unfortunately the legend lives on because "it doesn't work" is a better soundbite than "it works"
- SamWhited 5y ago
  I first started using XMPP heavily in 2014 when I was thru-hiking the Appalachian Trail. Much of the trail has extremely limited cell coverage (even if you can get Edge some of the towers are so bad you can literally only get a few bytes per second). I evaluated several different protocols and apps for communication with family, and XMPP beat them all hands down every time. The long lived TCP connections meant that once a connection was established I could keep it up and it would sit there slurping up the bits as it came. That experience later led me to get involved with the community and even write a spec about using XMPP on high-latency low-bandwidth networks. It may have been bad at this at one time, I don't know, but at least since I've been using it's been fantastic with poor network quality, I suspect the people saying otherwise are just repeating something they learned in the early 2000s that's no longer true.
- davecridland 5y ago
  XMPP is routinely used on HF radio and SATCOM networks field-deployed by militaries. It's deployed with channel compression (so the links themselves are compressed), but it routinely operates down to way way below mobile. In general, the really bad links are used for federation (s2s) rather than client connections which demand lower latency for user interaction. I've personally watched it operate on HF radio modems down to single-figure bits per second - those are simplex links with a 30 second turnaround. It's slow of course, but it does work - and this is on the base standard. Any server can do this, there's three I know of in use. WhatsApp decided, at some point in the past, that XML was too verbose and compressed it using a technique borrowed from WAP - essentially a fixed-dictionary compression. Newer WhatsApp systems don't ever bother decompressing to XML, and it's likely it can't be anymore, but it's fundamentally the same traffic patterns even now. Your WhatsApp account still has a jid (with a very short, fake domain) and so do your groupchats (also a very short fake domain). The WAP compression choice was unfortunate, as it only really had an effect back in GPRS/EDGE days, only on certain networks, and only on certain traffic patterns, because it's the number of packets that matter in most cases, not the number of bytes. There'd still be some rare benefit on 3G, but by 4G the benefit had all gone. Meanwhile, clients like Siskin and Conversations work just fine on modern mobiles. Conversations (an Android client) does work better when given permissions to keep the sessions live rather than rely on push notifications, but testing has consistently shown that battery life in unaffected. There's a number of extensions that are widely deployed that help efficiency, for sure, and I'd not want to run without for preference - though it is possible, and not as bad as you'd think. So I'd say that XMPP has no performance problems at all on "long thin" networks way beyond mobile. To get the same performance out of anything based on HTTP, you need to recode to use the parallel protocols of CoAP and friends. Matrix have done this, but it means specialist clients and servers are needed, and as far as I'm aware there's only a single implementation.
infosechandbook 5y ago
The article describes XMPP as "secure" by highlighting TLS (protecting data in transit only) and experimental OMEMO (protecting a small part of an XMPP message only if enabled and working). What about other crucial security features, see https://www.eff.org/deeplinks/2018/03/building-secure-messenger https://www.eff.org/deeplinks/2018/03/building-secure-messen...? Then, XMPP is described as "privacy respecting" mostly because you can use a nickname instead of a phone number for your account. What about all of the cleartext data and metadata that can be accessed by parties on the XMPP server, like the XMPP server admin, see https://infosec-handbook.eu/articles/xmpp-aitm/ https://infosec-handbook.eu/articles/xmpp-aitm/? This logic implies that e-mail is also secure and privacy respecting.
- tialaramex 5y ago
  I await future articles "Saudi Arabia: The resource poor country with a thriving democracy", "Bears: These vegetarians are too shy to defecate outdoors" and perhaps soon, "Popes: The married women who are rarely seen in church". But maybe they've just never seen a protocol more secure than telnet or more privacy respecting than the News Of The World ? Nobody show them Signal or their head might explode.
  - jmnicolas 5y ago
    Thanks for the laugh, you should write news title it would be fun! Anyway the problem of Signal is that you have to use your phone number and a phone number is a much stronger link to you than an ip for example. As the ex boss of NSA said "We Kill People Based on Metadata".
    - infosechandbook 5y ago
      > Anyway the problem of Signal is that you have to use your phone number and a phone number is a much stronger link to you than an ip for example. Signal requires access to a valid phone number during registration, not "your phone number." It can even be a virtual/landline/temporary phone number without any SIM cards or cell phones involved. How is this a "much stronger link to you than an ip"? And how about looking at more than just an isolated property of a competitor? > As the ex boss of NSA said "We Kill People Based on Metadata". XMPP servers are a gold mine when it comes to metadata.
tacticaldev 5y ago
Isn't that Jabber? Haven't heard of XMPP in a while.
- southerntofu 5y ago
  It's the same thing! XMPP usually refers to the protocol and Jabber the open federation, but since Cisco acquired the Jabber trademark some people have been reluctant to use that name. And some people think a protocol name is irrelevant and would rather build a consistent product based on open standards: https://snikket.org/blog/products-vs-protocols/ https://snikket.org/blog/products-vs-protocols/
southerntofu 5y ago
Thanks for the article! Just to nitpick: > Moreover, the protocol has been audited by a third party. Some implementations have been audited, unfortunately far from all! There's a lot of things to audit and/or improve related to privacy and security in the XMPP ecosystem: i would personally recommend to read this FAQ: https://joinjabber.org/faqs/security/ https://joinjabber.org/faqs/security/ > Also, on this page, you can track the progress of OMEMO integration in XMPP clients (applications) This is true, but based on estimated progress not something measured by a test suite. For example poezio is marked 100% but i keep having OMEMO problems with it (not blaming the poor poezio-omemo maintainer who's working on it alone mostly). > Only the nickname is displayed if you participate in a group chat or a channel (here, the XMPP extension called MUC, the acronym for Multi-User Chat, is used). Except for the room operators! The MUC server admins have access to all addresses, as well as room admins. Also, some rooms are public in which case everyone can read everyone's address (like a mailing list).
snvzz 5y ago
On XMPP, encryption is optional and not even the default. I'm very unlikely to recommend it to anyone over alternatives that default to end to end encryption, or even require it.
- ezst 5y ago
  > I'm very unlikely to recommend it to anyone over alternatives that default to end to end encryption, or even require it. Which are they? Alternatives that require you to reveal your identity (via a phone number), or to reveal your whole social graph/usage patterns (by being organized around a single actor in the middle knowing about everything and everyone in the network)? Federated and P2P networks are the only true alternatives for the privacy/security conscious. > On XMPP, encryption is optional and not even the default. OMEMO encryption is widespread/practically universal these days. You are pretty much guaranteed to be able to establish an E2EE session would it not be the default for any reason.
  - snvzz 5y ago
    >Alternatives that require you to reveal your identity (via a phone number), or to reveal your whole social graph/usage patterns (by being organized around a single actor in the middle knowing about everything and everyone in the network)? No. Matrix and Tox come to mind.
    - ezst 5y ago
      Agreed about Matrix and Tox qualifying (not being centralized). I can't vouch for Tox from a security standpoint (haven't looked at the details), but I can guarantee that it's not ready for widespread use (esp. on mobile where P2P messaging still needs a breakthrough). Matrix is fine. In my biased opinion, it's just XMPP with more steps, more overhead and a less diverse ecosystem. Also, its security story is no better than XMPP so it's funny that we came to that from "XMPP, encryption is optional and not even the default", where that's practically truer for Matrix than it is for XMPP.
- Andrew_nenakhov 5y ago
qwertox 5y ago
It angers me so much when my browser tries to connect to a port other than 80 or 443 and the firewall pops up [0] and even more if I decline the request and it keeps popping up because the page doesn't understand that I don't want to accept this. Other than that, I absolutely love XMPP. It's the platform my servers and applications use to inform me of events, and with Conversations [1] there's a really nice Android app as a client. [0] https://matrix.cactus.chat:8448/_matrix/client/r0/register?kind=guest https://matrix.cactus.chat:8448/_matrix/client/r0/register?k... [1] https://conversations.im/ https://conversations.im/
SergeAx 5y ago
Was waiting for this after two top posts about IRC.
jakearmitage 5y ago
How can accounts be distributed? What would prevent impersonation?
- ezst 5y ago
  Same as the rest of the modern internet, XMPP relies on the DNS network. Your account is basically `nick@service.tld`, just like email.
Hakashiro 5y ago
XMPP is dead and I'm very happy about that. The only people who still use XMPP in a significant capacity are the likes of Nintendo (for the Switch push notifications system) and it is pretty out of reach for any average citizen. XMPP as a protocol for engineering and science is fantastic. As a set of standards it's well designed. Performant, flexible, and powerful. As a general, average Joe software however it fucking sucks big time. And it is precisely this flexibility that makes it suck. It's not just flexible, it's a mess. And mobile support in 2021 is atrocious. There's a reason why Telegram's very shitty protocol is vastly more popular for average Joes than XMPP ever was. XMPP was designed by engineers, for engineers. Which is good for this very specific set of engineering problems and essentially useless for everyone else. Want secure communication? Use Signal, Threema, hell even Telegram is more secure in its default canonical protocol implementations than XMPP. And stop beating the dead horse XMPP is.
- deleted 5y ago
  [deleted]
- nitia 5y ago
  > XMPP is dead and I'm very happy about that. Quoted this on XMPP for the irony.
- singpolyma3 5y ago
  > And mobile support in 2021 is atrocious. I'm curious to hear of any specific mobile issues you are aware of. Most of our customers use XMPP exclusively from mobile and I have not heard complaints so far, but it's only been 5 years so far...
yalogin 5y ago
I am not seeing the value in discussing privacy at the protocol level. Sure I share what I want to share with the other party but that is not where the privacy violations occur. The host of the service (like FB) will suck up all data and use it to mine info on me. That is where the leak is.
cjtrowbridge 5y ago
It's trivially easy to log messages and content on an xmpp server. It's not a secure protocol at all, just because it uses tls in transport.
tptacek 5y ago
I'm not going to say that you can't build a secure messaging system with XMPP, but you should be skeptical of any analysis that suggests that XMPP is secure because it uses TLS, and "engineers are working on E2EE to add even more security". The security you get from TLS in these systems is not meaningful, and by the "it uses TLS" definition, virtually every messaging system is "secure".
- Volker_W 5y ago
  > The security you get from TLS in these systems is not meaningful I don't like that phrasing, because it suggests that having TLS is equally good than not having TLS. Otherwise, you are right.
AceJohnny2 5y ago
As a former XMPP fan, I think XMPP is extremely interesting in light of Moxie's recent web3 post [1], and most specifically the part: > A protocol moves much more slowly than a platform. After 30+ years, email is still unencrypted; meanwhile WhatsApp went from unencrypted to full e2ee in a year. You could replace email with XMPP in that sentence. (In fact, I'd bet Moxie was specifically thinking of XMPP when he wrote that.) I remember when Google introduced voice/video, and provided a library (libjingle) to help other clients add the feature. It never really got picked up. Perhaps it was the state of the driver ecosystem at the time that made it hard for clients to reliably support such streams (PulseAudio was still new at the time, and GStreamer wasn't as mature), that was in excess of what open-source maintainers could provide. Google eventually decided (reasonably, in retrospect and IMHO) it was easier to turn its chat into its own platform than try and drag a protocol with it. They were certainly dealing with problems that no-one else did. For example, they were very late to enable federation, much to the annoyance of the community, because Google had to deal with spam at a scale no-one else did, and wanted to make sure they had the protocols to deal with that, which no-one else in the community wanted to deal with. (Of course after that I cannot give Google any credit for their chat client merry-go-round, and they've burned any goodwill I had for them on that front! [2] ) Perhaps we'll reach a point where the feature-set for a chat client will settle, and once again a federated protocol can emerge. I no longer believe XMPP is it. [1] https://moxie.org/2022/01/07/web3-first-impressions.html https://moxie.org/2022/01/07/web3-first-impressions.html [2] https://arstechnica.com/gadgets/2021/08/a-decade-and-a-half-of-instability-the-history-of-google-messaging-apps/ https://arstechnica.com/gadgets/2021/08/a-decade-and-a-half-... Edit: that said, I think XMPP had a lot of great ideas, and I'm glad it still pops up now and again.
- AceJohnny2 5y ago
  A particular subset of the XMPP story I want to share is that back in the mid-00's, the XMPP folks were trying to make it the protocol of the real-time web. I think that was a laudable goal. One thing they particularly feared was for the web to become HTTP-only, with all the overhead that entails. How prescient.
- kixiQu 5y ago
  I'd bet he was thinking of this whole back and forth (blog posts, conference talk) with Matrix: https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom
TheJoYo 5y ago
I can't even convince security professionals to install Signal, let alone something that requires installing a specific client configuration that may not be identical across platforms. If it's not e2ee by default I'd rather just stick to my current social graph.

284 points by neustradamus 5y ago

Hi! Glad to see XMPP on the HN first page this morning :) I'm working on a social-network and IM web platform (for 12 years already!), fully built on XMPP https://movim.eu/ https://movim.eu/. Thanks to its extensibility and the PubSub XMPP standard (see https://xmpp.org/extensions/xep-0060.html https://xmpp.org/extensions/xep-0060.html) you can easily build social-network like features. The standard is pretty simple, it's Atom 1.0 transport within PubSub (see https://xmpp.org/extensions/xep-0277.html https://xmpp.org/extensions/xep-0277.html). For those that likes RSS/Atom you can also easily publish Atom newsfeed to PubSub (see https://github.com/edhelas/atomtopubsub https://github.com/edhelas/atomtopubsub) and follow your favorite website using your XMPP account and with real-time pushed articles. Here is ArsTechnica as an example https://mov.im/?node/news.movim.eu/ArsTechnica https://mov.im/?node/news.movim.eu/ArsTechnica XMPP is not only for IM, but way more than that ;)

yosamino 5y ago
I've seen movim around but I have never actually tried it. This post gave me the push. So thank you for that. I do have a question though: On https://mov.im/?login https://mov.im/?login it says: "Login using any XMPP account or create a new one" But it only shows me a login form where I can enter my xmpp address and a password. This signals to me that I can log into my existing non-movim-xmpp account, but I have to enter my password on there? That can't be right. What am I misunderstanding ?
- MattJ100 5y ago
  Movim is a social-oriented XMPP client, so yes, it needs to log in to your account. You don't have to use the mov.im instance - in an ideal world your own server can run a copy of Movim, but you can also self-host, or even run it locally on your system. This year I'm also going to be working on account access delegation for XMPP as part of a funded project, resulting in implementation in Prosody (server software) and publishing/updating related standards. That's the kind of thing Movim would be able to take advantage of so you can grant (restricted) account access to a remote Movim instance without sharing your password.
  - yosamino 5y ago
    > This year I'm also going to be working on account access delegation for XMPP as part of a funded project, resulting in implementation in Prosody (server software) and publishing/updating related standards. So that I can do something along the lines of "Log in with XMPP" and then my client asks me "hey do you wanna allow movim.eu to access foo/do bar on your behalf" ? That sounds very useful. Sharing my password like this does not seem a great idea.
    - southerntofu 5y ago
      This is already possible! https://xmpp.org/extensions/xep-0070.html https://xmpp.org/extensions/xep-0070.html
      - MattJ100 5y ago
        That's slightly different. XEP-0070 is about allowing someone to verify that you own a given XMPP address. That is indeed often all you need for a "Log in with XMPP" functionality. Just how many sites allow you to log in with an email + verification link today. However it does not grant someone the ability to connect to your account and perform any actions. Movim is an XMPP client. It interacts with the XMPP network as you, not as a third-party. That's very different to what XEP-0070 is for. Currently the only practical way to allow someone access to your XMPP account is to give them your credentials. But if you do that, there's no way to restrict, monitor or revoke their access (apart from changing your password - something they would also be able to do!). Many XMPP server implementations already implement some of the building blocks for something better (e.g. Prosody and ejabberd both support OAuth in some form already). But there are a number of important missing pieces before we can get it usable and adopted, and that's what I will be focusing on this year. Again, in Movim's case it's fully open-source. You can self-host it or run it on your laptop, so you're never forced to hand over your credentials to any third party today. But many people would find a mechanism to grant a third-party limited access to their account an acceptable solution, so they can use Movim instances hosted by others.
        5y ago
m4lvin 5y ago
I wanted to try it out, but this is annoying: - registration happens on https://api.movim.eu/register https://api.movim.eu/register and firefox provides me a way to generate a password and save it linked to that domain. - now I want to log in at https://mov.im/?login https://mov.im/?login but firefox has no idea that it should use my api.movim.eu account for that.
- edhelas 5y ago
  Yes this is perfectly normal. The XMPP account (so movim.eu) is decorelated from the mov.im pod we deployed as a public instance to show up the project. You can connect on Movim (and mov.im, the official pod/instance) using any XMPP account. movim.eu is just one amongs all the others. You have to differenciate Movim as a project that particular instance deployed as mov.im and the Movim XMPP server that we deployed from the project. I know it might be a bit confusing so if you have some ideas to clarify things up do not hesitate :)
  - judge2020 5y ago
    I think this is the same problem matrix has: you end up entering your login details on foreign domains. There's really nothing stopping them from capturing that login via malicious javascript and using it for some malicious mitm, or just saving it to try on other services (you can't expect everyone to use a randomly-generated password). I don't see why you couldn't just enter 'server.com' (your xmpp server) and have an OIDC flow performed (the same complaint goes for matrix).
  - marwis 5y ago
    Login should happen on a single domain (same one that was used for sign up). Just redirect from mov.im to movim.eu and back, same as Oauth.
  - m4lvin 5y ago
    I have my own XMPP server ;-) and I understand the underlying problem here. I mostly wanted to point out that for a new person to quickly try out Movim this might be a stumbling block. As another comment suggested using something like OAuth to smooth this out might help.

a3w 5y ago

Encryption is "activily bein worked on", sound about right - I never got encryption to work across two of my own devices with a third party. Yet I do not understand why a rewrite of messaging as [matrix] was necessary, when XMPP was already there and matrix did not even have an edit-message feature on release, perhaps not even now.

_zooted 5y ago
Matrix supports encryption out-of-the-box without any strange key exchange problems. Most of the time the way key exchange is done in XMPP is very insecure.
- zaik 5y ago
  > Most of the time the way key exchange is done in XMPP is very insecure. How so?
- f1refly 5y ago
  > Most of the time the way key exchange is done in XMPP is very insecure. We have OMEMO now, key exchange is paranoia-level secure.
  - gefhfffh 5y ago
    How resistant to MITM is it though? Currently, verification seems to work on a session basis and not just per user, which makes it very tedious to have everything verified e.g. a group chat. If it is not almost impossible given peoples sessions change with time. Add a new session in the browser -> meet every contact to verify their sessions with your new browser session? Doesn't seem very practical, and reminds me of the old times in [matrix]. This opens room for MITM attacks
    - f1refly 5y ago
      Security is always a tradeoff with convenience. How should a "per user" verification work in your opinion? A single master key that signs subkeys? Would the master key be secured with yet another password? What happens with already signed keys if a user loses access to the master key? Will I have to explain to my auntie over the phone that her master key password is somehow different to her account password and that it's very important she remembers both? Will I have to tell my uncle to sign his new key in the browser session with his master key that was generated on the phone and now has to be transmitted to the computer because it wasn't password protected and thus can't be stored on the providers server for syncing? When existing keys are used to sign new ones, what happens when the old one gets dropped? Will the conversation just break out of nowhere? Also you don't have to meet with everyone to verify new keys, you can just use a known good key for that. Essentially, if you want 100% security by comparing keys in a meetup, you can do that once and then use that known good channel to verify every new key. In reality, cryptonerds will be happy to verify every single new key, everyone else will never bother to even open the key signature view and I will get a confused call should it be opened by accident. > This opens room for MITM attacks Yes, in your constructed strawman world xmpp is prone to MITM. In reality it's equally or less prone than its competitors.

KaiserPro 5y ago

XMPP is many thing, but I doubt it could be described as secure. Yes it has SASL auth, TLS and you can run it on an intranet, but thats not the same as secure.

rakoo 5y ago
XMPP has had e2ee for years. What are your criterias for calling it not secure ?
f1refly 5y ago
XMPP is as secure as Signal nowadays, it implements the same encryption scheme and is still completely federated: https://conversations.im/omemo/ https://conversations.im/omemo/ Omemo is a relatively recent effort though and many people still remember the days when gpg and otr where the sad state of the art in the xmpp world.
- rakoo 5y ago
  XMPP leaves a lot of metadata and user information around, so it does have a privacy issue that's probably not solvable. Whether it's a security issue is a completely different discussion though.
  - f1refly 5y ago
    That's got nothing to do with the security problems OP complained about though. Are there even working solutions to those metadata problems apart from sending dummy decoy messages and purposeful delays on the server side to make correlating message relaying hard?
    - southerntofu 5y ago
      The metadata leaks are more about correlating pseudonymous identities to the same accounts than network leaks (for which we employ VPN/SSH tunnels or Tor). If you'd like to know more about the threat model of XMPP: https://joinjabber.org/faqs/security/ https://joinjabber.org/faqs/security/ (critique welcome)

folex 5y ago

How about XMPP performance on low-performance networks like mobile ones? I believe poor networking performance was one of the reasons XMPP had to be customised in WhatsApp and overall didn't become as widely used as I'd like it to be :) Is it still the case? Or was that problem addressed at standard level somehow?

southerntofu 5y ago
Some extensions like XEP-0352 Client State Indication have been developed to fit the mobile world. XMPP on mobile is nowadays very reliable, except for iOS preventing 3rd party notifications.
rakoo 5y ago
That is a situation documented by people years ago, and has been wrong for years. See https://gultsch.de/xmpp_2016.html https://gultsch.de/xmpp_2016.html. Unfortunately the legend lives on because "it doesn't work" is a better soundbite than "it works"
SamWhited 5y ago
I first started using XMPP heavily in 2014 when I was thru-hiking the Appalachian Trail. Much of the trail has extremely limited cell coverage (even if you can get Edge some of the towers are so bad you can literally only get a few bytes per second). I evaluated several different protocols and apps for communication with family, and XMPP beat them all hands down every time. The long lived TCP connections meant that once a connection was established I could keep it up and it would sit there slurping up the bits as it came. That experience later led me to get involved with the community and even write a spec about using XMPP on high-latency low-bandwidth networks. It may have been bad at this at one time, I don't know, but at least since I've been using it's been fantastic with poor network quality, I suspect the people saying otherwise are just repeating something they learned in the early 2000s that's no longer true.
davecridland 5y ago
XMPP is routinely used on HF radio and SATCOM networks field-deployed by militaries. It's deployed with channel compression (so the links themselves are compressed), but it routinely operates down to way way below mobile. In general, the really bad links are used for federation (s2s) rather than client connections which demand lower latency for user interaction. I've personally watched it operate on HF radio modems down to single-figure bits per second - those are simplex links with a 30 second turnaround. It's slow of course, but it does work - and this is on the base standard. Any server can do this, there's three I know of in use. WhatsApp decided, at some point in the past, that XML was too verbose and compressed it using a technique borrowed from WAP - essentially a fixed-dictionary compression. Newer WhatsApp systems don't ever bother decompressing to XML, and it's likely it can't be anymore, but it's fundamentally the same traffic patterns even now. Your WhatsApp account still has a jid (with a very short, fake domain) and so do your groupchats (also a very short fake domain). The WAP compression choice was unfortunate, as it only really had an effect back in GPRS/EDGE days, only on certain networks, and only on certain traffic patterns, because it's the number of packets that matter in most cases, not the number of bytes. There'd still be some rare benefit on 3G, but by 4G the benefit had all gone. Meanwhile, clients like Siskin and Conversations work just fine on modern mobiles. Conversations (an Android client) does work better when given permissions to keep the sessions live rather than rely on push notifications, but testing has consistently shown that battery life in unaffected. There's a number of extensions that are widely deployed that help efficiency, for sure, and I'd not want to run without for preference - though it is possible, and not as bad as you'd think. So I'd say that XMPP has no performance problems at all on "long thin" networks way beyond mobile. To get the same performance out of anything based on HTTP, you need to recode to use the parallel protocols of CoAP and friends. Matrix have done this, but it means specialist clients and servers are needed, and as far as I'm aware there's only a single implementation.

infosechandbook 5y ago

The article describes XMPP as "secure" by highlighting TLS (protecting data in transit only) and experimental OMEMO (protecting a small part of an XMPP message only if enabled and working). What about other crucial security features, see https://www.eff.org/deeplinks/2018/03/building-secure-messenger https://www.eff.org/deeplinks/2018/03/building-secure-messen...? Then, XMPP is described as "privacy respecting" mostly because you can use a nickname instead of a phone number for your account. What about all of the cleartext data and metadata that can be accessed by parties on the XMPP server, like the XMPP server admin, see https://infosec-handbook.eu/articles/xmpp-aitm/ https://infosec-handbook.eu/articles/xmpp-aitm/? This logic implies that e-mail is also secure and privacy respecting.

tialaramex 5y ago
I await future articles "Saudi Arabia: The resource poor country with a thriving democracy", "Bears: These vegetarians are too shy to defecate outdoors" and perhaps soon, "Popes: The married women who are rarely seen in church". But maybe they've just never seen a protocol more secure than telnet or more privacy respecting than the News Of The World ? Nobody show them Signal or their head might explode.
- jmnicolas 5y ago
  Thanks for the laugh, you should write news title it would be fun! Anyway the problem of Signal is that you have to use your phone number and a phone number is a much stronger link to you than an ip for example. As the ex boss of NSA said "We Kill People Based on Metadata".
  - infosechandbook 5y ago
    > Anyway the problem of Signal is that you have to use your phone number and a phone number is a much stronger link to you than an ip for example. Signal requires access to a valid phone number during registration, not "your phone number." It can even be a virtual/landline/temporary phone number without any SIM cards or cell phones involved. How is this a "much stronger link to you than an ip"? And how about looking at more than just an isolated property of a competitor? > As the ex boss of NSA said "We Kill People Based on Metadata". XMPP servers are a gold mine when it comes to metadata.

tacticaldev 5y ago

Isn't that Jabber? Haven't heard of XMPP in a while.

southerntofu 5y ago
It's the same thing! XMPP usually refers to the protocol and Jabber the open federation, but since Cisco acquired the Jabber trademark some people have been reluctant to use that name. And some people think a protocol name is irrelevant and would rather build a consistent product based on open standards: https://snikket.org/blog/products-vs-protocols/ https://snikket.org/blog/products-vs-protocols/

southerntofu 5y ago

Thanks for the article! Just to nitpick: > Moreover, the protocol has been audited by a third party. Some implementations have been audited, unfortunately far from all! There's a lot of things to audit and/or improve related to privacy and security in the XMPP ecosystem: i would personally recommend to read this FAQ: https://joinjabber.org/faqs/security/ https://joinjabber.org/faqs/security/ > Also, on this page, you can track the progress of OMEMO integration in XMPP clients (applications) This is true, but based on estimated progress not something measured by a test suite. For example poezio is marked 100% but i keep having OMEMO problems with it (not blaming the poor poezio-omemo maintainer who's working on it alone mostly). > Only the nickname is displayed if you participate in a group chat or a channel (here, the XMPP extension called MUC, the acronym for Multi-User Chat, is used). Except for the room operators! The MUC server admins have access to all addresses, as well as room admins. Also, some rooms are public in which case everyone can read everyone's address (like a mailing list).

snvzz 5y ago

On XMPP, encryption is optional and not even the default. I'm very unlikely to recommend it to anyone over alternatives that default to end to end encryption, or even require it.

ezst 5y ago
> I'm very unlikely to recommend it to anyone over alternatives that default to end to end encryption, or even require it. Which are they? Alternatives that require you to reveal your identity (via a phone number), or to reveal your whole social graph/usage patterns (by being organized around a single actor in the middle knowing about everything and everyone in the network)? Federated and P2P networks are the only true alternatives for the privacy/security conscious. > On XMPP, encryption is optional and not even the default. OMEMO encryption is widespread/practically universal these days. You are pretty much guaranteed to be able to establish an E2EE session would it not be the default for any reason.
- snvzz 5y ago
  >Alternatives that require you to reveal your identity (via a phone number), or to reveal your whole social graph/usage patterns (by being organized around a single actor in the middle knowing about everything and everyone in the network)? No. Matrix and Tox come to mind.
  - ezst 5y ago
    Agreed about Matrix and Tox qualifying (not being centralized). I can't vouch for Tox from a security standpoint (haven't looked at the details), but I can guarantee that it's not ready for widespread use (esp. on mobile where P2P messaging still needs a breakthrough). Matrix is fine. In my biased opinion, it's just XMPP with more steps, more overhead and a less diverse ecosystem. Also, its security story is no better than XMPP so it's funny that we came to that from "XMPP, encryption is optional and not even the default", where that's practically truer for Matrix than it is for XMPP.
Andrew_nenakhov 5y ago

qwertox 5y ago

It angers me so much when my browser tries to connect to a port other than 80 or 443 and the firewall pops up [0] and even more if I decline the request and it keeps popping up because the page doesn't understand that I don't want to accept this. Other than that, I absolutely love XMPP. It's the platform my servers and applications use to inform me of events, and with Conversations [1] there's a really nice Android app as a client. [0] https://matrix.cactus.chat:8448/_matrix/client/r0/register?kind=guest https://matrix.cactus.chat:8448/_matrix/client/r0/register?k... [1] https://conversations.im/ https://conversations.im/

SergeAx 5y ago

Was waiting for this after two top posts about IRC.

jakearmitage 5y ago

How can accounts be distributed? What would prevent impersonation?

ezst 5y ago
Same as the rest of the modern internet, XMPP relies on the DNS network. Your account is basically `nick@service.tld`, just like email.

Hakashiro 5y ago

XMPP is dead and I'm very happy about that. The only people who still use XMPP in a significant capacity are the likes of Nintendo (for the Switch push notifications system) and it is pretty out of reach for any average citizen. XMPP as a protocol for engineering and science is fantastic. As a set of standards it's well designed. Performant, flexible, and powerful. As a general, average Joe software however it fucking sucks big time. And it is precisely this flexibility that makes it suck. It's not just flexible, it's a mess. And mobile support in 2021 is atrocious. There's a reason why Telegram's very shitty protocol is vastly more popular for average Joes than XMPP ever was. XMPP was designed by engineers, for engineers. Which is good for this very specific set of engineering problems and essentially useless for everyone else. Want secure communication? Use Signal, Threema, hell even Telegram is more secure in its default canonical protocol implementations than XMPP. And stop beating the dead horse XMPP is.

deleted 5y ago
[deleted]
nitia 5y ago
> XMPP is dead and I'm very happy about that. Quoted this on XMPP for the irony.
singpolyma3 5y ago
> And mobile support in 2021 is atrocious. I'm curious to hear of any specific mobile issues you are aware of. Most of our customers use XMPP exclusively from mobile and I have not heard complaints so far, but it's only been 5 years so far...

yalogin 5y ago

I am not seeing the value in discussing privacy at the protocol level. Sure I share what I want to share with the other party but that is not where the privacy violations occur. The host of the service (like FB) will suck up all data and use it to mine info on me. That is where the leak is.

cjtrowbridge 5y ago

It's trivially easy to log messages and content on an xmpp server. It's not a secure protocol at all, just because it uses tls in transport.

tptacek 5y ago

I'm not going to say that you can't build a secure messaging system with XMPP, but you should be skeptical of any analysis that suggests that XMPP is secure because it uses TLS, and "engineers are working on E2EE to add even more security". The security you get from TLS in these systems is not meaningful, and by the "it uses TLS" definition, virtually every messaging system is "secure".

Volker_W 5y ago
> The security you get from TLS in these systems is not meaningful I don't like that phrasing, because it suggests that having TLS is equally good than not having TLS. Otherwise, you are right.

AceJohnny2 5y ago

As a former XMPP fan, I think XMPP is extremely interesting in light of Moxie's recent web3 post [1], and most specifically the part: > A protocol moves much more slowly than a platform. After 30+ years, email is still unencrypted; meanwhile WhatsApp went from unencrypted to full e2ee in a year. You could replace email with XMPP in that sentence. (In fact, I'd bet Moxie was specifically thinking of XMPP when he wrote that.) I remember when Google introduced voice/video, and provided a library (libjingle) to help other clients add the feature. It never really got picked up. Perhaps it was the state of the driver ecosystem at the time that made it hard for clients to reliably support such streams (PulseAudio was still new at the time, and GStreamer wasn't as mature), that was in excess of what open-source maintainers could provide. Google eventually decided (reasonably, in retrospect and IMHO) it was easier to turn its chat into its own platform than try and drag a protocol with it. They were certainly dealing with problems that no-one else did. For example, they were very late to enable federation, much to the annoyance of the community, because Google had to deal with spam at a scale no-one else did, and wanted to make sure they had the protocols to deal with that, which no-one else in the community wanted to deal with. (Of course after that I cannot give Google any credit for their chat client merry-go-round, and they've burned any goodwill I had for them on that front! [2] ) Perhaps we'll reach a point where the feature-set for a chat client will settle, and once again a federated protocol can emerge. I no longer believe XMPP is it. [1] https://moxie.org/2022/01/07/web3-first-impressions.html https://moxie.org/2022/01/07/web3-first-impressions.html [2] https://arstechnica.com/gadgets/2021/08/a-decade-and-a-half-of-instability-the-history-of-google-messaging-apps/ https://arstechnica.com/gadgets/2021/08/a-decade-and-a-half-... Edit: that said, I think XMPP had a lot of great ideas, and I'm glad it still pops up now and again.

AceJohnny2 5y ago
A particular subset of the XMPP story I want to share is that back in the mid-00's, the XMPP folks were trying to make it the protocol of the real-time web. I think that was a laudable goal. One thing they particularly feared was for the web to become HTTP-only, with all the overhead that entails. How prescient.
kixiQu 5y ago
I'd bet he was thinking of this whole back and forth (blog posts, conference talk) with Matrix: https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom

TheJoYo 5y ago

I can't even convince security professionals to install Signal, let alone something that requires installing a specific client configuration that may not be identical across platforms. If it's not e2ee by default I'd rather just stick to my current social graph.