Why I won't recommend Signal anymore(sandervenema.ch)
sandervenema.ch
Why I won't recommend Signal anymore
https://sandervenema.ch/2016/11/why-i-wont-recommend-signal-anymore/
334 comments
The author of this post believes that by making a stand over Signal policies he doesn't like (the superficial GCM dep, the OWS-only server policy, the contact list discovery system), something more like LibreSignal will grow to take Signal's place.
The author is wrong. LibreSignal won't replace Signal. Something like Telegram will: an "open source" messaging system with inferior cryptography, "opt-in" end-to-end messaging, a long-term dependency on the telephone system for authentication, and a far "cuddlier" personality with its users and, more importantly, with people from the app development community (like the author). Telegram will continue to gain adoption, because sexy beats sound in every end-user match up. Signal is the closest thing sound cryptography has to a palatable solution for end users.
Iran has already compromised Telegram users, because it systemically trades security off for user adoption. They'll get more of them, and people will hang from cranes as a result.
It's not wrong to criticize Signal. Signal does things I don't love, too! But we should be clear-eyed about the market.
The author is wrong. LibreSignal won't replace Signal. Something like Telegram will: an "open source" messaging system with inferior cryptography, "opt-in" end-to-end messaging, a long-term dependency on the telephone system for authentication, and a far "cuddlier" personality with its users and, more importantly, with people from the app development community (like the author). Telegram will continue to gain adoption, because sexy beats sound in every end-user match up. Signal is the closest thing sound cryptography has to a palatable solution for end users.
Iran has already compromised Telegram users, because it systemically trades security off for user adoption. They'll get more of them, and people will hang from cranes as a result.
It's not wrong to criticize Signal. Signal does things I don't love, too! But we should be clear-eyed about the market.
Unfortunately, Google has made it (almost) impossible to wake up the phone via some external event without using its proprietary GCM. Even though GCM is not part of AOSP, it has unique status on the platform that can't easily be replicated (without recompiling the kernel, etc like the article mentions).
Before the days of doze mode & other battery optimizations, you could just listen & block on a socket, then let the phone go to sleep. Incoming 3G packets would wake up the phone, you grab a wakelock, then start doing things. From what I remember, at least a while ago Facebook Messenger did this using MQTT. But this is not possible any more.
Before the days of doze mode & other battery optimizations, you could just listen & block on a socket, then let the phone go to sleep. Incoming 3G packets would wake up the phone, you grab a wakelock, then start doing things. From what I remember, at least a while ago Facebook Messenger did this using MQTT. But this is not possible any more.
I highly recommend Conversations (disclaimer: I've worked on it in the past, although I'm not a project "member" per say): https://conversations.im/
It's open source, uses a federated, open protocol, and can do multiple types of encryption including OTR and OMEMO (an XMPP wire format that uses the Axolotl ratched devised for signal). It does not do VoIP, so it would just be for chat (although there is a large bounty on Jingle-based voip support open). It has also had a public security audit, and is designed to be white labeled so you can tweak a few variables in the source and build your own hardended version or encrypted-only version, etc.
It's open source, uses a federated, open protocol, and can do multiple types of encryption including OTR and OMEMO (an XMPP wire format that uses the Axolotl ratched devised for signal). It does not do VoIP, so it would just be for chat (although there is a large bounty on Jingle-based voip support open). It has also had a public security audit, and is designed to be white labeled so you can tweak a few variables in the source and build your own hardended version or encrypted-only version, etc.
Essentially this guy is saying, Signal is secure, it's mostly easy to use (with the exception of multiple phone numbers), and the only alternative he mentioned is a half broken clone. Is he seriously going to stop recommending it to people whose lives depend on secure communications because of some abstruse ideological point? In any case, Moxie's position is a reasonable one even though there are some arguments for federation.
While my current phone doesn't support Signal, once I get a new one I will continue to use it.
You might opine that allowing Signal clones would allow me to use the app, but they would almost certainly be maintained by people who aren't really crypto experts, and so it's better to operate as though I am broadcasting in cleartext than to pretend that I'm not and get burned.
While my current phone doesn't support Signal, once I get a new one I will continue to use it.
You might opine that allowing Signal clones would allow me to use the app, but they would almost certainly be maintained by people who aren't really crypto experts, and so it's better to operate as though I am broadcasting in cleartext than to pretend that I'm not and get burned.
Signal may not transmit any payload via Google Cloud Messaging, but Signal's requirement to run Google Play Services compromises the user's privacy in ways that have nothing to do with Signal. If you run Play Services then you have a device which provides your communications metadata, whereabouts, and device usage habits to Google.
I don't trust Google with this information and don't want to carry such a device, but a handful of friends and family use Signal, so I must choose between easy/secure communication with them, and reducing my exposure to corporate surveillance.
Signal may be "pragmatic" among the current choices (just like the project's decision to use GCM is pragmatic), but OpenWhisperSystems absolutely deserves criticism for:
1. Tying secure communication to running what amounts to Google's spyware on your device
2. Offering no alternative for privacy-conscious users
3. Showing hostility to those trying to introduce such an alternative to the project
I think those dismissing these concerns as "crypto-puritanism" will be on the wrong side of history.
I don't trust Google with this information and don't want to carry such a device, but a handful of friends and family use Signal, so I must choose between easy/secure communication with them, and reducing my exposure to corporate surveillance.
Signal may be "pragmatic" among the current choices (just like the project's decision to use GCM is pragmatic), but OpenWhisperSystems absolutely deserves criticism for:
1. Tying secure communication to running what amounts to Google's spyware on your device
2. Offering no alternative for privacy-conscious users
3. Showing hostility to those trying to introduce such an alternative to the project
I think those dismissing these concerns as "crypto-puritanism" will be on the wrong side of history.
This.
I didn't know much of the insides of Signal. But, When WhatsApp decide to go in bed with FB to share my contacts and usage, one of the alternatives I explored was Signal. Threw it out the moment it asked for ownership of my contacts (no way to opt out). I for one am not going to trust a guy's pinky promise to be good with my contacts and meta-data.
If I'm going to give up the convenience of reaching anybody by WhatsApp, it is going to be at least worth it in the sense of privacy.
Still hoping for a GNU project that garners enough interest to be technically strong, and used universally. One can dream.
If I'm going to give up the convenience of reaching anybody by WhatsApp, it is going to be at least worth it in the sense of privacy.
Still hoping for a GNU project that garners enough interest to be technically strong, and used universally. One can dream.
"Also, there’s the issue of integrity. Google is still
cooperating with the NSA and other intelligence agencies.
PRISM is also still a thing."
https://googleblog.blogspot.com/2013/06/what.html
Google’s chief legal officer claimed that collection was being done without Google's consent:
http://www.irishtimes.com/news/technology/google-outraged-at...
Evidence leaked by Edward Snowden also points in the direction of illegal infiltration of Google's private network without Google's consent:
https://www.washingtonpost.com/world/national-security/nsa-i...
Any messenger, tied to phone number, is not safe. possible attacks are: 1) create copy of sim-card; 2) force mobile operator to intercept password-code, sent to your number, and "restore" password this way.
It may sound ridiculous for you, but in Russia it's reality (both vectors), it's real cases from life. And when user really need safe messenger, all of them are too careless to implement really safe way of messaging. And if you think these vectors are not possible in your country - be sure, we were thinking the same way.
EDIT: this isn't a response to most of the article, but specifically to the "Moving Forward" section, asking about alternative tools.
Come to the matrix!
https://matrix.org/
It's free -- all FOSS, including the entirety of the server -- and yes, all of it: proof by existence: several of my friends run their own.
It federates. I regularly join channels hosted on several different servers, and exchange messages without issue.
It's on every platform. I use it on the desktop, my android (cyanogen, without gapps, none the less!), and my ipad, every day.
It even has voice and video calling built in, using webRTC. This feature has been a little rough while it was in development, but I used it last week in a 1-on-1 call and had an effortless experience. The audio and video quality was on par with Google Hangouts.
Crypto is hard, but it's coming. The Matrix developers have huge respect for the axolotl ratchet design used in Signal. They've worked on making another implementation (in C, for easier linking in various languages, ostensibly) here: https://matrix.org/git/olm/
The deployment of that code to give full End-to-End encryption is a work in progress, but the beta is roughly functional. It includes everything you'd expect: communication works by default, but in an encrypted room, messages are flagged yellow if you haven't explicitly verified the sender's key. There's a key per device; it doesn't leave the device; and as soon as you verify that device/key, messages from it are green, and you're E2E secure.
Disclaimer: I have no direct association -- I became a Matrix convert after trying to write some XMPP client code about a year ago. I'm just really enthusiastic about recommending it because the tech is solid, the sync is good, it solves a problem, and the team hasn't stopped either: they been firing on all cylinders constantly since I started using Matrix.
I love Signal for their dedication to getting encryption right and the security of their users. But yes, I also share a lot of the concerns listed in this article. Most of all, I honestly believe federation is an imperative. So, while acknowledging Signal's history of outstanding security work... Hey, let's celebrate there's more than one game in town working on alternatives.
Come to the matrix!
https://matrix.org/
It's free -- all FOSS, including the entirety of the server -- and yes, all of it: proof by existence: several of my friends run their own.
It federates. I regularly join channels hosted on several different servers, and exchange messages without issue.
It's on every platform. I use it on the desktop, my android (cyanogen, without gapps, none the less!), and my ipad, every day.
It even has voice and video calling built in, using webRTC. This feature has been a little rough while it was in development, but I used it last week in a 1-on-1 call and had an effortless experience. The audio and video quality was on par with Google Hangouts.
Crypto is hard, but it's coming. The Matrix developers have huge respect for the axolotl ratchet design used in Signal. They've worked on making another implementation (in C, for easier linking in various languages, ostensibly) here: https://matrix.org/git/olm/
The deployment of that code to give full End-to-End encryption is a work in progress, but the beta is roughly functional. It includes everything you'd expect: communication works by default, but in an encrypted room, messages are flagged yellow if you haven't explicitly verified the sender's key. There's a key per device; it doesn't leave the device; and as soon as you verify that device/key, messages from it are green, and you're E2E secure.
Disclaimer: I have no direct association -- I became a Matrix convert after trying to write some XMPP client code about a year ago. I'm just really enthusiastic about recommending it because the tech is solid, the sync is good, it solves a problem, and the team hasn't stopped either: they been firing on all cylinders constantly since I started using Matrix.
I love Signal for their dedication to getting encryption right and the security of their users. But yes, I also share a lot of the concerns listed in this article. Most of all, I honestly believe federation is an imperative. So, while acknowledging Signal's history of outstanding security work... Hey, let's celebrate there's more than one game in town working on alternatives.
There's a fundamental assumption here: that there is a better way. I'm not saying there isn't, but there's a pretty good existence proof that Signal is the best combination of security & simplicity we can put together.
I would agree with this statement from the article: "there should be a tool that is fully free software (as defined by the GNU GPL), that respects users' freedoms to freely inspect, use, modify the software and distributed modified copies of the software. Also, this tool should not have dependencies on corporate infrastructure like Google’s (basically any partner in PRISM), that allows these parties to control the correct working of the software."
There are such tools. None of them are as easy to use as Signal. So for now, I recommend Signal. I can't, in good conscience, recommend anything else... and given the author doesn't speak to what they recommend, I'm curious about what their recommendation would be.
I would agree with this statement from the article: "there should be a tool that is fully free software (as defined by the GNU GPL), that respects users' freedoms to freely inspect, use, modify the software and distributed modified copies of the software. Also, this tool should not have dependencies on corporate infrastructure like Google’s (basically any partner in PRISM), that allows these parties to control the correct working of the software."
There are such tools. None of them are as easy to use as Signal. So for now, I recommend Signal. I can't, in good conscience, recommend anything else... and given the author doesn't speak to what they recommend, I'm curious about what their recommendation would be.
"Also, there’s the issue of integrity. Google is still cooperating with the NSA and other intelligence agencies. PRISM is also still a thing. I’m pretty sure that Google could serve a specially modified update or version of Signal to specific targets for surveillance, and they would be none the wiser that they installed malware on their phones."
Isn't part of the reason that Moxie went with the Google Store is that he gets to sign the god damned binaries, making it impossible for Google to modify the app.
Isn't part of the reason that Moxie went with the Google Store is that he gets to sign the god damned binaries, making it impossible for Google to modify the app.
Wire (http://wire.com) has worked well on iOS for encrypted text/files/audio/video. Open-source client, no contact sharing neeeded. No phone number needed, you can register with email by using a desktop browser at http://app.wire.com, then logging into the mobile app. Group chat for text only. Timed/ephemeral messages for 1:1 text/files. Feature matrix, https://wire.com/privacy/. Could use more documentation (e.g. on retention of encrypted data) but a lot of questions are answered on Twitter or Github issues.
From the post:
"The Google Cloud Messaging service basically handles message handling from/to the user’s devices to the Signal servers. The GCM service then handles all the aspects of queueing all messages and delivery from/to users."
This is not true. Messages are delivered via Signal's own servers only. GCM messages are empty; their only purpose is to wake up your device. [1]
"The phone component of Signal is called RedPhone. The server component of this is unfortunately not open source [...] this is also probably the reason why secure encrypted phone calls don’t work in e.g. LibreSignal"
No. The reason for that is that the signaling for RedPhone calls is currently still done via GCM and not via Signal's own message transport.
Regarding microg: I've never heard of the need to re-compile kernels for that. I think most people use it with Xposed (admittedly, a giant hack, but it works).
[1] https://whispersystems.org/blog/goodbye-encrypted-sms/
"The Google Cloud Messaging service basically handles message handling from/to the user’s devices to the Signal servers. The GCM service then handles all the aspects of queueing all messages and delivery from/to users."
This is not true. Messages are delivered via Signal's own servers only. GCM messages are empty; their only purpose is to wake up your device. [1]
"The phone component of Signal is called RedPhone. The server component of this is unfortunately not open source [...] this is also probably the reason why secure encrypted phone calls don’t work in e.g. LibreSignal"
No. The reason for that is that the signaling for RedPhone calls is currently still done via GCM and not via Signal's own message transport.
Regarding microg: I've never heard of the need to re-compile kernels for that. I think most people use it with Xposed (admittedly, a giant hack, but it works).
[1] https://whispersystems.org/blog/goodbye-encrypted-sms/
Can't wait for moxie to jump into the commentary. :)
>Lack of federation
Moxie's pissy because he trusted the kangbangers at Cyanogenmod to to keep in sync with his development. They didn't. Someone will need to volunteer to run their own server that's kept updated, then buy Moxie a Snickers and hope he stops being moody.
>Dependency on Google Cloud Messaging
Fun fact: The iOS client doesn't use GCM, it uses Pushkit. GCM was chosen for Android because what else is as robust and doesn't eat battery? Moxie's voiced support of Websockets if someone implements it correctly and he can merge it as a fallback option when Play Services are missing. If you can't code and want it, contribute to the bounty on it:
https://github.com/LibreSignal/LibreSignal/issues/37
https://github.com/LibreSignal/LibreSignal/issues/43
> Your contact list is not private
https://whispersystems.org/blog/contact-discovery/
TL;DR, it's a tradeoff because nobody has a better idea that works at scale and is usable. Redphone used to have a good way of blindly doing contact discovery but it would require too much data for their current userbase.
>Lack of federation
Moxie's pissy because he trusted the kangbangers at Cyanogenmod to to keep in sync with his development. They didn't. Someone will need to volunteer to run their own server that's kept updated, then buy Moxie a Snickers and hope he stops being moody.
>Dependency on Google Cloud Messaging
Fun fact: The iOS client doesn't use GCM, it uses Pushkit. GCM was chosen for Android because what else is as robust and doesn't eat battery? Moxie's voiced support of Websockets if someone implements it correctly and he can merge it as a fallback option when Play Services are missing. If you can't code and want it, contribute to the bounty on it:
https://github.com/LibreSignal/LibreSignal/issues/37
https://github.com/LibreSignal/LibreSignal/issues/43
> Your contact list is not private
https://whispersystems.org/blog/contact-discovery/
TL;DR, it's a tradeoff because nobody has a better idea that works at scale and is usable. Redphone used to have a good way of blindly doing contact discovery but it would require too much data for their current userbase.
Nothing is stopping anyone from running their own servers, changing the username scheme, and implementing the voice signaling. Moxie doesn't complain about such usage. But that's more work than simply complaining and telling OWS what they should do.
As far as usernames go, that would require the signaling key to be remembered by the user. That doesn't work well in practice. As far as contact sync goes, has anyone submitted a patch for the android client to add an advanced option to disable that? On IOS access to the address book is user controlled at runtime. destinations will be validated by the server at compose time. Regarding federation, let's see some code. It's ridiculous to demand the small team that is OWS solve every single problem.
As far as usernames go, that would require the signaling key to be remembered by the user. That doesn't work well in practice. As far as contact sync goes, has anyone submitted a patch for the android client to add an advanced option to disable that? On IOS access to the address book is user controlled at runtime. destinations will be validated by the server at compose time. Regarding federation, let's see some code. It's ridiculous to demand the small team that is OWS solve every single problem.
I have started to read about matrix a lot.
- It now supports e2e encryption.
- It has a nice web and mobile client, called riot.im
- I has many other client options
- You don't need to show any phone numbers.
- Federated, you can host your own server
- It now supports e2e encryption.
- It has a nice web and mobile client, called riot.im
- I has many other client options
- You don't need to show any phone numbers.
- Federated, you can host your own server
Animated GIFS were the straw that broke the camels back?
Let's throw the best available solution under the bus.
This post will be my go to example of the myopia of some members of the security community. We have very few examples of well executed, consumer friendly privacy soloutions. Signal is the best for all possible scenarios: Open source, user friendly, buy in from a major Internet service.
I like wickr, but it falls short due to the closed source nature of the project.
Consumer friendly, usable security needs to be the number one priority for security advocates. We need to stop burning down houses because they are short a door or are the wrong color. The foundation is the hard part. Wait till there is a real alternative that can be used by people who are not c.s. majors before you argue that people should stop using the best available solution.
I appreciate the authors perspective and I agree with some of their points. Then they fuck it up by demonstrating purist jackassery. Worth a read as a useful persuasion antipattern.
Let's throw the best available solution under the bus.
This post will be my go to example of the myopia of some members of the security community. We have very few examples of well executed, consumer friendly privacy soloutions. Signal is the best for all possible scenarios: Open source, user friendly, buy in from a major Internet service.
I like wickr, but it falls short due to the closed source nature of the project.
Consumer friendly, usable security needs to be the number one priority for security advocates. We need to stop burning down houses because they are short a door or are the wrong color. The foundation is the hard part. Wait till there is a real alternative that can be used by people who are not c.s. majors before you argue that people should stop using the best available solution.
I appreciate the authors perspective and I agree with some of their points. Then they fuck it up by demonstrating purist jackassery. Worth a read as a useful persuasion antipattern.
I've trained hundreds of human rights defenders and journalists over the last 10 years and I will continue to recommend Signal. For too long the community has placed perfect security over usability - there are slightly more secure ways to communicate than Signal but they are far too disruptive to peoples work flows to actually be implemented.
> this tool should not have dependencies on corporate infrastructure like Google’s (basically any partner in PRISM)
Free yourself from the bonds of corporate infrastructure by installing this tool on your Google Android or Apple iPhone device (Microsoft Windows desktop version coming soon).
Free yourself from the bonds of corporate infrastructure by installing this tool on your Google Android or Apple iPhone device (Microsoft Windows desktop version coming soon).
There are several projects moving toward this. Matrix is probably the most well-known project, but its crypto isn't actually operational yet, AFAIK.
Tox works now, but for all their talk of trying to be user-friendly, asking users to exchange long alphanumeric sequences inherently isn't.
Psyc, maybe?
Tox works now, but for all their talk of trying to be user-friendly, asking users to exchange long alphanumeric sequences inherently isn't.
Psyc, maybe?
If they are only using GCM as a queue (and the messages are themselves encrypted) I don't understand what the problem is.
They could use anyone for that functionality. Even if the messages are given to an "adversary" what can they really get from that? Your phone app contacted the signal servers. That's really it.
They could use anyone for that functionality. Even if the messages are given to an "adversary" what can they really get from that? Your phone app contacted the signal servers. That's really it.
Redphone component.
I don't know why it's closed source. It's been suggested elsewhere in this thread that it was potentially IP issues they kept it closed for. Is it possible loose US CALEA law interpretation influences the reasoning? Or a gag?
I honestly don't know why they chose to do that but I wanted to comment in to see if a lawyer or someone from the project could hint at the reasoning.
I don't know why it's closed source. It's been suggested elsewhere in this thread that it was potentially IP issues they kept it closed for. Is it possible loose US CALEA law interpretation influences the reasoning? Or a gag?
I honestly don't know why they chose to do that but I wanted to comment in to see if a lawyer or someone from the project could hint at the reasoning.
I'm working on a completely open secure communications suite based on TweetNaCl. Proof-of-concept prototype is here:
https://github.com/Spark-Innovations/SC4
Working on a better UI at the moment. Could really use help, especially beta testers.
https://github.com/Spark-Innovations/SC4
Working on a better UI at the moment. Could really use help, especially beta testers.
I know the redphone is library is just a binary blob in the github repository:
The server code is up there too - in fact it's all up there. AFAICT, Signal is completely open source.
https://github.com/WhisperSystems/Signal-Android/tree/master/libs/armeabi
https://github.com/WhisperSystems/Signal-Android/tree/master/jni/redphone
The server code is up there too - in fact it's all up there. AFAICT, Signal is completely open source.
[deleted]
I haven't actually worked with GCM so please forgive me if this doesn't make any sense.
I suggest that, instead of routing all messages through GCM, what if Signal could send a "wake up" message via GCM, and then let the app pull the encrypted messages directly out of Signal's servers? A wake up message would only be sent by the server if the message could not be received by the client via normal means (implying that the device is asleep).
An optional user preference could allow some dummy wake up messages to be sent at random moments during the day, to support plausible deniability, at the cost of slightly worse battery life performance. This would all happen silently and the user would only notice a message notification when the app successfully fetches a new incoming message.
An optional user preference could allow some dummy wake up messages to be sent at random moments during the day, to support plausible deniability, at the cost of slightly worse battery life performance. This would all happen silently and the user would only notice a message notification when the app successfully fetches a new incoming message.
I didn't have to recompile my kernel to use microg...instead I used FakeGApps with Xposed framework. instructions: https://github.com/thermatk/FakeGApps
Signal is to get people from SMS and iMessage -> Signal. This means that cross platform communication becomes secure in transit.
Once Signal and others have really wiped out all the insecure messaging people are doing, then we can start with the identity problem with phone numbers. GCM, Contacts, etc are all related to this "phone number as identity" problem.
RCS is an unfortunate grab in this space, and we need to move fast before RCS is the default, and we're back to insecure messaging.
Email addresses are the best form of "federated identification" but are wildly insecure for communication. Here's to hoping we can get some better ones.
Once Signal and others have really wiped out all the insecure messaging people are doing, then we can start with the identity problem with phone numbers. GCM, Contacts, etc are all related to this "phone number as identity" problem.
RCS is an unfortunate grab in this space, and we need to move fast before RCS is the default, and we're back to insecure messaging.
Email addresses are the best form of "federated identification" but are wildly insecure for communication. Here's to hoping we can get some better ones.
For me I won't recommend it because of the horrible lack of options when you replace your phone (let alone lose it). No encrypted migrate. No backup options. Unencrypted loses content (images).
Plus there's no way to search old messages.
Plus there's no way to search old messages.
He says he thinks the protocol is secure, then says he doesn't want it to use GCM because it routes messages via Google who he doesn't trust (fixing that is the point of the encryption) and then talks about an attack that'd apply to any app regardless of whether it used GCM or not.
He finishes with a call to action: "We as a community need to come up with a viable solution and alternative to Signal that is easy to use and that does in fact respect people’s choices ... this tool should not have dependencies on corporate infrastructure"
But like a lot of armchair moralising, he isn't willing to debate the hard choices that go into building successful software. He says it should "respect people's choices" as if Signal is built by people who are disrespectful, he says it should not have dependencies on "corporate infrastructure" as if volunteer run datacenters actually exist, and then says his motivation is avoided paywalls, ignoring that both Signal and WhatsApp are free.
It reads like a collection of talking points rather than a coherent argument.
Signal is unusual because it combines cutting edge cryptography with consumer friendliness and is actually successful. It's pragmatic, not ideological. Crypto-warriors have a long history of producing secure software that nobody uses and then blaming the general public for not getting it; this sort of blog post is just a continuation of this decades long trend.