https://blog.mathieui.net/xmpp-and-metadata.html

mathieui's blog

I develop stuff and have opinions on things -
About me/Contact

Articles:

  * 01/2026 XMPP and metadata
  * 12/2025 XMPP at 39C3!
  * 11/2025 This is no...
  * 10/2025 slixmpp v1.12
  * 09/2025 slixmpp v1.11
  * 07/2025 Being a ch...
  * 04/2025 The Signal...
  * 04/2025 Things tha...
  * 03/2025 Poezio 0.1...

XMPP and metadata

  * by mathieui
  * on Tue 06 January 2026

Tags: xmpp ccc xmpp-en

I had the pleasure of giving a talk on "XMPP and Metadata" during the
last Chaos Communication Congress, in the Critical Decentralization
Cluster area. It was my first public presentation in a very long
while (also in english), so the talk went okay-ish at best. The end
of the year was also hectic and I did not manage to prepare or
rehearse as much as I would have liked to.

This blog post will be a longer, more complete version of the talk.
You can nonetheless find the talk slides on the CDC pretalx. Thanks a
lot to the people who proofread the blog post to fix stuff or suggest
additional content.

This was about metadata, but also generally data retention and what
the server sees in general.

Metadata

First I want to define the basics: metadata is data about the data.
In a messaging system, data is usually considered to be the message
contents (what is being exchanged), and metadata is about the
envelope:

  * who (sender and receiver)
  * when (timestamp)
  * hints about the what (e.g. payload size)

Outside of messages, you can additionally have data/metadata about
the users themselves, like online status or location, which can be
either sent in the clear to the server, or deduced from user
activity.

Obvious message workflow

This might be too obvious for most people, but for clarity's sake, I
want to assert that to send a message to another entity, you need:

  * a sender
  * a message
  * a receiver

This is not technical, this is baked into the concept of sending a
message. Those elements will always be present somewhere in the
workflow. Assuming a working encryption system, the message data
itself will not be considered.

There are, however, some technical tricks that can hide a lot of
things from the infrastructure layer.

XMPP

I cannot really make this an introduction to XMPP but to summarize,
XMPP is an extensible federated protocol for messaging and presence.
It is using XML for the most part but nobody should care (except
trolls, I guess). It started in 1999 as Jabber, and grew to be an
IETF standard under the name XMPP after Jabber got bought by Cisco
(we can still use the Jabber name in many ways).

The protocol started server-heavy with light clients - and in fact,
you will read as much in the "XMPP, the definitive guide" book -, but
the trend got reversed in the last decade due to the rise of mobile
clients which can be updated very often and other circumstances.

There are clients and servers, and it is therefore a protocol made of
client-to-server interactions and server-to-server interactions, each
with their own privacy implications.

The key elements to remember in order to assess threats in the XMPP
network fabric would be:

  * Your server is the only entity sending data to other servers.
    Every single bit of XML your XMPP client sends goes through your
    server.
  * Other servers will only see your interactions with their own
    users.

Those two points are true in most non-P2P models. Centralized models
can be thought as a specialization of this model, but with only one
single server.

That is why it is essential to rely on a server you can trust, either
operated by people you trust, or at least who have some
accountability in place, for example the services listed on
providers.xmpp.net.

Threats

I can roughly point out four types of "passive" threats on metadata
for XMPP:

  * A server compromise (present)
      + Correlation of data streams in real time
  * A server compromise (future)
      + Exploitation of the static data available on the server
  * An attacker present on the server network
      + Can see what the server does (both with clients and servers)
  * An attacker on the client (your) network
      + Can see what your client does

Network metadata threats

Client network attacker

Only a bit of metadata is visible on the client network:

  * Timing and size of every network call
  * HTTP(s) interactions that cross the XMPP boundary, like file
    upload
  * Jingle interactions
  * Other services (STUN, TURN services, etc)

On XMPP, one client - with only one account - will only ever connect
to the XMPP server the account is living on. Some services might go
through HTTP, which then cross the boundary and create networks calls
outside of the XMPP TLS stream, like HTTP Upload (XEP-0363).
Likewise, application like audio, video calls or direct file
transfers will also cross that boundary.

STUN and TURN servers are used to bypass NAT restrictions which are
everywhere nowadays. STUN can be described as a way for clients to
find out their reachable address from behind the NAT, and then use
that to establish a peer-to-peer connection, and TURN is used in the
more restricted networks where a relay is necessary to be able to
communicate. In the case of TURN it creates yet another server
overseeing the -encrypted- communication, and in most modern XMPP
setups the server operator also operates a TURN server; a network
attacker will also see the encrypted stream to the TURN server from
the client. In the STUN case, clients will do a short network call to
find out their external address, then establish the direct session to
the other user, making that metadata available to an attacker as
well.

A diagram showing the client network interactions in XMPP. All data
goes through a TLS stream to the server, except HTTP interactions
that are handled separately.

I do not know of any work related to fingerprinting encrypted
client-to-server XMPP traffic, but I would guess that it is fairly
easy if no precautions are taken.

Some examples:

  * Ping (XEP-0199) as connectivity check: periodical request/answer
    to your server, with a fixed size
  * Room join (XEP-0045): send disco, receive disco info, send join
    request, receive plenty of presences in a short period of time
  * Sending messages: composing chat state (somewhat fixed size),
    sometimes followed by other chat states (e.g. paused), followed
    by a longer payload, the message, which size can often be
    predicted by the time since the chat state.
  * etc...

This metadata will depend on the XMPP client used and how much it is
customized, because while protocol workflows are mostly the same for
all clients, some might do different or extra steps in common cases.

Server network attacker

A diagram showing the server network interactions in XMPP. An
attacker can see both what data comes from/to client, and from/to
servers.

If an attacker can eavesdrop on the server network, it gets access to
a lot more info than on the client network:

  * It has a view on both open client and server connections
  * It can then correlate quite easily the destination of stanzas
    sent by the client (since it will see something go from the
    client to the server, then immediately something from the server
    to another server)
  * If the server has lots of active users, it makes it harder to
    correlate, but metadata of single-user servers are a very easy
    target!

A diagram showing the server network interactions in XMPP. An
attacker can see both what data comes from/to client, and from/to
servers.

If there is plenty of activity on the server, it will be much harder
to find out what the source of the activity is:

A simple diagram showing the inside of an XMPP TLS stream, with
various types of stanzas from different JIDs going to a specific
server.

All stanzas are going through a single stream for each destination
server which makes it difficult for an observer to find out which
payload is going where provided there is enough activity, and luckily
XMPP is a somewhat chatty protocol.

Server compromise

On-disk data and metadata

In an event where a server gets compromised later (or even a backup
gets compromised), it is important to know what kind of data and
metadata will be visible to the attacker.

There is a lot of data available on servers with normal XMPP usage,
and a few categories stand out.

User accounts

Accounts are tied to a specific server; they can in some ways be
migrated to another server but the process is currently not fun.

For a normal user, one of the important troves of metadata is the
roster (contact list): it contains all the people you have added to
the list, which allows you to put them in groups, as well as letting
the server broadcast your online presence when you get online.

Another important piece of information is your bookmarks list: this
allows you to sync the chatrooms you are in between all your clients,
but incidentally that information stays in cleartext on the server as
well.

The most identifying piece of information about the user on the
server can be the vcard, as it is litterally a collection of personal
data (including the user's avatar).

And the server will usually store some useful information it can know
without asking the user: date of last connection, last seen IP
address, etc... Some of this data can be very useful to assist manual
account recovery!

Groupchats

Groupchats in XMPP are hosted on a specific server, which does not
have to be (and often isn't) the user's server. The room identifiers
are in the form room@a-groupchat-server.net, where 
a-groupchat-server.net gives the information of where the room is
hosted.

The server hosting a persistent room needs to keep, on-disk:

  * A message archive - not mandatory but very nice to have -
  * A members/admins/onwers/ban list; only the owner list is
    mandatory, as long as everyone else is fine with being a "normal"
    participant
  * Data related to the room, like configuration, access control
    (which can be tied to membership), topic, etc

There are two types of rooms:

  * Semi-anonymous rooms, where only room admins (and their servers,
    as well as the room server) can see the real addresses of the
    users exchanging messages, creating a pseudonymous situation.
  * Non-anonymous rooms, where everyone sees everyone's addresses;
    here all participants and their servers can know who is in the
    room and authors messages.

In terms of live data, due to how XMPP is designed, all servers of
all the active participants will be able to see who is sending
messages:

A diagram showing how a message goes from a client to all the other
participants clients, through the user's server, then the groupchat
server, then their servers, and also back to the original sender.

But in semi-anonymous rooms, they only get a nickname, and not the
real address.

Live stream interception

As stated earlier, choosing a server you trust is the very first
step, and if you do not trust your server (and operators) at all, why
are you there?

If the server itself is compromised, the point-to-point TLS
encryption between client and servers, and between servers, becomes
very much useless, which means "server network attacker" scenarios
can now be matched with 100% precision, and more:

  * Correlation between sender and receiver is exact
  * The user's XMPP address can be mapped to an IP and port
  * Stanza type is exposed, whether <message/>, <iq/>, <presence/>
    stanzas are sent, everything is known
  * Activity patterns can get a lot more detailed
  * E2EE still works to protect data - but can get disrupted -

Some solutions for XMPP

Remediation of network metadata leaks

I do not see magic bullets here, and everything has a cost. The idea
would be to add noise that is not easy to filter out when parsing
network activity at scale.

  * Inserting random padding in server-to-server and client-to-server
    communications would help, of course, but network data is not
    always cheap, and processing XML also has a cost.
  * Another solution would be "garbage" stanzas sent in various
    manners to other servers, but again there is a cost here, and
    since very little litterature exists on such attacks, it remains
    to be seen that there is an upside to this.
  * Another one would be to allow stanzas to be grouped on the wire
    when possible (e.g. presence updates or groupchat messages)
  * The last one I can see would be to induce random delays in stanza
    delivery when processing them on a server. This has of course a
    usability cost, but for large servers, adding random delays <
    0.3s would probably be enough to make correlation quite hard, but
    of course ordering must be preserved.

Remediation of roster issues

Presence-based messaging has been going downhill for a while thanks
to a smartphone-centric population and apps, which means the roster
is not as useful as it could once be.

It still provides useful information in my opinion, and is also very
useful for abuse prevention, since you do not receive abuse from your
contacts - hopefully -.

The roster could be stored on devices instead of servers, and we
could find a way to share it encrypted and cross-signed with the
user's other devices. This does not change the fact that your server
will see who you are chatting with or sending presence to.

The bookmarks could likely be shared in the same way, and removed
from the server as well.

Fixing groupchat metadata

As mentioned earlier, if we phase out presences in many cases, being
passively inside a room would at least prevent being exposed to
servers looking at the traffic, as long as nobody requests the
participants list.

I do not see a good way out of this for metadata.

Fixing many types of metadata issues

The most deployed end-to-end encryption solution on the network is
OMEMO, but not in its latest version, which allows for Stanza Content
Encryption. The version most people use only encrypts the message's
body tag, which is the text sent by the user. By extension, uploads
are also encrypted there because they are encrypted using OMEMO Media
sharing which is really just encrypted using AES-GCM with a key and
IV shared inside the URL sent through the OMEMO session.

This means people wanting to use nice features like composing chat
states and the like have the choice to either generate this metadata
in the clear, or disable the feature, which is not ideal.

Other interesting solutions

Serverless messaging

XEP-0174 describes how to operate XMPP inside a trusted network,
which bypasses the need for a server by using mDNS on this network
and advertising your address with your local IP.

I liked it a lot and had fun at the time, but it was from a blissful
era where encryption was not seen as the foundation upon which
everything should be built. It means that everything transits
unencrypted on the network, both metadata and data are unprotected.
Data could be encrypted using OTR, but some required bricks for the
modern XMPP experience like the Personal Eventing Protocol are
unavailable, making OMEMO in its current form a no-go.

Implementations are scarce nowadays, as an incomplete XMPP layer
inside a normal client is usually pretty convoluted to maintain and
after a while it was removed from most clients where it existed.

The modern replacement is RELOAD, but implementation and deployment
is just starting, so it is a bit early to know if it is a good
solution or not.

XTLS

XTLS describes a way to create a direct and encrypted TLS stream
between two entities using jingle, which could be then used to
exchange stanzas in a secure manner, without going through the
server.

That means that the metadata threats shift from server-based to
client-based, which can be an upside or not at all. The layer used
for the channel is also quite important, as it could be In-Band
Bytestreams (which means the data goes through the usual
client-server-server-client route) which would then provide
additional E2EE cloaking of all data exchanged between clients, but
still going through all the entities to route data.

Cryptographic identities

Strong cryptographic identities as outlined in XEP-0416 could serve
as a framework for removing some of the requirements for trust in the
server. I do find X.509 a bit too complex for what we want to do with
it, but I did not dive very deep into this spec.

Other services/protocols

Signal

Signal is a pioneer in encryption systems at scale, and keeps pushing
the boundaries of what is possible to do securely. Nonetheless, their
messenger is centralized, with systems running on AWS and Azure (as
far as I can tell), which makes them very dependent on the US
political wasteland as well as the tech landlords' whims.

They do a lot of things to ensure things are as secure as it can be
within the constraints they imposed on themselves, and as such while
I trust them for now, their servers certainly have a lot of
opportunities to collect and store a ton of metadata, simply due to
the fact that this is a centralized system. While their cryptography
work is class-leading, which makes my data secure (as long as someone
does not bust the secure enclave which protects my "recovery code" I
guess), keeping my metadata volatile and secure there is only a leap
of faith on my part, as I can have no guarantees.

A diagram showing every client connects to a single entity, because
signal is centralized.

Matrix

Matrix is a federated protocol which has many of the same flaws as
XMPP with regards to metadata.

One notable difference is that matrix is more like a distributed
database with built-in conflict resolution, which leads to every
participant's server replicating the state (data and metadata) of the
rooms they are in. This creates a more difficult situation for
metadata than XMPP, because while XMPP servers can see what goes
through them, in Matrix the servers are required to store this
information.

Matrix also has two different sets of APIs for client-to-server and
server-to-server communication, which should allow it to batch
messages when appropriate.

SimpleX

SimpleX is a protocol with a lot of cryptography baked in, and has
interesting properties such as the absence of user accounts and
therefore identifiers (which means very little data on the servers
can be compromised).

One of its more interesting properties is that it has 2-stage onion
routing baked in, which allows it to sidestep many issues around
metadata due to connecting to servers.

Diagram showing how a message can be encapsulated several times using
onion routing, so that only the final recipient knows of the message.
(credit: Wikipedia)

The whitepaper stresses that it is still important to choose your
servers well, but that is still less critical than in XMPP since you
can easily switch at very little cost.

(P.S.: calling your protocol "SMP" is not nice if it is not based on
the Socialist Millionaire Protocol, I haven't checked but skimming
did not reveal any mention of it)

Conclusion

As Daniel noted on mastodon, there are some low-hanging fruits to
improving the metadata issues around XMPP (and some higher-hanging
fruits as well). I agree that this is not going to be even a blip on
XMPP adoption, but we should do what we can nonetheless to improve
the situation, in order to improve the standard and the ecosystem.
That said, I can perfectly understand that since a lot of the work is
purely volunteer-driven and our time and energy is limited, it can
appear to be a waste of time to dedicate them to removing bits of
metadata here and there.

If you have remarks or suggestions concerning this article, please by
all means contact me.

Proudly powered by Pelican, which takes great advantage of Python.