The post, titled “Why I won’t recommend Signal anymore,” piqued my interest as I spend a lot of time evangelizing Signal to virtually anyone I interact with, for reasons which I have spent several years discovering. I immediately thought, “What did this guy discover that I’ve so blatantly missed?” and read through the article.

Unfortunately, there were no real revelations as the points the author raises have been well discussed publicly by Open Whisper Systems (OWS) and Moxie Marlinspike (Moxie) and seem to omit quite a bit of perspective in Moxie’s and OWS’ stances on the issues and also the threat model Signal is assuming with their users.

I’m going to provide some brief background on Signal, Open Whisper Systems and Moxie Marlinspike, then head straight into my response, point-by-point, offering additional context on each issue raised by the previously mentioned author and my thoughts and findings when researching these issues.

Background

Signal is an encrypted messaging and voice calling app, a combination of what was originally two mobile apps, RedPhone (the voice calling part) and TextSecure (the instant messaging part), created by Open Whisper Systems, a nonprofit software group founded by Moxie Marlinspike in 2013.

Moxie also created (along with Trevor Perrin) the Signal Protocol, currently developed by Moxie and OWS, which is a cryptographic protocol providing end-to-end encryption for instant message conversations, originally based on the Off-the-Record Messaging (OTR) protocol and which is implemented in TextSecure, WhatsApp, Facebook Messenger, and Google Allo to provide encrypted messaging to their users.

Redphone is the encrypted voice calling part of Signal and was a standalone product until Moxie and OWS combined both TextSecure and Redphone into a single, unified app called Signal, which runs on iOS, Android, and as a desktop app via Google Chrome.

Server Federation

Before we address server federation, you need to know that while Signal is free and open source software, it doesn’t just magically work all on its own. OWS must run servers which handle things like call and message routing, public key exchange between devices, and contact discovery. Signal user A can’t securely communicate with Signal user B without some server acting as an intermediary for the aforemented technical needs.

Despite the intermediate server being part of this equation, our communications are still secure. Recall that Signal implements the end-to-end encryption Signal Protocol. Signal user A and B have a private key stored only on their individual devices and they both have an associated public key which can be shared with another person without compromising their private key.

In order to securely communicate encrypted messages, the public keys need to be shared between user A and B, which is where the intermediate server comes in. The client never uploads your private key to the server, so neither the server or its operator can read the encrypted messages you send after the key exchange.

Since the Signal client source code is published openly, we can confirm the client generates and protects the private key in a manner which we expect and is only sharing the public key with the server.

So what does this all have to do with federation? Stick with me–we’re nearly there.

LibreSignal

Imagine you’re a programmer and wanted to make major changes to core parts of Signal and redistribute this heavily modified version to some of your friends. Maybe you and your friends really don’t trust Google and you want to remove the Signal dependency on Google Cloud Messaging (GCM, more on this later) by implementing your own, non-Google-reliant method, albeit at a higher cost to battery life and performance, that you deem worth it to get GCM out of the picture. That could be a valid concern and a reasonable trade-off.

There is also a possibility you want to try and support other operating systems besides the original iOS and Android targets that OWS is catering to with Signal. Removing Google dependencies might be beneficial for someone wanting to run a Signal-based variant on CopperheadOS or SailfishOS for instance, although that isn’t the userbase that OWS is supporting with Signal (nor are they likely a large share of the Signal donor base or code contributors).

So you make the changes, you remove the GCM dependency, you change the name in the code from Signal to LibreSignal and you build your LibreSignal app and upload it to your GitHub account, so your friends can easily download a copy for their phone. Now we run into the first problem: the requirement of an intermediate server we mentioned earlier.

Since you modified the original Signal code so much when making LibreSignal, you now realize your app doesn’t communicate with the official OWS Signal servers. Perhaps if the servers were modified, they could be made to work with your changes, but the point is it would require modifications which have an impact on developer time, maintenance costs, and take away from higher priority issues being addressed in a timely manner, the costs of which are disproportionately borne by OWS.

That’s obviously a problem.

It’s Free Software, Not Entitled Software

Since the software is open source, you were free to modify and redistribute it as you have, but there was never any agreement that the organization behind the Signal project is going to reprioritize their development priorities or take on any additional costs in time, maintenance cost, infrastructure, or manpower as a result of whatever you decide to do with their source code in your project.

Since OWS can’t be expected to deal with hosting and making changes around your modified project’s ecosystem, you decide to host your own servers for your LibreSignal users, providing much of the same required features that OWS’ Signal servers provide, but tailored to work for your modified LibreSignal app. Now your users can chat amongst one another just like Signal users, without dealing with the GCM dependency and all is well and good. You were able to satisfy that niche of users.

Only now you realize, many people, for one reason or another, must rely on having Google Play and other Google services installed and running on their Android phone and are not technically savvy enough or simply do not have the time or inclination to install LibreSignal or rely on non-Google Play delivery systems like F-Droid, which inherently require them to enable third-party software installations which they likely do not understand the risks associated with.

Those people just download Signal off of Google Play as it is a very secure and reliable way for average Android users to obtain software. Unfortunately, your LibreSignal users can’t talk to the official Signal users because of that thing we mentioned a long time ago: server federation – that thing OWS and Moxie tried before, had a very bad experience with, and have deemed to be a mistake not to be repeated again, at least until someone else does the work and proves them wrong, at which point Moxie has stated they would be open to federating again.

The Google Dependency

Since we’ve opened the can of worms regarding the ackward intersectional topics of Google, privacy, nation-state surveillance and Signal, we may as well bite the bullet and talk about it. A primary reason many LibreSignal users “go Libre” in their philosophy is due to a very reasonable distrust of Google and, let’s be honest, literally every American corporation for exactly the same, very serious reasons:

  • Title 2, Section 215 of the USA PATRIOT Act
  • Title 7, Section 702 of the Foreign Intelligence Surveillance Act (FISA)
  • Title 18, Section 2701, AKA Stored Communications Act (SCA) of the Electionic Communications Privacy Act of 1986 (ECPA)

These laws allow the US government, specifically the FBI (and in some cases the NSA), to issue various national security letters, orders from the Foreign Intelligence Surveillance Court, or grand jury subpoenas to communications service providers like OWS or Google, along with orders gagging the provider from announcing the receipt of such orders to its users.

The general idea here is that if Signal is distributed through Google Play, then Google could theoretically, in cooperation with the FBI or NSA, use their access to Google Play to distribute a malicious copy of Signal to your device in order to facilitate spying on you. They could also issue similar orders requesting data Google or OWS has on their users as a result of a surveillance target using Signal, Google Play, or the dependent Google Cloud Messaging and Google Services Framework.

Moxie has recently stated that Google Cloud Messaging is not used to transmit any message data to a user. It’s used to send an empty ‘wake-up’ message to your device to trigger Signal to connect to the server to receive queued messages if the app wasn’t running in the foreground on your phone.

Still, there is the issue of metadata leaks to Google, although if you’re using an Android phone, there is probably more valuable metadata available to Google elsewhere than is introduced by Signal using GCM to facilitate push notifications.

To that end, Moxie, ever the pragmatist, has continuously stated that he welcomes anyone unhappy with GCM to submit “a clean, well written, and well tested [pull request] for websocket-only support in Signal […] that comes with a warning and only runs in the absence of play services.” He expects it will have trade-offs of “high battery consumption and an unreliable user experience.”

So far, nobody has submitted such a pull request.

Also, the scenario of a hostile Google (or man-in-the-middle) sending a malicious Signal update to your device through Google Play is balanced by the PackageManagerService running on your Android device, and part of its job is to validate the authenticity of the signing key used to sign the update.

PackageManagerService

Let’s walk through this real quick: Moxie decides he wants to issue an update to Signal users. He physically takes a copy of the Signal source code on a removable device, like a CD or USB flash drive, and copies it onto an air-gapped build machine, builds the update, then signs it with his encrypted signing key, which is always kept offline.

Since the PackageManagerService is part of the open-source aspect of the Android OS, we can confirm that the PackageManagerService is working as expected and properly validates keys, by reviewing the source code before building our device image or by checking the validity of our installed image prior to performing an update.

If you’re trying to protect against a hostile Google/Apple and OWS all cooperating with the NSA and FBI to target you, then you have no business carrying most modern cell phones or an Android device or having phone conversations with anyone using such things.

There are diminishing returns and trade-offs to consider when mitigating security risks. Signal is there to help average users running iOS and Android to easily have more secure communications than not using Signal on those platforms and OWS develops Signal for those platforms. They have a limited staff and budget and have to make very careful decisions on how their time is spent.

If you want to run a separate fork of the Signal project specifically for other device types, then OWS and Moxie seem to encourage you to organize and obtain donations and other funding to support the infrastructure and development needs of your project, just as they do for theirs, but I don’t think it’s right to expect them to do that on behalf of other projects at the expense of their own.

We got the source code for free already; asking them to help support our side endeavours financially, et al, is a little disingenuous.

Social Graph Privacy

Next up on the list is the issue of contact privacy, also known as the privacy of your social graph. The Signal app requests permission to view and modify your device contacts when you install it. This is optional as of Android 6, as you can choose to individually disable permissions granted to each app on your device.

According to Moxie, this is used to associate incoming phone numbers in Signal with names to display locally in your client. So this way you see names in Signal instead of a list of phone numbers.

Signal also takes a cryptographically-hashed list of your contacts and periodically uploads it to the intermediary Signal servers, which then check the list of hashes against the Signal subscriber database, in order to determine which of your contacts are Signal users and which ones aren’t, before immediately discarding the hashed contact list. It does this to know if it should send an encrypted Signal message or a normal SMS message to a given contact.

Moxie has noted this remains an unsolved problem throughout the infosec community with regards to phone numbers and how secure hashes can be with how, relatively, few possible combinations of phone numbers exist (small preimage space). As long as you want the conveniences provided through contact discovery, this is a problem you have to live with for the time being.

I have used Signal with the Contacts permissions disabled and it worked fine, although inconveniently, as I had to manually enter the number of my contacts and the list in Signal shows only phone numbers now. Again, that’s a trade-off for the additional security. If contact privacy is that huge of a concern for you, disable the permissions.

Sharing Your Phone Number

As far as I’m aware, you can use a disposable phone’s number when setting up Signal on your primary phone. The number you associate with Signal on your device doesn’t have to be the number associated with that device. I have also used Signal on the desktop via their Chrome app, with the app linked to a phone that was later physically destroyed, and I was still able to send and receive encrypted messages via the desktop app.

That could have implications for that niche of Signal users that would prefer not to share their primary mobile number with anyone they want to Signal with or people that regularly use burner/disposable phones to avoid analysis by certain classes of observers.

Planning for Compliance: The FBI Grand Jury Subpoena

Moxie and OWS aren’t ignorant to all of our privacy concerns as users. They know there’s a risk of being served a FISA or other secret government order that could put their users privacy at risk and so they have designed their strategy with that in mind.

As previously mentioned, when Signal shares your contact list with a Signal server, the server immediately discards that information after completing its task. OWS goes out of their way to ensure a minimum amount of information is retained about a user on their servers.

Better than a company privacy policy, however, is a real world test by just the adversaries for the job: the US Federal Bureau of Investigation and a federal grand jury:

On 4 Oct. 2016 the ACLU reported that earlier this year, Open Whisper Systems was the subject of both a federal grand jury subpoena seeking an exceptional amount of information from Signal for two phone numbers the FBI believed to be associated with Signal accounts, as well as a gag order barring OWS from notifying any person of the existence of the subpoena.

Both the subpoena and the associated gag order were issued by the US District Court for the Eastern District of Virginia, in association with an FBI investigation in that district. The subpoena demanded the following from OWS:

True to their privacy policy, the extent of the information OWS could provide the FBI was the following:

All OWS could provide was the account creation date and the day of the last connection. They partnered up with the ACLU and defeated the gag order, which is why we have access to all of these redacted documents and can have this discussion now. OWS also posted about the subpoena and gag order battle on their website.

The fact we have this information and the way this has played out so far with OWS, I think says a lot about the group of individuals behind this project and what user privacy means to them.

Taken with everything else we’ve addressed, I can’t imagine why anyone would not recommend Signal to a journalist running Android or iOS on their mobile device. I challenge the other author and any other critic to find a more secure, easy to use solution for non-technical activists and journalists to protect their communications that has such a proven track record and transparency.

The project isn’t perfect and neither is Moxie, but they keep an open dialogue with their community and have a deep understanding of all aspects of the privacy and security problems we are facing today.

We should be rallying behind companies and developers like this, with code contributions and with donations, and maintain an active dialogue to continue changing it for the better.