The case against Signal
With WhatsApp changing its privacy policy, Signal has been getting a lot of attention over the past few days. While a lot of praise has been given to the project, a lot of critiques emerged as well. I wanted to review some of the arguments that were mentioned and explain why, to me, these arguments were not enough to discard Signal as an option. First, let’s have a look at the mission of the Signal Foundation:
To develop open source privacy technology that protects free expression and enables secure global communication.
It’s not true opensource #
This point generally relates to the fact that Signal doesn’t allow alternative clients to connect to their service. There have been multiple issues in the past with people trying to fork Signal. One of the most famous is LibreSignal. This project aimed at providing a Google-free Signal client though a comment from Moxie (Signal’s founder) stated that the project was not authorized to either use the name “Signal” or connect to the Signal service as provided by OpenWhisperSystems (now Signal).
The name is an issue that already arose with Mozilla protecting their names back in the 2000s. As stated by Mitchell Baker, Mozilla’s Chair Person, in 2007, the aim was to ensure that users were getting a consistent experience when using Firefox. This led some distributions like Debian to not being able to distribute Firefox because it didn’t match Debian’s guidelines, hence the name Iceweasel. The same applies to Signal.
Another problem mentioned by users is that Signal is not present on F-Droid. The reasons why were explained by moxie in this comment. While he doesn’t explain the reasons for his team to feel F-Droid as an insecure option, he gives a list of requirements for a system that would complement Google Play. These requirements describe features that Google Play offers. These features, which F-Droid currently lacks, are giving Signal more control and insights into their deployments. While Signal doesn’t allow distribution outside of Google Play, it provides a link to an APK for users to download. The door to a Google Play alternative is thus not closed.
There is a distinction to be made between the software and the service. The software is opensource though the service doesn’t allow forks to connect. The reasons for this are explained in this comment. And this brings us to the next point.
It’s centralized #
Moxie gave a talk on the challenges of decentralization from the perspective of Signal. In this talk, he goes over how, from a decentralized ideal where everyone is a consumer and a producer, the internet became centralized by nature by creating an imbalance between producers of content and consumers. He also explains the fact that decentralization becomes an obstacle when one wants to release features often and compete against companies with hundred of engineers. Going back to their mission, they want to enable secure global communication. As he explains, achieving this would be much harder if they had to manage any kind of federation: upgrades to the protocol would take a long time or, in the example he takes, are at risk of never happening (take IPv6 as an example).
Let’s take Google Talk as an example, they started offering the service using standard XMPP and enabled federation. It was great though, as they were releasing Hangouts, Google lost interest in the service: XMPP started requiring federation over TLS, which Google Talk didn’t support but with Hangouts around the corner, there was no incentive for them to implement it. This in turn isolated Google Talk’s users from the network and also highlighted a security issue for them. Google stopped supporting XMPP for their clients or for federation in Hangouts. This is a good example of not being able to enforce upgrades to the protocol (in this case encryption on the server to server protocol).
The same arguments apply to forks and custom clients, it is much harder to maintain a consistent experience and release feature when you don’t control the clients to your service. Furthermore, if you allow forks whose quality of implementation you can’t control, you are at risk of weakening the security of the network.
It relies on cloud providers #
A lot of people blame Signal because they rely heavily on cloud providers, arguing they should have their own infrastructure. This would be dismissing the cost of maintaining one’s own infrastructure: Signal would have to hire many more people with a different set of skills just to maintain it. The Signal team is small and needs to focus on their mission while keeping their velocity high and add features to their service. In addition, maintaining your own infrastructure makes it a lot easier to be blocked, them being in AWS or GCP meddles them in the mass of customers the providers have.
Signal had issues with cloud providers in the past, where they would block a feature they were using to circumvent censorship in some countries. There is a risk that a cloud provider would also kick Signal’s infrastructure out, dealing a great blow to the service. There is also a risk for Signal to be shut down by the US government. However as the service grows its user base, this becomes increasingly harder to do politically.
Now keeping in mind that the service is hosted by US based companies, and is itself maintained by an US based entity, we could wonder what kind of hold the US government might have on it. The good thing with Signal is that we don’t have to trust the infrastructure to keep our communications secret, the only information AWS/GCP can get are the IP addresses of the users, there is no link between a user and its IP (see this subpeona).
Signal is doing a good job at using their host providers as mere conduit.
It uses phone numbers as identifiers #
Everyone is telling me Signal is the most secure solution there is, so why does it need my phone number?
This was explained multiple times by Signal. The idea behind using the phone number was to make sure the user’s social network (e.g. their contacts) wasn’t sent to the service and that, if the service was down, it wasn’t lost. In the video I shared at the beginning of this post, Moxie explains this at minute 38, he also covers the fact that using pseudonyms or any kind of other identifiers outside of phone numbers doesn’t mean you can’t be identified: your phone needs to connect to notifications services using unique identifiers that can be used to identify you.
Since that video, Signal has started to announce that they were working on ways to remove the phone number as the unique identifier on Signal so this concern should soon be a thing of the past.
Conclusion #
We’ve seen that Signal is in line with its mission, trying the best it can to bring privacy to the masses by reducing the friction to adoption and thus keeping a good user experience. Their technology stays open source (a note though: signal-server hasn’t been updated since April 2020) and they release new features at a crazy pace, every week bringing its lot of improvements.
Signal is not perfect and I wish it were decentralized as well though the urgency at the moment is to make sure privacy becomes a right rather than a product. Signal is paving the way for others to bring better alternatives in a context that is requiring ever increasing privacy. It is not the ultimate solution but for the short/mid-term, it’s the best out there. Even if you don’t like Signal, it is setting a very high standard for privacy. If you don’t install it for you, install it for your peers, it’s still better than to use plain SMS.
– This is day 16/100 of #100DaysToOffLoad!