StormFree Cloud Corporation is a company focused on developing technology that provides users with flexibility, freedom, and security. This is why we are interested in the debate between centralized vs. decentralized systems, and - picking up from our previous blog post on the subject - provide our analysis on the perspectives given by Moxie Marlinspike of Signal Technologies in his presentation at the 36C3 conference in December 2019, along with the response given by Matthew Hodgson of New Vector.
The strength of Marlinspike's arguments, which we laid out in our last post, suffer due to a variety of factors. Chief among these is his tendency to downplay issues related to Signal and other centralized applications while exaggerating similar issues as they relate to decentralized systems.
One such example was when Marlinspike claimed that switching servers in a decentralized environment to circumvent censorship necessitates destroying a user's social graph, and that switching from Telegram to Signal to WhatsApp is easy because that social graph is preserved. This claim ignores the continuing work on nomadic accounts within Matrix, and does not acknowledge that there are other methods of preserving or transferring address books between servers. Further, Marlinspike's statements do not address the very real difficulty of switching from one communication application to another. While Signal does preserve a user's social graph because it relies on telephone numbers to identify contacts, switching from Signal to Telegram would still involve convincing all of your contacts to do the same. Acknowledging this significant barrier to switching communication applications would inadvertently demonstrate one of the reasons that a federated protocol like Matrix is needed, so it is no surprise that Marlinspike omitted addressing this in his presentation and his blog post.
This minimization of Signal's own drawbacks occurred again when Marlinspike explained why his messaging application does not offer peer-to-peer (P2P) functionality. According to Marlinspike, users were dissatisfied when they attempted to introduce P2P VoIP functionality because this had the potential of revealing a user's IP address and identifying information about their device to the person on the other end of the call. Signal therefore opted to use a server-based VoIP solution, which means that these identifiers are instead located on the server that facilitates the call. This discussion was intended by Marlinspike to dismiss pushes for P2P functionality, and it ignores user concerns over providing so much identifying information - including telephone numbers - to Signal's servers. Just as Hodgson pointed out, users must trust that Signal will respect their privacy and hide these identifiers on their servers now and in the future. In a decentralized system, users can run their own servers if they do not trust other implementations, allowing them to control their data and metadata retention policies.
Another apparent oversight emerged in Marlinspike's claims about Signal's supposed censorship-avoidance capabilities. While Marlinspike's argument that multiple ingress points and domain fronting can be useful to avoid censors has some merit, a centralized service nevertheless remains vulnerable to being censored by its host nation. Currently, state-sponsored censorship efforts have only been directed at Signal from nations such as Egypt and the United Arab Emirates, locations which do not house any of the servers that Signal relies on. In these scenarios, the aforementioned measures have been effective at circumventing censorship. However, what would happen if the United States government wanted to censor Signal? The messaging application uses Amazon Web Services (AWS) to host their servers, and it is likely that these servers are mostly located in data centres in the United States. This means that the U.S. government could effectively censor Signal by raiding the AWS data centres that the service uses. This reality exposes one of the major vulnerabilities of a centralized service, which is that there is often a small number of data centres or servers which are responsible for supporting the entire system, making it relatively easy to bring down the entire service.
Decentralized systems like Matrix, on the other hand, are much more difficult to take down because the service is dispersed across a large number of servers in a variety of locations around the world. The Matrix Voyager bot, which travels the ecosystem and records the number of servers and rooms it finds, has discovered over 7,300 servers as of January 2020. The sheer number of active servers means that it is nearly impossible for a censor to find and take down all of them, making a decentralized system like Matrix extremely censorship-resistant. These factors were not addressed by Marlinspike in his presentation, who only contended that the potential loss of a user's social graph renders decentralized systems non-censor-resistant, a claim that is false.
Possibly one of the most bizarre claims from Marlinspike was the idea that splitting a centralized service like Signal between multiple data centres would increase the chances of a service outage. No evidence was offered to support this argument, but it appears to be based on the idea that a larger pool of data centres has a higher chance of experiencing technical issues because there are more pieces of hardware and processes that could malfunction. While this might be true from a strictly statistical basis, the argument does not make sense when considered in the real world. If Signal were to split its services between multiple data centres, perhaps one for their North American users located in Wyoming and another in Germany to serve their EU customers, an outage in one of these areas would not bring down the entire service. Instead, an outage would have a regional effect, bringing the service down for only a portion of the global user base. In this hypothetical split, the data centre in Wyoming going offline would render the service unreachable for North American users, but EU users would still be able to use the service. In a completely centralized deployment that utilizes a single data centre, that data centre going offline would render the service unreachable for all users around the world, highlighting one of the weaknesses of a centralized deployment.
Along with the unfounded claim that decentralizing a service decreases reliability, Marlinspike also asserted that splitting Signal between two data centres would halve the service's availability. This claim is also confusing, and seems to be based more in a theoretical appreciation of decentralization rather than how it plays out in the real world. It is true that a user connecting to a single one of those two servers would only be accessing half of the data that had once been made available on a single server, assuming these servers are isolated. This analysis seems to lose sight of how federated, decentralized systems are intended to operate in the real world, where users access a network via one server, and in doing so are able to interact with users on other servers. In the Matrix ecosystem, for example, homeservers only connect to each other when users on those servers are talking to each other - the fact that a user only connects with a single server is irrelevant, and does not impede their use of the ecosystem. Other types of servers can also be federated in this way, allowing servers to share data and ensuring that a single server outage does not render the entire distributed network unreachable. Federated, decentralized networks of this type are a known solution to the problem that Marlinspike seems to be implying here, and the fact that he does not acknowledge this solution is further evidence of his questionable approach.
Marlinspike also took direct aim at XMPP, which is a decentralized messaging protocol that has been in use since 1999. Marlinspike complained that the XMPP ecosystem has become fragmented with too many extensions (called XEPs in XMPP parlance) causing variations in the capabilities of different client configurations. A blog post written by a member of the XMPP community responded to this, saying that XMPP has recognized this issue and introduced compliance suites to address it. These compliance suites are published annually, and contain a list of XEPs that are considered vitally important for clients or servers to run in order to be compatible with the majority of the community. While Marlinspike's criticisms do serve to highlight the real difficulty of ensuring voluntary compliance across a federated network, he left out the important steps that have been taken to encourage users to maintain some uniformity within XMPP.
Further evidence that Marlinspike may have been arguing in bad faith can be found in his next statement about XMPP, which was that "none of the extensibility that is built into [XMPP] could actually adapt to [...] mobile environments." This assertion was already addressed in a post from Daniel Gultsch, which was responding to Moxie's original 2016 blog post. Posted in November of the same year, Gultsch's response pointed to Conversations, an XMPP mobile client for Android, as evidence that XMPP can in fact be adapted to a mobile environment. He also made the astute observation that the major difference between "failed" or "static" federated technologies and successful ones is that the latter tend to have proper funding behind them. To further illustrate this point, Gultsch pointed to the World Wide Web - itself a federated, decentralized system - and noted that the web owes much of its success to the fact that there are many companies and individuals being paid to develop on it. Federated technologies like XMPP, on the other hand, are often developed and maintained by individuals in their spare time, so it is no surprise that these tend to often lag behind competing technologies that have financial backing driving their development.
The fact that this insightful response was posted three years prior to Marlinspike's recent appearance at 36C3 makes it unlikely that the Signal founder is unaware of it. Therefore, Marlinspike is likely one of two things: either he is unaware of the responses to his own viewpoint and the ongoing debate it has intermittently caused, or he is willfully choosing to ignore the valid counterpoints to his assertions.
When assessing the whole of Marlinspike's arguments alongside the current state of the technologies he holds up as examples to bolster his point, it seems clear that he is trying to discourage people from moving away from his communication silo. Marlinspike is certainly aware of the criticisms of Signal's retention of metadata and the use of telephone numbers as identifiers (both topics were, in fact, raised during the question period after his presentation). As a result, it would be in his benefit to convince potential users that federated ecosystems are stagnant, unimaginative, and slow-moving, and that only his proprietary system can truly offer the security and functionality that users want. Such an extreme position regarding federated systems and their relationship with centralized ones is patently false, and over-exaggerates the real issues that do cause the former to be slower and more difficult to develop than the latter.
In the end, Hodgson's position is correct in that federated systems offer something that centralized ones cannot: true user freedom. While that freedom does come at the cost of user effort and a more difficult environment to develop in, it is possible to design a system that makes that freedom relatively accessible. Matrix is a prime example of this in action: the ability to run one's own homeserver is becoming more and more accessible, with the New Vector developers actively working towards making Synapse easier to install and run for regular users, and the development of client-side homeservers / P2P Matrix is also moving along. Even now, users can choose from a variety of public homeservers when registering an account, and are free to use one of the many forks of Synapse if they are dissatisfied with the default implementation published by New Vector. Matrix also allows users to choose between a variety of compatible chat clients, and even proprietary, closed systems like Slack and Telegram can be bridged into Matrix so that users can connect with their preferred clients.
Federated systems align more closely with StormFree's values. Unlike proprietary communication silos which have access to user metadata and force users to trust a single, centralized entity, federated systems return control to the user. Individuals in a system like Matrix can engage in the ecosystem while maintaining complete knowledge and control over where their data and metadata is and who can access it. With end-to-end encryption enabled in Matrix (which is fast becoming an enabled-by-default feature), even a malicious server administrator cannot access a user's data since the private encryption keys never leave the device, which means that attackers breaching a user's personal server are also shut out of accessing any of the message data that a server houses.
In a walled garden like Signal, users simply have to accept the design that Marlinspike and his associates have chosen, and have no control over how the system handles their data and metadata. Users in Signal also cannot exercise any control over how the system will develop in the future, and must accept any software updates that Marlinspike releases. While there is no present indication of Signal compromising user data or metadata, this could change at any moment without users knowing it.
Federation is a difficult task that is worth the effort, and it is in the best interest of the user for individuals and organizations to continue to take up this challenge of decentralization in the pursuit of true user freedom.
