XMPP: Admin-in-the-middle(infosec-handbook.eu)
infosec-handbook.eu
XMPP: Admin-in-the-middle
https://infosec-handbook.eu/articles/xmpp-aitm/
58 comments
> Tools to solve this (e.g. Tor, VPNs) are well known and established solutions if you need to hide your IP from websites and services you use.
So true, yet some clients might still leak information. For example WebRTC leaks in web browsers is a real concern (which is why Tor Browser disables WebRTC entirely, except maybe in unsafe mode?). I also heard some mobile/desktop clients have such leaks when it comes to VOIP, but i didn't try to reproduce yet. This would be worth investigating with wireshark and a couple of volunteers.
> not a problem with XMPP specifically.
There is one problem the author mentioned which applies to XMPP but not to email/ActivityPub: presence tracking. So your own server/admin will know when a client-to-server (c2s) connection is active, but in the XMPP ecosystem it's rather common for clients and servers to advertise the presence status (online, away) to the entire world, and that's a huge metadata leak. Maybe something to investigate in the future.
So true, yet some clients might still leak information. For example WebRTC leaks in web browsers is a real concern (which is why Tor Browser disables WebRTC entirely, except maybe in unsafe mode?). I also heard some mobile/desktop clients have such leaks when it comes to VOIP, but i didn't try to reproduce yet. This would be worth investigating with wireshark and a couple of volunteers.
> not a problem with XMPP specifically.
There is one problem the author mentioned which applies to XMPP but not to email/ActivityPub: presence tracking. So your own server/admin will know when a client-to-server (c2s) connection is active, but in the XMPP ecosystem it's rather common for clients and servers to advertise the presence status (online, away) to the entire world, and that's a huge metadata leak. Maybe something to investigate in the future.
> There is one problem the author mentioned which applies to XMPP but not to email/ActivityPub: presence tracking. [...] clients and servers to advertise the presence status (online, away) to the entire world, and that's a huge metadata leak.
They don't advertise it to the entire world, but to authorized contacts (and typically groups that you join). With the rise of mobile clients, statuses other than 'online' are far less common than they used to be, because they are growing irrelevant.
Advertising online status to the whole world is what WhatsApp does ( https://news.ycombinator.com/item?id=26809770 ).
They don't advertise it to the entire world, but to authorized contacts (and typically groups that you join). With the rise of mobile clients, statuses other than 'online' are far less common than they used to be, because they are growing irrelevant.
Advertising online status to the whole world is what WhatsApp does ( https://news.ycombinator.com/item?id=26809770 ).
> and typically groups that you join
So more or less to the entire world if you join public chats. Even if you use different nicknames, occupant-id (used for message edits) may be used to track your presence across rooms.
> Advertising online status to the whole world is what WhatsApp does
If we're pointing the finger, i'd recommend reading this document about what Signal does wrong in terms of privacy and security. It's overall a good read of what not to do in private messenger UX:
https://north-shore.info/wp-content/uploads/2019/06/signalfa...
So more or less to the entire world if you join public chats. Even if you use different nicknames, occupant-id (used for message edits) may be used to track your presence across rooms.
> Advertising online status to the whole world is what WhatsApp does
If we're pointing the finger, i'd recommend reading this document about what Signal does wrong in terms of privacy and security. It's overall a good read of what not to do in private messenger UX:
https://north-shore.info/wp-content/uploads/2019/06/signalfa...
>They don't advertise it to the entire world, but to authorized contacts (and typically groups that you join)
But in the article they showed how the server administrator can easily add contacts to a user's contact list. So my understanding is that the user isn't really in control of who can see this information, as the server admin could add a new contact that can then see the presence status. Correct?
Edit: formatting
But in the article they showed how the server administrator can easily add contacts to a user's contact list. So my understanding is that the user isn't really in control of who can see this information, as the server admin could add a new contact that can then see the presence status. Correct?
Edit: formatting
Valid question, not sure why the downvotes. You're right, the server can modify the contact list (and this is used extensively within organizations, and in Snikket to ensure family members can see each other by default).
But this isn't the cause for concern here - if the server is malicious it can broadcast this info without the need to modify your contact list. This again is independent of protocol - if someone wants to log or share the times and durations you are actively connected to their server, they can do so quite easily. It doesn't require XMPP.
But this isn't the cause for concern here - if the server is malicious it can broadcast this info without the need to modify your contact list. This again is independent of protocol - if someone wants to log or share the times and durations you are actively connected to their server, they can do so quite easily. It doesn't require XMPP.
> the user isn't really in control of who can see this information
Server-side parties (e.g., the admin) can see the status information without adding somebody to the group. It is in cleartext, passing the server.
Server-side parties (e.g., the admin) can see the status information without adding somebody to the group. It is in cleartext, passing the server.
Strange criticism. Advertising presence information is the _goal_ of XMPP protocol. The "P" in XMPP stands for Presence.
Indeed! However, some things have changed since XMPP initially came out. For example, Message Archive Management (and equivalents in the PubSub/MIX specs) has been introduced so that messages can be stored reliably, reducing the need for presence. Multi-client usage has also grown, especially with mobile computers ("smartphones") with Internet access everywhere. Then, we now know and have proof that metadata leaks are used to actually harm people and that presence information can be used to establish correlations between several identities.
To be clear, I'm not arguing against presence being supported on a protocol level. However, i believe the protocol and clients/servers should support the usecase where presence information should not be leaked: that people see a message when i send it is fine, but that they know when my computer is online/offline, or when i'm "away" is way too much metadata leak for a privacy-conscious usecase.
My favorite way to deal with that would be to have a "private browsing" mode on IM clients. So that you could turn on/off privacy settings globally with a single switch. I'm guessing a lot of people would choose the "private" mode if prompted for it on first run. I know i would :)
To be clear, I'm not arguing against presence being supported on a protocol level. However, i believe the protocol and clients/servers should support the usecase where presence information should not be leaked: that people see a message when i send it is fine, but that they know when my computer is online/offline, or when i'm "away" is way too much metadata leak for a privacy-conscious usecase.
My favorite way to deal with that would be to have a "private browsing" mode on IM clients. So that you could turn on/off privacy settings globally with a single switch. I'm guessing a lot of people would choose the "private" mode if prompted for it on first run. I know i would :)
It is quite possible not to send presence information at all. I'll say more, we're working on an 'omnipresence' protocol that will advertise only the desired status to the external contacts, and will not leak per-device presences.
This Presence thing works well for always connected clients (desktop), but becomes a huge problem on clients that can't be always connected (iOS ones).
This Presence thing works well for always connected clients (desktop), but becomes a huge problem on clients that can't be always connected (iOS ones).
Desktop is not always connected. People turn it off, or suspend it to save on electricity bills.
From the point of view of xmpp development, it is always connected. Thing is, xmpp session start is a very costly operation. Desktop generally does it once and has it easy from then on. iOS device connects every time a user opens an app. By the time it'll finish receiving presence information, a user will already close it, and the OS will terminate app process.
Unless the protocol is connectionless, the server will always know at least the user's online status.
I have to use Slack for work, and the way I solve this is to have my client not send typing notifications, and have the client running on my server and repeatedly sending activity notifications all the time, so I always appear online and present to Slack servers.
I can prevent Slack from knowing when I'm really connected only by being connected all the time and always pinging my activity status in periodic fashion 24/7, so that from PoV of the server it's not possible to determine anything about my actual activity or online status on my workstation, because there's no relation to real-life status.
I have to use Slack for work, and the way I solve this is to have my client not send typing notifications, and have the client running on my server and repeatedly sending activity notifications all the time, so I always appear online and present to Slack servers.
I can prevent Slack from knowing when I'm really connected only by being connected all the time and always pinging my activity status in periodic fashion 24/7, so that from PoV of the server it's not possible to determine anything about my actual activity or online status on my workstation, because there's no relation to real-life status.
Would these leaks be solved by implementing a VPN at the router instead of the host?
> XMPP uses passwords for authentication, rather than phone numbers. Since the server needs to use the password to verify you are you, there should be no surprise that it is sent to the server when you create your account or change your password. Just like any website or service that utilizes passwords for authentication.
There are plenty of authentication protocols that don't send passwords in cleartext. WPA would be rather useless if that happened, for example. Granted, the server operator can impersonate anyone they want already, but password leaks are a thing.
Server-side contact handling is independent of end-to-end ecryption, and doesn't need to be plaintext either.
Pretty much the only excusable things here are what's related to IP.
There are plenty of authentication protocols that don't send passwords in cleartext. WPA would be rather useless if that happened, for example. Granted, the server operator can impersonate anyone they want already, but password leaks are a thing.
Server-side contact handling is independent of end-to-end ecryption, and doesn't need to be plaintext either.
Pretty much the only excusable things here are what's related to IP.
I believe you're slightly misunderstanding the details here (no surprise, as the article is not clear). All modern XMPP servers store the password securely hashed, and during authentication only hashes are exchanged.
Your comparison to WPA isn't quite an analogy - in the case of WPA the access point has already selected the password for the network, only authentication is needed. For XMPP and other services, the user selects their own password. This step is where the password is sent (once) to the server, upon which it is hashed and stored. That step doesn't happen in WPA, however the owner of the access point does have to securely transmit the password to the clients somehow.
Your comparison to WPA isn't quite an analogy - in the case of WPA the access point has already selected the password for the network, only authentication is needed. For XMPP and other services, the user selects their own password. This step is where the password is sent (once) to the server, upon which it is hashed and stored. That step doesn't happen in WPA, however the owner of the access point does have to securely transmit the password to the clients somehow.
> All modern XMPP servers store the password securely hashed, and during authentication only hashes are exchanged.
Huh, I didn't realize that SCRAM is this widely supported https://xmpp.net/reports.php
Thanks for the hint!
Huh, I didn't realize that SCRAM is this widely supported https://xmpp.net/reports.php
Thanks for the hint!
I see the distinction, but when I use public key cryptography, the keys are not symmetrical, and the server never sees my secret.
Indeed it was my mistake when I searched for authentication mechanisms, which aren't concerned with the initial exchange.
Still, as a non-cryptographer, I have to wonder if it's possible to make a password work while using public key crptography. Perhaps the way SSH does it: use password to unlock the private key, but only send the public key?
Indeed it was my mistake when I searched for authentication mechanisms, which aren't concerned with the initial exchange.
Still, as a non-cryptographer, I have to wonder if it's possible to make a password work while using public key crptography. Perhaps the way SSH does it: use password to unlock the private key, but only send the public key?
Yes. You'd probably want to derive your private key from the password, so that you don't have to store anything and use this method portably on multiple computers. But there's no need to ever send a password to the server, even when setting/changing it.
In theory... I don't know if there's any established auth method like this, that would eg. generate ed25519 secret key from a password, and used pubkey from it to send to the server when creating account or changing passwords and server using some challenge response, to authenticate users.
In theory... I don't know if there's any established auth method like this, that would eg. generate ed25519 secret key from a password, and used pubkey from it to send to the server when creating account or changing passwords and server using some challenge response, to authenticate users.
> I believe you're slightly misunderstanding the details here (no surprise, as the article is not clear).
The article clearly mentions that passwords are sent in cleartext to the server when the user sets/changes their password. It even clarifies that SCAM-SHA-1 won't help as hashing happens after cleartext password can be logged.
> loglevel: 5 (or “debug”) logs every single message and all activities mentioned above plus passwords in cleartext. Some XMPP proponents insisted that this isn’t true as XMPP servers use SCRAM-SHA-1 for password hashing. However, it doesn’t matter whether you enable or disable server-side password hashing as clients send new/changed passwords to XMPP servers in cleartext. The server logs the cleartext password before hashing it.
The article clearly mentions that passwords are sent in cleartext to the server when the user sets/changes their password. It even clarifies that SCAM-SHA-1 won't help as hashing happens after cleartext password can be logged.
> loglevel: 5 (or “debug”) logs every single message and all activities mentioned above plus passwords in cleartext. Some XMPP proponents insisted that this isn’t true as XMPP servers use SCRAM-SHA-1 for password hashing. However, it doesn’t matter whether you enable or disable server-side password hashing as clients send new/changed passwords to XMPP servers in cleartext. The server logs the cleartext password before hashing it.
Hi, authors here (Again, as we already have had the pleasure a while ago).
> The main problem with this article is that all the points apply equally to other services, but the article frames it such that it implies the problems are unique to XMPP.
The article never states that these issues exclusively apply to XMPP. In our opinion, users should be aware of these downsides that might be obvious to technical people, but aren't obvious to others.
And no, not all the points apply equally to other services. Even if this would be the case, then should we just withhold downsides of XMPP because these downsides might also apply to unrelated communication protocols? This article is about XMPP, not about something else.
> Pretty much everything else listed is solved by verified end-to-end encryption, which is the primary solution to these problems regardless of any platform or protocol you use.
No, as stated in the article, you can't solve most problems with XMPP by enforcing E2EE in XMPP. This article is about XMPP, not about unrelated communication protocols that might have similar problems.
> Instead of focusing on helping educate people sensibly about these things, the article seems to be a lot of biased scaremongering.
Ehm, no, again, this article lists verifiable downsides of XMPP. People should be aware of these downsides and decide on their own what they want to do. There is no need to call it "biased scaremongering."
> Full disclosure
Full disclosure: We aren't involved in any XMPP projects or any other projects related to instant messaging. No party paid for our article.
> The main problem with this article is that all the points apply equally to other services, but the article frames it such that it implies the problems are unique to XMPP.
The article never states that these issues exclusively apply to XMPP. In our opinion, users should be aware of these downsides that might be obvious to technical people, but aren't obvious to others.
And no, not all the points apply equally to other services. Even if this would be the case, then should we just withhold downsides of XMPP because these downsides might also apply to unrelated communication protocols? This article is about XMPP, not about something else.
> Pretty much everything else listed is solved by verified end-to-end encryption, which is the primary solution to these problems regardless of any platform or protocol you use.
No, as stated in the article, you can't solve most problems with XMPP by enforcing E2EE in XMPP. This article is about XMPP, not about unrelated communication protocols that might have similar problems.
> Instead of focusing on helping educate people sensibly about these things, the article seems to be a lot of biased scaremongering.
Ehm, no, again, this article lists verifiable downsides of XMPP. People should be aware of these downsides and decide on their own what they want to do. There is no need to call it "biased scaremongering."
> Full disclosure
Full disclosure: We aren't involved in any XMPP projects or any other projects related to instant messaging. No party paid for our article.
The article is a weird mix, partially very relevant information [0], partially just saying "using XMPP without E2E encryption is… not E2E encrypted" which is a weird ting to get worked up about. Maybe I’m missing something here?
[0]: And honestly, something I have not thought about. I host my own XMPP server (Prosody) with only 2 accounts, mine and my wife’s, so it doesn’t affect me. But obviously you can’t expect everyone to just host their own server.
[0]: And honestly, something I have not thought about. I host my own XMPP server (Prosody) with only 2 accounts, mine and my wife’s, so it doesn’t affect me. But obviously you can’t expect everyone to just host their own server.
I was not really expecting XMPP to do anything else by default, to be honest. If you want end-to-end encryption, the hard thing is to do the initial key exchange in a way that the server can't just MITM. It is extremely rare that somebody compares the "security numbers" of services like Signal to be sure there is no interposer. One solution might be to do key exchange by a completely separate third party.
Or, instead of running your own server, you could just move the server completely into the client (and maybe have an external server only to buffer encrypted messages while you are offline). I wonder, is it possible to send P2P data from one cell phone to another nowadays? It used to be impossible to have any incoming open port, but I think in some circumstances you can use CGNAT hole punching, connect to other users on your carrier directly, or even use IPv6?
Or, instead of running your own server, you could just move the server completely into the client (and maybe have an external server only to buffer encrypted messages while you are offline). I wonder, is it possible to send P2P data from one cell phone to another nowadays? It used to be impossible to have any incoming open port, but I think in some circumstances you can use CGNAT hole punching, connect to other users on your carrier directly, or even use IPv6?
The problem with pure peer-to-peer communication is that it is unreliable due to IP address changes and NATs, requires you to always be online (or at least both be online simultaneously) and also exposes your social graph to your ISP and any other intermediary on the network path.
Some of these can be fixed by adding servers into the mix (such as discovery/rendezvous servers, or Tor), but that doesn't solve everything.
Some of these can be fixed by adding servers into the mix (such as discovery/rendezvous servers, or Tor), but that doesn't solve everything.
Use a STUN server to assist with NAT traversal. Some DHT swarms can also assist with that.
Or use a VPN or VPN-like network, like TOR, yggdrasil, IPFS p2p, etc. Some are explicitly designed for that kind of use, and can form a mesh network with peers that are physically close.
Unfortunately, for yggdrasil that means mostly Apple's Airdrop, though that should be possible with the more recent wifi NAN "neighbour area network" (wifi aware) and P2P.
Or use a VPN or VPN-like network, like TOR, yggdrasil, IPFS p2p, etc. Some are explicitly designed for that kind of use, and can form a mesh network with peers that are physically close.
Unfortunately, for yggdrasil that means mostly Apple's Airdrop, though that should be possible with the more recent wifi NAN "neighbour area network" (wifi aware) and P2P.
These points are good to know, but as others pointed out they apply to email, Matrix, ActivityPub and other federated protocols. I believe we have published a rather comprehensive security/privacy FAQ here: https://joinjabber.org/faqs/security/
Let me know if you find some information missing in there!
PS: I don't understand why the infosec-handbook.eu article appears posted on november 1 2021. It was published in August 2018, see also: https://web.archive.org/web/20201208132104/https://infosec-h...
Let me know if you find some information missing in there!
PS: I don't understand why the infosec-handbook.eu article appears posted on november 1 2021. It was published in August 2018, see also: https://web.archive.org/web/20201208132104/https://infosec-h...
Hi, authors here.
> I don't understand why the infosec-handbook.eu article appears posted on november 1 2021. It was published in August 2018
We fully revised this and other articles as mentioned on our website. The article itself contains a note that it was republished.
> I don't understand why the infosec-handbook.eu article appears posted on november 1 2021. It was published in August 2018
We fully revised this and other articles as mentioned on our website. The article itself contains a note that it was republished.
Is there a better alternative that meets the following constraints:
* standards based: i.e. it has demonstrated commitment to openness and universality
* multi stakeholder: i.e. it has momentum
* can self host: i.e. power can reside with communities
* has clients that support encrypted video chat: i.e. I can use it today.
XMPP does that.
* standards based: i.e. it has demonstrated commitment to openness and universality
* multi stakeholder: i.e. it has momentum
* can self host: i.e. power can reside with communities
* has clients that support encrypted video chat: i.e. I can use it today.
XMPP does that.
Matrix
Why should I use Matrix over XMPP? All the problems mentioned in this article also apply to Matrix.
Matrix has introduced some really neat innovations compared to XMPP:
- decentralized conversations instead of centralized ones
- MEGOLM
- Cross Signing
- monolithic protocol (i.e. one true way of doing things officially)
- easy sync of (encrypted) history between sessions
These are reasons why people use Matrix and not because of misinformation about how private it is
Also: afaik not everything applies to Matrix, e.g. a widely used server logging passwords or a server being able to manipulate chat rooms that extensively
- decentralized conversations instead of centralized ones
- MEGOLM
- Cross Signing
- monolithic protocol (i.e. one true way of doing things officially)
- easy sync of (encrypted) history between sessions
These are reasons why people use Matrix and not because of misinformation about how private it is
Also: afaik not everything applies to Matrix, e.g. a widely used server logging passwords or a server being able to manipulate chat rooms that extensively
MEGOLM seems to be encrypted group chat. OMEMO already provides that.
Cross signing OMEMO keys would be nice indeed.
Not sure what a session is or why it needs sync.
XMPP is decentralized, maybe even more than Matrix, since almost everyone uses the official server matrix.org.
I'm not sure if all of this is reason enough to switch to an non-standard protocol, fragmenting the small space of open IM protocols even further. It would be better to implement those features using existing Internet Standards.
Cross signing OMEMO keys would be nice indeed.
Not sure what a session is or why it needs sync.
XMPP is decentralized, maybe even more than Matrix, since almost everyone uses the official server matrix.org.
I'm not sure if all of this is reason enough to switch to an non-standard protocol, fragmenting the small space of open IM protocols even further. It would be better to implement those features using existing Internet Standards.
> MEGOLM seems to be encrypted group chat. OMEMO already provides that.
No, OMEMO is rather comparable to OLM. MEGOLM is a layer on top of that.
> Not sure what a session is or why it needs sync.
When you log in (on phone, browser, ...) you create a session
> XMPP is decentralized, maybe even more than Matrix,
Certainly not technology wise
> since almost everyone uses the official server matrix.org.
Less than a third
> It would be better to implement those features using existing Internet Standards
In your opinion. The success of Matrix today is enough for me to distance myself from purely idealistic views
No, OMEMO is rather comparable to OLM. MEGOLM is a layer on top of that.
> Not sure what a session is or why it needs sync.
When you log in (on phone, browser, ...) you create a session
> XMPP is decentralized, maybe even more than Matrix,
Certainly not technology wise
> since almost everyone uses the official server matrix.org.
Less than a third
> It would be better to implement those features using existing Internet Standards
In your opinion. The success of Matrix today is enough for me to distance myself from purely idealistic views
This article triggers one of my current pet peeves. It treats privacy and anonymity as more or less the same thing. Anonymity is a sort of privacy related to identity, but it is not required that you are anonymous to have privacy. Everyone can know that I am sending encrypted messages to other people but those messages are still private. Anonymity should be discussed as a special case.
Having said that, XMPP can be quite anonymous in practice. There are public XMPP servers running on hidden services. XMPP servers do not insist that you give them any personal information at all. In particular they normally do not require a phone number.
Having said that, XMPP can be quite anonymous in practice. There are public XMPP servers running on hidden services. XMPP servers do not insist that you give them any personal information at all. In particular they normally do not require a phone number.
I wonder why did they choose to investigate plain text connection to XMPP server instead of SSL or TLS ? As far as I recall there's "starttls" command on standard 5222 port, after that things get encrypted and all their tcpdump tricks fail. Almost none of the XMPP clients use plain text connection nowadays.
> Almost none of the XMPP clients use plain text connection nowadays.
Everything shown in the article works with or without TLS enabled. It doesn't matter. The server-side party sees cleartext XMPP packets passing the server.
> all their tcpdump tricks fail
There are no "tricks" in the article. It is just capturing network traffic. The point here is that XMPP traffic isn't magically invisible to third parties that observe the network traffic as some people claim.
Everything shown in the article works with or without TLS enabled. It doesn't matter. The server-side party sees cleartext XMPP packets passing the server.
> all their tcpdump tricks fail
There are no "tricks" in the article. It is just capturing network traffic. The point here is that XMPP traffic isn't magically invisible to third parties that observe the network traffic as some people claim.
And, by the way, federated servers use SSL/TLS as well. Of course server admins can do verything, like peer into your traffic or grab passwords from database, because they are admins!
I wanted to change Matrix for XMPP, now I have one less reason to do so.
Most of the problems described here also apply to Matrix.
Also came up on Reddit: https://reddit.com/r/PrivacyGuides/comments/qkhqf7/xmpp_admi...
Also came up on Reddit: https://reddit.com/r/PrivacyGuides/comments/qkhqf7/xmpp_admi...
If only Matrix had nice clients like Conversation or Gajim instead of all those mIRC and Discord look-alikes.
Which matrix clients have you tried? Fluffychat?
I tried elements and looked at all the screenshots of non-alpha clients on https://matrix.org/clients/
Fluffychat would be okay for mobile. But that still leaves me without a primary client on my Windows PC.
Fluffychat would be okay for mobile. But that still leaves me without a primary client on my Windows PC.
Those issue applies as well to the Matrix network since the global architecture is similar :)
Basically all the issues listed in the article apply equally to Matrix, and most other communication platforms too.
There are some alternatives that overcome most of the issues with a "serverless" approach (hint: no practical communication protocol on the internet is ever truly serverless), such as Briar. However they generally have UI/UX and feature limitations that are impractical barriers to mass adoption.
If you're concerned that your communications may be specifically targeted, you should definitely consider carefully what solution meets your needs and security in the context of your threat model. Sometimes this might be self-hosting, or a pseudonymous XMPP account accessed via Tor, Signal or Matrix, or Briar, or something else.
What we need are good factual unbiased guides to inform people about the practical and security properties of various options. Unfortunately this article is not in that category.
There are some alternatives that overcome most of the issues with a "serverless" approach (hint: no practical communication protocol on the internet is ever truly serverless), such as Briar. However they generally have UI/UX and feature limitations that are impractical barriers to mass adoption.
If you're concerned that your communications may be specifically targeted, you should definitely consider carefully what solution meets your needs and security in the context of your threat model. Sometimes this might be self-hosting, or a pseudonymous XMPP account accessed via Tor, Signal or Matrix, or Briar, or something else.
What we need are good factual unbiased guides to inform people about the practical and security properties of various options. Unfortunately this article is not in that category.
In matrix, not only can your homeserver usually impersonate you, but most information/history in rooms is considered public and archived forever. I haven't followed recently if there were mitigations on this topic, but that was historically one of the reasons many activists stuck with IRC/XMPP who support ephemeral discussions and/or an explicit data retention policies (eg. keep the latest 20 messages in this room so newcomers can have a little backlog).
In case that wasn't clear, in the XMPP model, the backlog for a room is kept on the room's server, not on every individual home server. In matrix, all data is replicated on all servers (which eats massive server resources, although newer implementations like conduit seem to improve on that) which greatly increases the possibilities for a bad actor to find their way to these conversations.
In case that wasn't clear, in the XMPP model, the backlog for a room is kept on the room's server, not on every individual home server. In matrix, all data is replicated on all servers (which eats massive server resources, although newer implementations like conduit seem to improve on that) which greatly increases the possibilities for a bad actor to find their way to these conversations.
> who support ephemeral discussions and/or an explicit data retention policies
Matrix's variant of that: https://brendan.abolivier.bzh/matrix-retention-policies/
> In case that wasn't clear, in the XMPP model, the backlog for a room is kept on the room's server, not on every individual home server. In
Which makes your history dependent on a plethora of different servers. Result: very bad usability
> replicated on all servers
No, this is misleading. It is replicated between servers that have users participating in the conversation, i.e. know the conversation anyways
> which eats massive server resources
I'd like to have a source for that. To my knowledge Matrix cryptographically verifying actions between servers (prohibiting various bad actions due to the decentralized nature of rooms in Matrix) and the implied DAG is really what needs resources
Matrix's variant of that: https://brendan.abolivier.bzh/matrix-retention-policies/
> In case that wasn't clear, in the XMPP model, the backlog for a room is kept on the room's server, not on every individual home server. In
Which makes your history dependent on a plethora of different servers. Result: very bad usability
> replicated on all servers
No, this is misleading. It is replicated between servers that have users participating in the conversation, i.e. know the conversation anyways
> which eats massive server resources
I'd like to have a source for that. To my knowledge Matrix cryptographically verifying actions between servers (prohibiting various bad actions due to the decentralized nature of rooms in Matrix) and the implied DAG is really what needs resources
So the hype around XMPP is no better than Matrix then. Oh dear.
Going to keep using Matrix then.
Going to keep using Matrix then.
So the hype around Matrix is no better than XMPP then. Oh dear.
Going to keep using the IETF XMPP Standard then.
Going to keep using the IETF XMPP Standard then.
Matrix has introduced some really neat innovations compared to XMPP:
- decentralized conversations instead of centralized ones
- MEGOLM
- Cross Signing
- monolithic protocol (i.e. one true way of doing things officially)
- easy sync of (encrypted) history between sessions
These are reasons why people use Matrix and not because of misinformation about how private it is
- decentralized conversations instead of centralized ones
- MEGOLM
- Cross Signing
- monolithic protocol (i.e. one true way of doing things officially)
- easy sync of (encrypted) history between sessions
These are reasons why people use Matrix and not because of misinformation about how private it is
If there's anything that's overhyped these days, it's Matrix.
https://news.ycombinator.com/item?id=27557113 was so brilliant at capturing my own thoughts/concerns on it.
https://news.ycombinator.com/item?id=27557113 was so brilliant at capturing my own thoughts/concerns on it.
I think that bit of history shows what a false idol extensibility is. 20 years of extension and improvement has resulted in a chat system that is still staggeringly worse in practice than its competitors of 20 years ago. (Seriously, XMPP is still worse than AIM for actual day-to-day use).
Look at XML vs JSON for another example. A simple standard that has no improvement path except completely replacing it turns out to be much more usable than an extensible, upgradeable standard.
Look at XML vs JSON for another example. A simple standard that has no improvement path except completely replacing it turns out to be much more usable than an extensible, upgradeable standard.
> Seriously, XMPP is still worse than AIM for actual day-to-day use
Have you actually tried the modern clients like Conversations/Dino? I've been running a private XMPP server for friends for the past couple of years and the only way to describe it is rock-solid.
Have you actually tried the modern clients like Conversations/Dino? I've been running a private XMPP server for friends for the past couple of years and the only way to describe it is rock-solid.
I tried Conversations (admittedly a while ago) and found it a solid meh. Its features mostly worked, but it definitely felt clunkier than AIM.
Have you actually tried any alternatives at all?
Even Matrix with Element (which used to have quite a few issues with slowness and encryption), works way better these days
Not to mention any widely used centralized messenger...
Even Matrix with Element (which used to have quite a few issues with slowness and encryption), works way better these days
Not to mention any widely used centralized messenger...
Yes, in addition to my private XMPP server, I have been running a Matrix server for one of my clients for about the same amount of time.
Element desktop is... slow and terrible in comparison with all of its confusing options, and regularly kicks just a single person off the server for no apparent reason when their session becomes corrupted. I really want to use fractal but it doesn't do E2EE.
Synapse was a horrible resource hog, but conduit actually seems pretty good. Still prefer ejabberd.
Element desktop is... slow and terrible in comparison with all of its confusing options, and regularly kicks just a single person off the server for no apparent reason when their session becomes corrupted. I really want to use fractal but it doesn't do E2EE.
Synapse was a horrible resource hog, but conduit actually seems pretty good. Still prefer ejabberd.
> XMPP is still worse than AIM for actual day-to-day use
Care to elaborate? I used AIM back in the day and i have a much more pleasant and varied experience on modern XMPP, which supports many gateways to the networks i care for (including mobile phone like skype was doing! [0]).
> XML vs JSON
And yet the people who claimed XML was too complex have since then reimplemented the XML features into JSON, such as JSON schemas which are key to federated protocols (eg. ActivityPub) built on top of JSON message passing.
[0] https://jmp.chat/
Care to elaborate? I used AIM back in the day and i have a much more pleasant and varied experience on modern XMPP, which supports many gateways to the networks i care for (including mobile phone like skype was doing! [0]).
> XML vs JSON
And yet the people who claimed XML was too complex have since then reimplemented the XML features into JSON, such as JSON schemas which are key to federated protocols (eg. ActivityPub) built on top of JSON message passing.
[0] https://jmp.chat/
Hype and (related) money is what open messaging needs at the moment. XMPP is fine, it’s stable, extensible and generally works, but average users have never heard of it.
Those parts of matrix needed for interop need to go through the spec change proposal process to land in the spec. But namespacing is used extensively. The spec reserves the 'm.' prefix, e.g. 'm.text', but everyone is encouraged to extend using reverse dns namespacing, e.g. 'com.ycombinator.news.our.extension'.
Half the article is dedicated to obsessing that the server can see your IP address. This is true of every internet service, and is how the internet works. Tools to solve this (e.g. Tor, VPNs) are well known and established solutions if you need to hide your IP from websites and services you use.
Common alternatives to XMPP that people may recommend include Signal and Matrix, but both certainly see your IP address just as easily.
XMPP uses passwords for authentication, rather than phone numbers. Since the server needs to use the password to verify you are you, there should be no surprise that it is sent to the server when you create your account or change your password. Just like any website or service that utilizes passwords for authentication.
Pretty much everything else listed is solved by verified end-to-end encryption, which is the primary solution to these problems regardless of any platform or protocol you use. Again, not a problem with XMPP specifically.
Instead of focusing on helping educate people sensibly about these things, the article seems to be a lot of biased scaremongering.
Full disclosure: I'm actively involved in various XMPP projects, including the XMPP Standards Foundation, Prosody and Snikket. Obviously I have a very keen interest in protocol design, secure online communication and the various available platforms/tools.