Comment by mmahmad | Hacker News Reader

Comment by mmahmad | Hacker News Reader

Parent Full thread

They say it doesn't solve the problem

- "Would adding federation to Signal help with users behind country-wide blocks? Seems like a distributed service would be harder to censor than a centralized one."

- "It's trivial to block several distributed hosts simultaneously. An aspiring censor would simply find the most common federated endpoints for a given service and block all of them. Only the users of that software would be affected. There wouldn't be any collateral damage. If the censors somehow didn't hit every single worthwhile federated endpoint, users would still be left wondering why they couldn't communicate with most of their friends. Moving between federated hosts would also necessitate an entirely new identifier, so users would need to rebuild their social graph again.

In addition to being ineffective against censorship, there are several other properties and trade-offs that make federation a difficult proposition for an application like Signal: https://signal.org/blog/the-ecosystem-is-moving/"

src: https://news.ycombinator.com/item?id=16868564

I'm not sure this holds water, really - all you need to solve this is to allow identity to migrate between servers (by linking it to a keypair held by the user), or for that matter go the whole hog and go p2p rather than federated.

Matrix is currently working towards transparent migration (account portability) between servers with p2p as a longer term target - and meanwhile projects like Status are going all the way to p2p today.

I think it may depend on how well distributed would a service be: having several big servers would not help but if every family and company had their own mini server, located in a non-censoring country then the censors would be unable to do anything easily. These servers, in turn, would be able to easily connect to the broader network. Of course that wouldn't be as easy to setup as a simple installation of the Signal app.

An aspiring censor could also "easily connect to the broader network" and masquerade as a federated server in order to discover others. This process could even be automated.

Federated services also require an identifier, and this identifier usually indicates where the user's account is located and how to connect with them (e.g. user@domain.com). As people share these identifiers, the aspiring censor can just keep adding new entries to the blacklist.

At least in case of XMPP, the client doesn't need to be able to connect to other domains, so as long as you can connect to your own server outside of the censorship's reach (which could be accessible for c2s connections in a completely different way than for s2s), you should be fine.

How do you ensure the censor doesn't block the major c2s connections? I suspect most techniques are too technical for your average user.

Modern clients can connect via port 443. There is also support for XMPP via WebSockets, that looks like regular HTTPS traffic.

Sure, but they can just block the IP.

Yes, but it's always possible to block IP (targeted attack). Federated with a big amount of small servers make it hard to automate. You can block several hosts but the rest of the network would work fine. And because of how federation in XMPP works you just need a one client to server connection to reach the entire network.

In XMPP you cannot easily enumarete other servers s2s connections. If the censor connects as a client he can only see their own contacts.

As for sharing IDs if you post them publicly then of course they are revealed and can be blocked.

When hosting one of those servers could potentially get limbs cut off, that makes it a much less attractive proposition.

It sounds like a hard thing, but in case of XMPP "rebuilding your social graph again" is very easy - it's just a matter of importing your roster and sending authorization requests where needed. Could be, and probably already is, easily automated with some user friendly tool.

If the solution to censorship is to constantly switch to new hosts, it would be even easier to do this via a VPN (which wouldn't require you to rebuild your social graph at all, unlike a federated endpoint switch).

If the more straightforward solution (VPN) isn't a panacea for censorship, then federation isn't either.

Of course it's not a "panacea". It just makes some situations easier to handle, including server operator going rogue or broken by government. It doesn't magically provide answer to everything, but it's definitely an improvement when compared to purely centralized networks.

Reply on news.ycombinator.com