Moxie Marlinspike, the creator of Signal gave a talk at 36C3 on Saturday titled “The ecosystem is moving”.
The Fahrplan description of that talk reads as follows:
Considerations for distributed and decentralized technologies from the perspective of a product that many would like to see decentralize.
Amongst an environment of enthusiasm for blockchain-based technologies, efforts to decentralize the internet, and tremendous investment in distributed systems, there has been relatively little product movement in this area from the mobile and consumer internet spaces.
This is an exploration of challenges for distributed technologies, as well as some considerations for what they do and don’t provide, from the perspective of someone working on user-focused mobile communication. This also includes a look at how Signal addresses some of the same problems that decentralized and distributed technologies hope to solve.
https://fahrplan.events.ccc.de/congress/2019/Fahrplan/events/11086.html
Basically the talk is a reiteration of some arguments from a blog post with the same title he posted back in 2016.
In his presentation, Marlinspike basically states that federated systems have the issue of being frozen in time while centralized systems are flexible and easy to change.
As an example, Marlinspike names HTTP/1.1, which was released in 1999 and on which we are stuck on ever since. While it is true that a huge part of the internet is currently running on HTTP 1.0 and 1.1, one has to consider that its successor HTTP/2.0 was only released in 2015. 4 / 5 years are not a long time to update the entirety of the internet, especially if you consider the fact that the big browser vendors announced to only make their browsers work with HTTP/2.0 sites when they are TLS encrypted.
Marlinspike then goes on listing 4 expectations that advocates of federated systems have, namely privacy, censorship resistance, availability and control. This is pretty accurate and matches my personal expectations pretty well. He then argues, that Signal as a centralized application can fulfill those expectations as well, if not better than a decentralized system.
Privacy
Privacy is often expected to be provided by the means of data ownership, says Marlinspike. As an example he mentions email. He argues that even though he is self-hosting his emails, “each and every mail has GMail at the other end”.
I agree with this observation and think that this is a real problem. But the answer to this problem would logically be that we need to increase our efforts to change that by reducing the number of GMail accounts and increasing the number of self-hosted email servers, right? This is not really an argument for centralization, where each and every message is guaranteed to have the same service at the other end.
I also agree with his opinion that a more effective tool to gain privacy is good encryption. He obviously brings the point that email encryption is unusable, (hinting to PGP probably), totally ignoring modern approaches to email encryption like autocrypt.
Censorship resistance
Federated systems are censorship resistant. At least that is the expectation that advocates of federated systems have. Every time a server gets blocked, the user just simply switches to another server. The issue that Marlinspike points out is, that every time this happens, the user loses his entire social graph. While this is an issue, there are solutions to this problem, one being nomadic identities. If some server goes down the user simply migrates to another server, taking his contacts with him. Hubzilla does this for example. There are also import/export features present in most services nowadays thanks to the GDPR. XMPP offers such a solution using XEP-0277.
But lets take a look at how Signal circumvents censorship according to Marlinspike. He proudly presents Domain Fronting as the solution. With domain fronting, the client connects to some big service which is costly to block for a censor and uses that as a proxy to connect to the actual server. While this appears to be a very elegant solution, Marlinspike conceals the fact that Google and Amazon pretty quickly intervened and stopped Signal from using their domains.
With Google Cloud and AWS out of the picture, it seems that domain fronting as a censorship circumvention technique is now largely non-viable in the countries where Signal had enabled this feature.
https://signal.org/blog/looking-back-on-the-front/
Notice that above quote was posted by Marlinspike himself more than one and a half years ago. Why exactly he brings this as an argument remains a mystery to me.
Update: Apparently Signal still successfully uses Domain Fronting, just with content delivery networks other than Google and Amazon.
And even if domain fronting was an effective way to circumvent censorship, it could also be applied to federated servers as well, adding an additional layer of protection instead of solely relying on it.
But what if the censor is not a foreign nation, but instead the nation where your servers are located? What if the US decides to shutdown signal.org for some reason? No amount of domain fronting can protect you from police raiding your server center. Police confiscating each and every server of a federated system (or even a considerable fraction of it) on the other hand is unlikely.
Availability
This brings us nicely to the next point on the agenda, availability.
If you have a centralized service than you want to move that centralized service into two different data centers. And the way you did that was by splitting the data up between those data centers and you just halved your availability, because the mean time between failures goes up since you have two different data centers which means that it is more likely to have an outage in one of those data centers in any given moment.
Moxie Marlinspike in his 36c3 talk “The Ecosystem is Moving”
For some reason Marlinspike confuses a decentralized system with a centralized, but distributed system. It even reads “Centralized Service” on his slides… Decentralization does not equal distribution.
A federated system would obviously not be fault free, as servers naturally tend to go down, but an outage only causes a small fraction of the network to collapse, contrary to a total outage of centralized systems. There even are techniques to minimize the loss of functionality further, for example distributed chat rooms in the matrix protocol.
Control
The advocates argument of control says that if a service provider behaves undesirably, you simply switch to another service provider. Marlinspike rightfully asks the question how it then can be that many people still use Yahoo as their mail provider. Indeed that is a good question. I guess the only answer I can come up with is that most people probably don’t care enough about their email to make the switch. To be honest, email is kind of boring anyways 😉
XMPP
Next Marlinspike talks about XMPP. He (rightfully) notes that due to XMPPs extensibility there is a morass of XEPs and that those don’t really feel consistent.
The XMPP community already recognized the problem that comes with having that many XEPs and tries to solve this issue by introducing so called compliance suites. These are annually published documents that contain a list of XEPs that are considered vitally important for clients or servers. These suites act as maps that point a way through the XEP jungle.
Next Marlinspike states that the XMPP protocol still fails to be a suitable option for mobile devices. This statement is plain wrong and was already debunked in a blog post by Daniel Gultsch back in 2016. Gultsch develops an XMPP client for Android which is totally usable and generally has lower battery consumption than Signal has. Conversations implements all of the XEPs listed in the compliance suites to be required for mobile clients. This shows that implementing a decent mobile client for a federated system can be done and there is a recipe for it.
What Marlinspike could have pointed out instead is that the XMPP community struggles to come up with a decent iOS client. That would have been a fair argument, but spreading FUD about the XMPP protocol as a whole is unfair and dishonest.
Luckily the audience of the talk didn’t fully buy into Marlinspikes weaker arguments as demonstrated by some entertaining questions during the QA afterwards.
What Marlinspike is right about though is that developing a federated system is harder than doing a centralized service. You as the developer have control over the whole system and subsequently over the users. However this is actually the reason why we, the community of decentralized systems and federated protocols do what we do. In the words of J.F. Kennedy, we do these things…
…not because they are easy, but because they are hard…
… or simply because they are right.
12 responses to “Re: The Ecosystem is Moving”
@vanitasvitae longpost is long
@vanitasvitae Ich teile die Argumentation von Marlinspike auch nicht, allerdings verkauft sich das #fediverse auch deutlich unter Wert. Ich teste seit ein paar Tagen #Mastodon und bin bisher nur mäßig zufrieden.
Kannst du das konkretisieren?
Womit genau bist du denn nicht zu Frieden und in welche Richtung evaluiert du?
Siehe z.B. hier:
https://social.lsnet.eu/@ls/103390347989631550
https://social.lsnet.eu/@ls/103395695327507652
@vanitasvitae I wonder why it should be important that this stupid guy shitposted against the fediverse.He's the second Zuckerberg who created a second Whatsapp.Period.He didn't do any better,he's just a Facebook competitor who is afraid of the success of decentralized networks because he knows that they're better.If Zuckerberg said Mastodon is shit,nobody would have cared.The same should be true for Marlinspike.I'd rather install Whatsapp once again before I get Signal btw.Fuck off.
Very good article, thanks!
There are some minor points to add:
1. [Privacy] Many organizations (companys, administrations, etc.) still have their own email servers. I.e. this area is not yet centralized completely.
2. [Censorship resistance] Many users, incl. non-geeks, have multiple email/XMPP/etc. accounts. I.e. even without nomadic identiites a service outage can be survived.
There is a lot to digest there. I agree that he set up some straw men and you’ve rightfully called them out. At the same time the problems he’s brought up I’m not sure are solved by the methodology you’ve laid out. For example, look at availability and scalability. As you point out federation does prevent a system wide outage but because these are user-focused networks the real problem is what is the availability to a particular user. If their server is down, or overloaded, they effectively have no access to the system at large. Worse, if their server goes offline for good all of their data goes offline with it. That is partially dealt with with nomadic identities, but that assumes that there is sufficient warning to perform the operation *and* that the user was logging into the system during that period.
Federation really doesn’t deal with the privacy issue much at all. Server admins have carte blanche to read all of the data on the system, public and private, for most of the fediverse implementations. Without the information being encrypted at rest anyone with access to the system has access to all data on the system. For the sake of discussion we can assume good intention on the part of the operator/admin and that they won’t read information they shouldn’t, however a related problem is security. Even with armies of people trying to keep the commercial centralized system secure there are still data breaches. In the case of fediverse hosted instances we don’t have those resources and therefore we have to hope that an individual host has successfully secured their system, doesn’t fall for a spear phishing email, etc. It’s a big if. Thankfully the damage would be limited to data on that particular instance however again, from the individual user’s point of view that is all of their private data. You at least don’t have to worry about malicious privacy violation practices on the part of the developers, but the rest are pretty much the same.
With respect to control, people say they want it but they want it transparently and seamlessly. Why do people still have Yahoo accounts, or AOL accounts in active use. It’s because it still works and the cost of migrating in terms of updating contacts, pulling all your information down, etc., is greater than zero. Human nature is pretty consistent on this behavior of sticking with the devil you know than the devil you don’t. Human nature is also pretty consistent on default behaviors will get chosen far more often than not. It’s one of the reasons why number of organ donors in Austria (+90%) is far higher than Germany (~15%) last decade. Making it so using the fediverse and having control of your data is the default behavior is how we will get more adoption and usage. The how of that is of course a very difficult problem.
[…] The Ecosystem is Moving […]
“I agree with this observation and think that this is a real problem. But the answer to this problem would logically be that we need to increase our efforts to change that by reducing the number of GMail accounts and increasing the number of self-hosted email servers, right? This is not really an argument for centralization, where each and every message is guaranteed to have the same service at the other end.”
If you think about it, it really is an argument towards centralization. Imagine Facebook releasing a privacy invading Matrix client that lures in billions of users just because it comes preinstalled on every Samsung phone or whatnot — no way to talk to almost anyone without them invading your privacy. Sure, you can choose not to use their client, but majority of your peers are the equivalent of second hand smokers blowing smoke at your face; “what’s the big deal, it’s only metadata. I have nothing to hide”. Compare that to centralized ecosystem built to protect your privacy from the ground up, there’s no bad Signal client out there. FB needs to have different ecosystem and they have: WhatsApp.
“totally ignoring modern approaches to email encryption like autocrypt.”
The only client supported are Thunderbird and K-9 Mail. How is this a solution? It’s XKCD #927 all over again.
“there are solutions to this problem, one being nomadic identities.”
Great, so the solution is… a centralized service managing your decentralized identities.
“There are also import/export features present in most services nowadays”
Good luck using those when the service is being censored.
“And even if domain fronting was an effective way to circumvent censorship, it could also be applied to federated servers as well, adding an additional layer of protection instead of solely relying on it.”
If Domain Fronting works, it’s enough. If it doesn’t, you’re out of luck because the international community isn’t going to care about oppressive nations blocking all Matrix servers.
“What if the US decides to shutdown signal.org for some reason?”
FUD. There’s nothing that implicates such incident would ever take place. Plus even IF that would happen, Signal could easily move to e.g. Switzerland or Nordic countries that still respect human rights. And there’s the fact the US senate staff is using Signal: https://www.schneier.com/blog/archives/2017/05/the_us_senate_i.html
“Police confiscating each and every server of a federated system (or even a considerable fraction of it) on the other hand is unlikely.”
That’s not necessary when you can block the protocol, public servers or whatnot.
“contrary to a total outage of centralized systems.”
Yeah, because AWS hasn’t figured out how to ensure uptime in case some individual server / data center goes down.
“The XMPP community already recognized the problem that comes with having that many XEPs and tries to solve this issue by introducing so called compliance suites. ”
So when a new feature is proposed, it takes one year to create a non-binding advisories to client vendors, who may or may not implement them. Doesn’t sound too agile. What if it’s a more secure protocol? What do you do if the client refuses to implement it? All clients need to maintain backwards compatibility or boot out the users using the client. If they maintain compatibility, you get protocol downgrade attacks. Security agility matters more than anything here, and it’s THE thing where decentralization sucks. If you want a good example, take a look at how OpenPGP workgroup still hasn’t agreed on a 256-bit hash function after SHAppening, FIVE years ago. Such things are a non-issue for centralized protocols. Considering Matrix clients’ E2EE-by-default is still non-existent, I’d say they’re on the same boat with PGP and its bike shedding.
“preading FUD about the XMPP protocol as a whole is unfair and dishonest.”
The problem is security. There is no mandated E2EE standard like OMEMO in XMPP. Matrix is another “solution” that did not think along the lines of “security first”.
“Luckily the audience of the talk didn’t fully buy into Marlinspikes weaker arguments as demonstrated by some entertaining questions during the QA afterwards.”
The question was not mocking in it’s nature, the fun part was the fact he disagreed with Moxie. Moxies reply wrt. metadata was eventual adaption of Onion Routing. It’s not a trivial issue to solve. What the writer fails to note is Matrix doesn’t solve metadata problem either. Instead, it moves metadata to Mike, the IT guy of your peers who has a crush on Karen, and who he’s stalking relentlessly: Who she talks on Matrix, when, and how much. And until Riot enables E2EE by default, it might be he’s reading her private messages too. I’ll take Moxie reading my metadata any time over such a scenario. At least I know all my messages are always E2EE.
The only solution is Tor. But v3 Onion Services aren’t even ready e.g. basic/stealth authorization doesn’t work yet. So even if you removed metadata, now you’re unable to properly block contacts from checking when you’re online.
“What Marlinspike is right about though is that developing a federated system is harder than doing a centralized service. You as the developer have control over the whole system and subsequently over the users. However this is actually the reason why we, the community of decentralized systems and federated protocols do what we do. In the words of J.F. Kennedy, we do these things “not because they are easy, but because they are hard” – or simply because they are right.”
Then they should start with security first like Signal does and only release once E2EE works. Until decentralized platforms solve metadata, I wouldn’t talk about idealistic not-so-well-thought-out ideas of decentralization to people who can do it faster. Matrix ecosystem will get there eventually, but considering they don’t offer anything meaningful to availability (as dissected by Moxie and above), their arguments fall down to the idealism regarding user freedom and FUD “what if the server is taken down or if Moxie gets bored”. Both would be problems, but neither seems to be the case. This blog post was full of “solutions have been proposed to this problem” — why wouldn’t the same apply to Signal’s problems?
I fail to see any meaningful, real benefits from decentralized platforms. To really solve metadata problem and censorship resistance, you need apps like Ricochet, Briar, or Cwtch, that are peer-to-peer and where you can’t screw up your anonymity and OPSEC accidentally.
“e.g. basic/stealth authorization doesn’t work yet”
Except I’m using it on several hidden services.
We have to distinguish between federated and peer 2 peer systems. Federated systems share a lot of problems of centralized approaches, because most people need a third party to handle their data. I don’t have my own Mastodon instance running, or my own Diaspora instance, so I rely on others (I do host my own e-mail like Moxie, but like him, most other people don’t, and if I send something to Gmail, I can just as well use my Gmail account, and be sure it won’t be stuck in some weird anti-spam measurement). Setting up your own server is not for the normal user.
So if you think about a user-centric product perspective, only peer2peer can bring a solution. The data is yours, and the protocol takes care about that you actually can set up your own instance without jumping through hoops.
The question whether you are going to stuck with a protocol or if development can move forward fast is that of how you organize your development: have many competing systems using the same protocol (frozen in time as a result), or have one system that is developed together by the community? If you think about everybody is stuck with HTTP/1.1, because writing a web server as abandonware is easy, we are not stuck with HTML, because writing a browser as abandonware is harder. People abandon their own approaches, and go forward to Chromium-based, with Firefox as active competitor. The situation is much better on that side.
“Yeah, because AWS hasn’t figured out how to ensure uptime in case some individual server / data center goes down.”
As a matter of fact, whenever there’s a power outage in the US state of Virginia, a large portion of sites hosted on Amazon’s cloud go down. US-East is their largest region, and the place where most sites are hosted.
“If Domain Fronting works, it’s enough. If it doesn’t, you’re out of luck because the international community isn’t going to care about oppressive nations blocking all Matrix servers.”
I don’t know how many Matrix homeservers there are, but I’m pretty sure they’re just HTTP, meaning that oppressive nations aren’t likely to try to block _all_ Matrix servers unless they’re shutting down their nation’s Internet connections anyway. Even if they weren’t using HTTP, a nation wouldn’t likely bother to block thousands of individually-hosted servers unless they were going to completely shut down the Internet.
On the other hand, if domain fronting is all that Signal’s got, all it takes is a big enough player deciding to block those fronting hosts, and they’ll cave.