description: Signal is often considered an alternative to Whatsapp, but is it really? Why you should gather a group of friends and consider staring into the abyss of self-hosted, federated messaging services.
description: Signal is often considered an alternative to Whatsapp, but is it really? Why you should gather a group of friends and consider staring into the abyss of self-hosted, federated messaging services.
*This article was first first published on <https://homebrewserver.club> on the 9th of march of 2017*
<hr>
>"Remember, when advertising is involved you the user are the product. [...]
>"Remember, when advertising is involved you the user are the product. [...]
>When people ask us why we charge for WhatsApp, we say 'Have you considered the alternative?'"
>When people ask us why we charge for WhatsApp, we say 'Have you considered the alternative?'"
@ -42,23 +46,23 @@ Cryptography matters, but then it also doesn’t
The latest competitive feature—one might even say, marketing trick—to make concerned users switch from one alternative to another is cryptography, the act of coding messages during communication. This strategy works well because the vast majority of people are not really informed when it comes down to the technicalities of cryptography, so this discourse mostly serves to throw bedazzling sparkles in our eyes. To be sure, cryptography is fundamental for privacy. However, the main privacy threat in the context of using these apps isn't the potential of a government eavesdropping on our communications. The privacy threat is the wholesale and increasing dependence on centralized services which revolve around the surveillance and monetization of user information. In 2016, both WhatsApp and Facebook Messenger enabled end-to-end encryption[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#e2e) to address increasing privacy concerns. Adding *crypto* to a communication app in this case merely obfuscates a concern about the hegemony of these platforms. In essence, the issue of privacy is much larger than just the lack of cryptography; the conditions that threaten privacy are structural and economic and not resolved by a *patch* or a new feature.
The latest competitive feature—one might even say, marketing trick—to make concerned users switch from one alternative to another is cryptography, the act of coding messages during communication. This strategy works well because the vast majority of people are not really informed when it comes down to the technicalities of cryptography, so this discourse mostly serves to throw bedazzling sparkles in our eyes. To be sure, cryptography is fundamental for privacy. However, the main privacy threat in the context of using these apps isn't the potential of a government eavesdropping on our communications. The privacy threat is the wholesale and increasing dependence on centralized services which revolve around the surveillance and monetization of user information. In 2016, both WhatsApp and Facebook Messenger enabled end-to-end encryption[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#e2e) to address increasing privacy concerns. Adding *crypto* to a communication app in this case merely obfuscates a concern about the hegemony of these platforms. In essence, the issue of privacy is much larger than just the lack of cryptography; the conditions that threaten privacy are structural and economic and not resolved by a *patch* or a new feature.
This issue is further stressed when looking at the question of metadata, that is to say, data about data, which in the case of communication applications is everything but the communication data itself. When WhatsApp started sharing, among other things, its users' phone numbers with its parent company, Facebook, it went to great lengths to guarantee us that the content of our messages was still perfectly secure, impossible to be read by both WhatsApp and Facebook. The argument stating that "It's only metadata, don't worry" has been however debunked numerous times. Even though these platforms would love us to believe otherwise, metadata is neither a trivial disposable by-product, nor it is anonymous. And assuming that the crypto is sound and that the app running this crypto is not flawed, cross-referencing several databases containing metadata will always produce an array of very personal information, that in itself is much more valuable than encrypted naked selfies. Thus it should be no surprise that former NSA director Michael Hayden infamously said in 2012 "we kill based on metadata"[ref][https://www.youtube.com/watch?v=UdQiz0Vavmc](https://www.youtube.com/watch?v=UdQiz0Vavmc)[/ref] and later argued in 2015 that metadata should be the main area of focus of surveillance activities, and not the creation of backdoors within crypto, or the banning of the latter[ref][https://www.c-span.org/video/?402284-1/discussion-immigration-policy-national-security](https://www.c-span.org/video/?402284-1/discussion-immigration-policy-national-security)[/ref].
This issue is further stressed when looking at the question of metadata, that is to say, data about data, which in the case of communication applications is everything but the communication data itself. When WhatsApp started sharing, among other things, its users' phone numbers with its parent company, Facebook, it went to great lengths to guarantee us that the content of our messages was still perfectly secure, impossible to be read by both WhatsApp and Facebook. The argument stating that "It's only metadata, don't worry" has been however debunked numerous times. Even though these platforms would love us to believe otherwise, metadata is neither a trivial disposable by-product, nor it is anonymous. And assuming that the crypto is sound and that the app running this crypto is not flawed, cross-referencing several databases containing metadata will always produce an array of very personal information, that in itself is much more valuable than encrypted naked selfies. Thus it should be no surprise that former NSA director Michael Hayden infamously said in 2012 "we kill based on metadata"[^8] and later argued in 2015 that metadata should be the main area of focus of surveillance activities, and not the creation of backdoors within crypto, or the banning of the latter[^9].
In short, both Whatsapp and FacebookMessenger can afford to deploy end-to-end encryption for your messages because it won’t hurt their bottom line, which is making money based on the surveillance of your behavior and your social graph. Adding crypto thus merely patches your privacy worries, but not the threat to it.
In short, both Whatsapp and FacebookMessenger can afford to deploy end-to-end encryption for your messages because it won’t hurt their bottom line, which is making money based on the surveillance of your behavior and your social graph. Adding crypto thus merely patches your privacy worries, but not the threat to it.
The Wrong Signal[ref][https://it-kollektiv.com/wrong-signal-das-falsche-signal-engl/](https://it-kollektiv.com/wrong-signal-das-falsche-signal-engl/)[/ref]
The Wrong Signal[^10]
---
---
The end-to-end encryption enabled in WhatsApp and Facebook Messenger has been developed by Open Whisper Systems, a non-profit run by crypto-celebrity Moxie Marlinspike. OWS also developed the algorithm for their own instant messaging application, Signal, and then open-sourced it. Signal itself is now the latest app being promoted as an alternative to WhatsApp and is hailed as the panacea of both security and usability. It even has the backing of members of the dissident elite such as Edward Snowden.
The end-to-end encryption enabled in WhatsApp and Facebook Messenger has been developed by Open Whisper Systems, a non-profit run by crypto-celebrity Moxie Marlinspike. OWS also developed the algorithm for their own instant messaging application, Signal, and then open-sourced it. Signal itself is now the latest app being promoted as an alternative to WhatsApp and is hailed as the panacea of both security and usability. It even has the backing of members of the dissident elite such as Edward Snowden.
While OWS provides thorough expertise in the field of cryptography, Marlinspike is currently advocating centralisation as the only answer towards user-friendly, fast and secure messaging apps. Decentralisation, according to him, has no place in the modern world and apparently hampers innovation. However, some of his arguments have not remained unchallenged. In particular, where Marlinspike accuses federation of stalling evolution[ref][https://whispersystems.org/blog/the-ecosystem-is-moving/](https://whispersystems.org/blog/the-ecosystem-is-moving/)[/ref], Daniel Gultsch[ref][https://gultsch.de/objection.html](https://gultsch.de/objection.html)[/ref] provides a counter argument by using the Web as an example of successfully federated system[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#federated). Furthermore, Gultsch states that the problem is not that federation doesn't adapt, but rather that there are problems with its implementation for a very significant reason: software developers working on federated systems mostly work for free in their spare time or with little means, given the difficulty to monetise a system which design can only succeed if it is open and can be appropriated easily beyond its original scope, and thus making its capitalisation particularly challenging. In that sense, the most interesting aspect of this debate is that while Marlinspike seems to defend his product from a technological perspective, Gultsch's counter argument moves back the discussion to the context of political economy.
While OWS provides thorough expertise in the field of cryptography, Marlinspike is currently advocating centralisation as the only answer towards user-friendly, fast and secure messaging apps. Decentralisation, according to him, has no place in the modern world and apparently hampers innovation. However, some of his arguments have not remained unchallenged. In particular, where Marlinspike accuses federation of stalling evolution[^11], Daniel Gultsch[^12] provides a counter argument by using the Web as an example of successfully federated system[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#federated). Furthermore, Gultsch states that the problem is not that federation doesn't adapt, but rather that there are problems with its implementation for a very significant reason: software developers working on federated systems mostly work for free in their spare time or with little means, given the difficulty to monetise a system which design can only succeed if it is open and can be appropriated easily beyond its original scope, and thus making its capitalisation particularly challenging. In that sense, the most interesting aspect of this debate is that while Marlinspike seems to defend his product from a technological perspective, Gultsch's counter argument moves back the discussion to the context of political economy.
Daniel Gultsch is an important counter-voice because he is the main developer behind Conversations[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#conversations). This open-source instant messaging app tries to be both accessible for new users as well as provide enough flexibility for more advanced users. In that regard, Conversations itself does not manage to escape the logic of competition and the discourse around *alternative* superior apps discussed previously. However, its approach is significantly different because unlike any other apps, Conversations is not a complete solution, nor does it present itself as such. It is a client that relies on federation, which means that it allows for people to chat with each other regardless of what provider they are using. In concrete terms, there is no central server directly connected to Conversations, but Conversations can connect to different chat servers. This is possible because Conversations is built upon a long-lived messaging protocol called XMPP[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#xmpp).
Daniel Gultsch is an important counter-voice because he is the main developer behind Conversations[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#conversations). This open-source instant messaging app tries to be both accessible for new users as well as provide enough flexibility for more advanced users. In that regard, Conversations itself does not manage to escape the logic of competition and the discourse around *alternative* superior apps discussed previously. However, its approach is significantly different because unlike any other apps, Conversations is not a complete solution, nor does it present itself as such. It is a client that relies on federation, which means that it allows for people to chat with each other regardless of what provider they are using. In concrete terms, there is no central server directly connected to Conversations, but Conversations can connect to different chat servers. This is possible because Conversations is built upon a long-lived messaging protocol called XMPP[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#xmpp).
XMPP, the federated messaging protocol
XMPP, the federated messaging protocol
---
---
Up to a few years ago XMPP and its implementations were lagging behind in terms of mobile features, usability and interface design[ref][https://op-co.de/blog/posts/mobile_xmpp_in_2014/](https://whispersystems.org/blog/the-ecosystem-is-moving/)[/ref]. That was the so-called lack of evolution Moxie pointed out. But recently Gultsch and the other contributors to Conversations have managed to bring XMPP up to speed with the functionality of well known mobile messenger applications. Not only did this demonstrate that bridging the gap could be done technically, but it also had the effect of breathing new life into the XMPP community. An example of this new energy was the initiative to create and implement OMEMO[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#omemo), an XMPP Extension Protocol[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#xep) that provides multi-user end-to-end encryption and which is based on Signal's own encryption algorithm. Ever since a growing number of clients have started implementing OMEMO, including Gajim[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#gajim) for desktops and ChatSecure[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#chatsecure) for iPhones[ref][https://omemo.top/](https://omemo.top/)[/ref].
Up to a few years ago XMPP and its implementations were lagging behind in terms of mobile features, usability and interface design[^13]. That was the so-called lack of evolution Moxie pointed out. But recently Gultsch and the other contributors to Conversations have managed to bring XMPP up to speed with the functionality of well known mobile messenger applications. Not only did this demonstrate that bridging the gap could be done technically, but it also had the effect of breathing new life into the XMPP community. An example of this new energy was the initiative to create and implement OMEMO[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#omemo), an XMPP Extension Protocol[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#xep) that provides multi-user end-to-end encryption and which is based on Signal's own encryption algorithm. Ever since a growing number of clients have started implementing OMEMO, including Gajim[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#gajim) for desktops and ChatSecure[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#chatsecure) for iPhones[^14].
Gultsch succeeded[ref]His XMPP client Conversations has been installed between [10 and 50 thousand times](https://play.google.com/store/apps/details?id=eu.siacs.conversations&hl=en) and he is able to live off and work full-time on the project[/ref] so far precisely because of understanding the technical underpinnings of centralized services[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#centralized) such as WhatsApp or Signal. It is however a bitter-sweet victory, because as Gultsch articulated in his defense of decentralisation, the main difference between centralised and decentralised implementations is not only technical, but also a matter of economic sustainability. In other words, if his ongoing efforts show that it is possible to have a satisfying and safe user experience *while* using federated alternatives, this is only possible because, unlike any other XMPP client developers, he is in the position of working on this project full time. The problem has not been solved but shifted.
Gultsch succeeded[ref]His XMPP client Conversations has been installed between [10 and 50 thousand times](https://play.google.com/store/apps/details?id=eu.siacs.conversations&hl=en) and he is able to live off and work full-time on the project[/ref] so far precisely because of understanding the technical underpinnings of centralized services[<sup>?</sup>](http://homebrewserver.club/beginners-guide-to-xmpp-speak.html#centralized) such as WhatsApp or Signal. It is however a bitter-sweet victory, because as Gultsch articulated in his defense of decentralisation, the main difference between centralised and decentralised implementations is not only technical, but also a matter of economic sustainability. In other words, if his ongoing efforts show that it is possible to have a satisfying and safe user experience *while* using federated alternatives, this is only possible because, unlike any other XMPP client developers, he is in the position of working on this project full time. The problem has not been solved but shifted.
If economically sustainable XMPP federation were to scale to the point of being as successful as the centralised solution offered by Signal, it would have to face the consequences of doing so in the context of a free market driven by competition. In that situation, each XMMP client's economic viability would depend heavily on its capacity to capture enough users that can provide income for their developers. The problem therefore is not so much a problem of the technical or economical sustainability of federation, but more a problem of the economic sustainability of open standards and protocols in a world saturated with solutionist business models. After all, many years ago, Google and Facebook did provide XMPP support in their chat applications before deciding to close its interoperability.
If economically sustainable XMPP federation were to scale to the point of being as successful as the centralised solution offered by Signal, it would have to face the consequences of doing so in the context of a free market driven by competition. In that situation, each XMMP client's economic viability would depend heavily on its capacity to capture enough users that can provide income for their developers. The problem therefore is not so much a problem of the technical or economical sustainability of federation, but more a problem of the economic sustainability of open standards and protocols in a world saturated with solutionist business models. After all, many years ago, Google and Facebook did provide XMPP support in their chat applications before deciding to close its interoperability.
@ -90,3 +94,10 @@ So while we are unable to recommend you the next big app that will solve all use
rra
7 years ago