Buy European

What metadata does XMPP leak?

• Sender's Full Jabber ID (JID): This is typically in the format user@domain.com/resource. The user@domain.com part identifies the user and their home server, and the /resource identifies the specific client device they are using (e.g., alice@example.com/mobile or alice@example.com/laptop).
• Recipient's Full Jabber ID (JID): Similar to the sender's, this specifies who the message is intended for, including their user, home server, and often the specific resource.
• Sender's Server: The domain of the sender's JID reveals which XMPP server the sender is connected to.
• Recipient's Server: The domain of the recipient's JID reveals which XMPP server the message is being routed to.
• Timestamp of Message Transmission: Servers record when a message was sent, which can be used to infer activity patterns.
• Approximate Message Size: While the exact content is encrypted, the size of the encrypted stanza can still be observed. This can sometimes give clues about the type of content (e.g., a small text message - versus a larger file transfer).
• Message Type (e.g., chat, group chat, presence, IQ): XMPP uses different stanza types for various purposes. Even with E2EE, the type of stanza (e.g., a "message" stanza vs. a "presence" stanza) is visible.
• Participation in Group Chats: If a user is part of a Multi-User Chat (MUC), the MUC service and the user's participation in it are known to the MUC server and potentially other participants' servers.
• Presence Information: XMPP inherently broadcasts presence (online/offline status, "away" messages, etc.) to contacts. This reveals when a user is active.
• Contact List (Roster) Information: While not "leaked" during every message, the XMPP server hosts and manages the user's contact list, meaning the server knows who a user is communicating with.
• Device Information (Resource): As mentioned, the /resource part of the JID can reveal the type of client or device being used.

I find it strange that Signal somehow doesn’t know when a message was sent

Signal uses Sealed Sender (wired.com). Imagine if letters you sent didn't require a "from" field - or it was inside the envelope and impossible for anyone to see it. The post office would only know who its going to and only the recipient can decrypt it (open the letter) to see who sent it. Now, you could say, well they have your IP and can correlate it to the account, but the easy way around this is to either use a VPN or Signal proxy (support.signal.org) if you're that paranoid.

how would they ever make this possible?

Read more about it here: Technology preview: Sealed sender for Signal (signal.org)

How about most e-mail providers? Not Google and Microsoft of course, but most e-mail providers only need a name which can be made up as well

Most email providers suffer similar metadata leaks as XMPP because:

• 1. Email was created in the 70's and we've learned a lot since then about privacy and security.
• 2. XMPP works off a similar concept where you inherently pass data along to another server.

You could host your own email, XMPP, or Matrix server - that's definitely a win for privacy. But as soon as you interact with someone outside your ecosystem (server), metadata leakage is an issue again. It's why making end-to-end encrypted email is a hard problem to solve. It's not that it can't be secure, its that it has to work with those that aren't because that's the expectation.

... host your own email server, then you are in control

Until you interact with others who aren't using encryption or have it misconfigured.