Poll: Is Federation/Decentralization bad? (and notes on XMPP)

General
1
Are federated/decentralized messengers bad?
  • No
  • Not always, but centralized messengers are preferable
  • Yes, decentralization is bad for instant messaging but okay for communities
  • Yes, and decentralization is ALWAYS bad
0 voters

Arguments for decentralization: users have more control over their data and who to trust, can’t easily be censored, often allows third-party clients, and can’t easily be compromised since no single entity controls it.

Arguments against decentralization: decentralized systems are more difficult to secure as new security features can’t be implemented easily unless a single entity controls it, and centralized messengers ensure security by forcing everyone to use the same secure setup instead of letting people choose their own client and server.

Take Email for example. You can choose any provider and PGP encrypt your emails, but if you’re sending emails to Gmail users, does any of that matter?

As of now no federated messengers are recommended on PG. Element used to be recommended until forward secrecy became a minimum requirement.

The only other federated system worth mentioning is XMPP which compared to Matrix is more lightweight and decentralized (most Matrix users use Element and Matrix.org) but does not use E2EE by default. OMEMO supports forward and future secrecy and has been audited.

The biggest problem keeping XMPP from being recommended is the lack of a cross-platform client that uses OMEMO by default for 1:1 chats at least. XMPP also reveals information including your timezone and OS information to people you chat with although some clients such as Gajim and Dino have an option to disable this or don’t reveal your time zone at all.

2

Recently a self-proclaimed “security researcher” published a blog post where they entirely miss the point and make the worst recommendation possible, to use Signal. Here’s the short and simple reason you should ignore it.

lol shots fired @soatok

3

I think this poll has issues. All options except “No” are phrased against federated/decentralized messengers, the explanation below is overall biased against decentralization. Further, I don’t have a clear understanding but I suspect decentralized and federated are similar but have differenences; are all decentralized systems federated?

To answer the poll’s question, I would say that decentralization is not inherently bad, but some decentralized messaging systems have practical design/implementation issues like no PFS, optional E2EE, insecure clients; or more briefly “No, but some protocols and clients have problems.”

1 Like
4

Depends on how you define federation I suppose. Our definition here makes a distinction between federation and P2P networks, but both are decentralized:

5

Element remains recommended for group chats, which is where federation is probably most useful anyways, but I see our category names are confusing after we moved it to a different page. I guess that change wasn’t fully completed as I expected it to be. I’ll make some edits to make this more clear.

6

This blog is just poor quality and personal takes without strong reasoning.

Because people have brought it up, I want to stress that while forming a Threat Model is critical before considering privacy, it is not applicable in any way to my main point up above. This is because there is no threat model where you need sound e2e to protect you from a provider, but trust that same provider to push any code they want to your system silently and automatically. That simply doesn’t make sense.

That’s the entire point of threat modeling to determine if you trust an entity or not. This is a very poor take in my opinion.

This blog does not have the same technical chops as soatok. It’s pretty much saying “centralization bad”, and “supply chain attacks can happen”. Yeah, but that doesn’t mean that XMPP just became immune these attacks: poorly made clients are now a threat, and the supply chain trust is deferred to someone else. Who’s to say client X doesn’t have malware in it.

In fact decentralizations comes with its own set of problems that can lead to siloing. Matrix has silod most usage to Element. Other clients have varying degrees of security and implementation, and IO wouldn’t trust them that much.

The protocol is actually hindering itself. Backwards compatibility is extremely commendable in the age of throwing stuff away and rot. But that compatibility comes at the cost of E2EE disabled by default.

They don’t control the server so they can’t ban you from using another client

Cons, no alternative clients. Pros, they can keep out poorly implemented clients or even malicious clients.

Use XMPP, stay free!

This is my takeaway: The blogs point isn’t about security, it’s about freedom. This is a solid argument against Signal. But the security aspect of this post is not good. I’m not going to stop using Signal just because it may not be good in 5 years - any XMPP client is also prone to exploits in 5 years too, and I can’t even imagine trying to move any of my network to XMPP. Again, love the extensibility built into XMPP, but E2EE not enabled by default is a no-go for me.

Finally, the main reason I don’t recommend this for threat models requiring E2EE, is straight from the mouth of the XMPP spec:

Status
Experimental
WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.

3 Likes
7

Most people do not realize how much background work well designed systems do, because being well designed, they don’t see it. Ask them how will they enforce “disappearing messages” and suddenly all the ideas run out. Signal’s ideas on how to groups without server trust, preserve profile info, etc. while keeping the app usable from my grandparents is exceptional.

Since none of them have security arguments, they muddy the water with tangential stuff like supply chain, or clients backdoored, etc. (signal clients reproducible btw), to drag the argument back to why the protocol they like is the best protocol.

1 Like
8

No messenger has solved this

9

I agree. Signal reduces the probability by reducing the number of clients.

10

Client is irrelevant. Screenshots? Cameras?

1 Like
11

Unsolvable, not in scope.

1 Like
12

There’s a reason Signal became sorta mainstream whereas XMPP and Matrix never have and likely never will. They’re less private, less secure, and much more difficult to use. That’s not to say decentralized systems must be that way, but the computers and internet of today is built around centralization. Trying to work around that is a massive uphill battle, one where you probably can’t reach the top until we resolve more fundamental issues with technology.

Also the writer acts as if having multiple clients and servers gives some sort of strong protection against a central authority, but there’s another 2 points to consider:

  • If you want your federated service to be more usable to the average person, you’re gonna need a “default” client and instance. This is how it works for Mastodon and Matrix and it means the majority of people will still be “vulnerable” to the same issues with centralized services.
  • Why should people leave Signal for a much less private and secure service (which objectively makes them more vulnerable) in order to prevent some sort of hypothetical attack which we have little reason to expect in the first place?
2 Likes
13

I doubt privacy and security had as much to do with it as convenience because all of them are thought to be privacy-friendly or advertised that way. And XMPP isn’t difficult to use. Just pick a client and provider and registration is easy.

Which defeats the whole purpose of federation.

People have different threat models and use cases. XMPP doesn’t ask for your phone number (depends on provider) or forbid third-party clients (so users of niche operating systems or Android users who only use F-Droid aren’t excluded). It’s true XMPP and Matrix aren’t as secure as Signal but they aren’t a security nightmare.

14

I read in some post that there isn’t a big point for having E2EE in group chats. Not sure how I feel about it.

15

They can make whatever marketing claims they want, XMPP (for the most part) is absolutely not very private or secure and it’s one of the main reasons it isn’t typically recommended by resources like Privacy Guides.

Easy to us, yes. Speaking from personal experience, the average user of today would find XMPP frustrating to learn and use. Respectfully, I think people who believe federated services are as easy as something like WhatsApp are just out of touch. This should be evident based on the size and nature of their user base. How many of your tech illiterate family and friends do you primarily talk to over XMPP? (If any, is your chat at least partially E2EE with something like OMEMO?)

Usability is made even more complicated when you also want to try to make XMPP as private and secure as possible, which is what your source is advertising it as. Not only do you have to learn about federation and pick an XMPP client and server. Additionally you must also pick from a set of fragmented and weak E2EE protocols which are only compatible on certain clients, all just to achieve only partial E2EE and 0 metadata protection.

Exactly, and it is what the most popular federated services resort to. It’s one of many reasons I think federation is not a great way of trying to achieve decentralization, but attempting it was probably a necessary step towards progress.

I agree there’s niche use cases for XMPP, but a widely adopted secure messenger is not one of them. What it offers today might’ve been compelling 15+ years ago, but we just have better tools today. If you want an anonymous, secure, decentralized messenger, I think SimpleX Chat would be my first recommendation. Matrix and/or Session would perhaps come in second or third. I don’t foresee any situations where I’d use or recommend XMPP.

I’d say it is a security nightmare. I skimmed through the text but don’t see how any of it addresses any of the security problems XMPP has.

1 Like
16

Yeah I disagree with people who downplay the need for encrypted group chats. I require and use them myself. Yes, the more people involved the more likely it is to be compromised. But that doesn’t mean we should give up entirely, it’s not all or nothing. The only exception might be public communities, but that’s different from a group chat.

17

Matrix is even worse.

At least OMEMO supports forward secrecy so that would put XMPP above both Element and Session.