An argument that centralized systems will be more secure

#1

This, by Moxie Marlinspike (of Signal fame) is a cogent argument that open, decentralized systems will not be as secure as centralized platforms. Excerpt:

One potential benefit of federation is the ability to choose what provider gets access to your meta-data. However, as someone who self-hosts my email, that has never felt particularly relevant, given that every email I send or receive seems to have gmail on the other end of it anyway. Federated services always seem to coalesce around a provider that the bulk of people use, with a long tail of small scattered self-hosting across the internet. That makes sense, because running a reliable service isn't easy, but it's an outcome that is sadly the worst of both worlds.

If anything, protecting meta-data is going to require innovation in new protocols and software. Those changes are only likely to be possible in centralized environments with more control, rather than less. Just as making the changes to consistently deploy end to end encryption in federated protocols like email has proved difficult, we're more likely to see the emergence of enhanced metadata protection in centralized environments with greater control.

https://whispersystems.org/blog/the-ecosystem-is-moving/

#2

This is an argument against federation, rather than against de-centralization. For example, the messenger Ricochet is de-centralized, but not federated. Ricochet uses client-side Tor hidden services to create server-less chat, but Ricochet clients only talk to other Ricochet clients and only receive updates from the Ricochet developers.

The same can be said of Tor. Sure, you can run a Tor node, but you need the directory authorities' blessing to be a part of the network, and you receive your updates from the Tor Project. Try playing with the Tor source code: compile your custom binary, spin up a dozen nodes, and watch how fast your uniformly anomalous nodes will be throttled or banned (to be clear, this is a good thing and I agree with the Tor Project for doing this; the recent CMU attack on the Tor network worked by spinning up a bunch of modified malicious Tor nodes).

Compare this to XMPP or TLS, both of which are described by standards managed by the IETF (Internet Engineering Task Force). The IETF issues RFCs describing the protocol, and anything that fits within that description and can speak to other implementations of the same protocol is kosher. That's federation. Thus, we have OpenSSL, BoringSSL, and LibreSSL. Don't like any of those? Write your own TLS implementation! Just remember to encrypt and then mac.

It's perfectly feasible to decentralize your infrastructure without suffering the stultification that Moxie aptly argues is associated with federation. For now, Signal is neither federated nor de-centralized. However, there is no reason that Signal could not operate as a mix network (thus obscuring meta-data), which wouldn't have anything to do with federation. A senior OWS dev has mentioned that something like this is one of their long-term goals.

Running one implementation and being able to push updates to the whole network makes a project nimbler. A non-federated network need not be centralized.

#3

Interesting. I think you're drawing a distinction between centralized control (e.g. the ability for one actor to update the protocol) and centralized routing (e.g. all clients talk to a single server for directory services.)

Do I have that right? I haven't heard "federated" used in this way before. All these words mean too many things.

#4

Yes, that's correct. It's confusing, because these terms have overlapping meanings. Even the distinction between "federated" and "centralized" is not necessarily strictly defined, since one can argue that a non-federated service is "centralized" insofar as all clients receive updates from a small team of devs, who can ban unauthorized clients. Under this definition of "centralized," the Tor network is also centralized.

"Federated" is a term of art that refers to a protocol defined by a standard (which is usually maintained by the IETF). The actual code implementing the standard is not defined. Anyone can write such code. In order to comply with the standard, any such implementation must be able to talk to other clients/servers that also comply with the standard. Examples include: email, http, xmpp, and tls.

"Centralized" is not a term of art, it's a political term whose meaning changes depending on your point of view. For Open Whisper Systems, unacceptable centralization would mean collecting user's plaintext data on their servers or using proprietary crypto libraries. For critics of OWS, unacceptable centralization means refusing to allow non-official clients to connect to the OWS servers, or refusing to allow Signal users to connect through non-OWS servers and talk to non-official clients that implement the Signal Protocol.

If you want to watch people argue about this stuff, here's the OWS Github issue thread that spawned the argument that provoked Moxie to write that post.