I agree overwhelmingly with what you wrote, except that I want to point out that this isn't "crypto-puritanism". It's just hipsterism. The author isn't a cryptographer, and if you asked a panel of 10 cryptographic engineers what messaging system they'd recommend, 9 of them would say "Signal".
The 10th wants you to use something else because they're working on an attack for that "something else", and want their paper to be splashier when it's released. :)
When reading critiques of messaging software, keep in mind that messaging is a fucking midnight back-alley knife fight of a market. For whatever reason --- I think because (a) basic chat software is pretty easy to write, with a near- hello- world payoff similar to, say, blog software for Ruby on Rails and (b) because there have been multi-billion-dollar acquisitions of messaging tools --- there are a lot of different messaging products. Messaging is a network-effect market, so all the different vendors are fighting for users.
I don't think Signal has sockpuppets (it's just not their style), but I know several other "secure" messaging applications do.
I think these types of posts are also the inevitable result of people overestimating our organizational capacity based on whatever limited success Signal and Signal Protocol have had. It could be that the author imagines me sitting in a glass skyscraper all day, drinking out of champagne flutes, watching over an enormous engineering team as they add support for animated GIF search as an explicit fuck you to people with serious needs.
I invite those who have opinions about Signal to start by getting involved in the project. To my knowledge the author of this blog post has never submitted a PR, issue, or discussion post to any of our repositories or forums. Many of these points are things that we would like to address, and we could use the help. The day to day reality of developing apps like these is a lot of work.
To provide some color on a few of these:
> Dependency on Google Cloud Messaging
To clarify this for casual readers, no data at all is transmitted over GCM. GCM is only used as a push event to tell the Signal Android client to wake up and connect to the Signal server to retrieve messages from the queue if the app isn't in the foreground.
This is pretty fundamentally just how Android works. However, people who want to use Google's OS without any Google services flash custom ROMs onto their devices that are missing this dependency.
I have said many times that I have no problem with supporting these custom ROMs. But I would like someone from that community to submit the PR: "I would consider a clean, well written, and well tested PR for websocket-only support in Signal. I expect it to have high battery consumption and an unreliable user experience, but would be fine with it if it comes with a warning and only runs in the absence of play services."
Nobody has done it.
> Your contact list is not private
First, on Android 6+ you can just disable the contacts permission and everything works (although you obviously won't see your contact names).
However, we also spend a lot of time thinking about this class of problems, as well as metadata in general. Right now things are playing out alright for one specific class of attack:
We'd obviously like to do even better. The nice thing about having a centralized service is that we can eventually take steps in this direction. People seem to equate federation with meta-data hiding for reasons I've never totally understood, but I think serious metadata protection is going to require new protocols and new techniques, so we're much more likely to see major progress in centralized rather than distributed environments (in the same way that Signal Protocol is now on over two billion devices, but we're unlikely to ever see even basic large scale email end to end encryption).
However, I would love it if someone proved me wrong. The Signal clients and server already support federation, so there shouldn't be any technical hurdles stopping the people who are really into federation from using our software to start their own federated network that demonstrates the viability of their ideas.
If anyone needs help doing that, let me know. I'd be happy to help.
> However, I would love it if someone proved me wrong. The Signal clients and server already support federation, so there shouldn't be any technical hurdles stopping the people who are really into federation from using our software to start their own federated network that demonstrates the viability of their ideas.
> If anyone needs help doing that, let me know. I'd be happy to help.
I appreciate that you would say this. I suspected that you actually felt this way despite your pragmatic approach outlined in that blog post. I'm a fan of federation, but I think the developers of federated systems have to take the problems outlined in your blog post very seriously and not defensively.
Push notifications without GCM can be done without losing reliability or ruining battery life, but it's difficult. There are a few apps like Conversations doing it well but it's quite rare. GCM is still technically more efficient since it's reused across multiple apps, but it doesn't really matter especially without a large number of apps doing this.
There's already a built-in warning on modern Android because apps need to request a battery optimization exception just as they would one of the dangerous permissions. Otherwise, GCM is the only way they be woken during Doze / App Standby for push notifications. Apps can't simply poll anymore. It's unfortunate that even an app doing a great job like Conversations gets a warning / prompt about this but there's little that can be done about that beyond the OS whitelisting the keys for known good apps.
Conversations is pretty much the only viable option without GCM. It uses a take on the Signal protocol via XMPP (when supported by the other contact) so you helped to make that happen anyway.
> First, on Android 6+ you can just disable the contacts permission and everything works (although you obviously won't see your contact names).
This is very good.
> However, we also spend a lot of time thinking about this class of problems, as well as metadata in general. Right now things are playing out alright for one specific class of attack: [federal subpoena]
Good, so Open Whisper Systems has no metadata. Do any third parties retain metadata about Signal messages?
There's also the issue of mobile numbers. I get that more-or-less anonymous numbers are doable. But arguably, most Signal users don't have anonymous numbers. However, maybe this is a non-issue, if the only data available are "the date and time a user registered with Signal and the last date of a user's connectivity to the Signal service". Is that it?
> Good, so Open Whisper Systems has no metadata. Do any third parties retain metadata about Signal messages?
I'll try to answer to the best of my knowledge (I'm not associated with project, I'm just a happy customer).
Does your ISP know that you are communicating with Signal servers? Yes, IP addresses.
Does it know to whom you are sending messages? No.
Does Google know you are using Signal? Yes.
Does it know whom of your contacts use Signal? Yes, because they have a full list of your contacts and they know if someone has installed Signal.
Does Google know you've sent a message? No.
Does Google know that you are receiving a message? Sometimes, because Signal servers ping your device via GCM with "wake up".
Does Google knows who from your contact list send this message? No, unless you have only one contact who uses Signal.
Can Google infer from pings who is communicating with whom? Yes, although pings are needed only if app has disconnected from server, and this severely limits usefulness of this technique.
Where else may any metadata coming from usage of Signal be? Nowhere.
As for Google having your contact list... Take a look into Flock.
I get that Signal is probably the best option for smartphones. And that maybe its vulnerabilities are only relevant for "TAO targets". But the problem is that "TAO targets" is in rapid flux, given developments in automation and AI. So arguably, more and more journalists and dissidents are becoming vulnerable.
And there's the fundamental insecurity of devices with cellular-radio connectivity, and operating systems that users can't control and lock down. Signal can do nothing about that. Even something as simple as reliably obscuring identity in connections to Signal servers is nontrivial.
> But the problem is that "TAO targets" is in rapid flux, given developments in automation and AI.
You are implying that cost of TAO consists mostly of labor costs. Which is false. NSA and friends are not really limited by money. They are limited by amount of unpatched software vulnerabilities. Every use of vulnerability in the wild is a chance of revealing it to world and losing it. Snowden docs reveal the existence of automated software which evaluates chance of vulnerability being revealed by attack. XKeyScore or one of related pieces, AFAIR.
It's nearly impossible to find out. But if I trust corporations like Google not to exploit the possibilities, I wouldn't be looking for an open-source alternative to WhatsApp in the first place.
You shouldn't use a smartphone if you expect to be TAO. Even the hardware could be compromised. Use a laptop with Linux for anything anyone might want to track...
Then why is Moxie advertising with Snowden the Signal app as communication for TAO targets?
And for non-TAO targets, WhatsApp is just as good as Signal – the users won’t read the source code anyway, and in both cases President Trump gets your social graph.
Aka NSA's "we really need to get access to this device and will fund diverting backbone traffic / writing firmware malware / whatever else we need to in order to get it" team(s).
> I invite those who have opinions about Signal to start by getting involved in the project.
Yeah we've been there. Do you remember someone on Github complaining about the Google dependency? You closed that issue as a wontfix. Or LibreSignal? I read the post where you basically told them to go away on Github too.
That's why I haven't recommended Signal ever since trying it myself a year or two ago.
Not sure what you're talking about, because the issues in question, #127 and #1000, are open.
> you basically told them to go away on Github
Quite the opposite [1]:
"I would consider a clean, well written, and well tested PR for websocket-only support in Signal. I expect it to have high battery consumption and an unreliable user experience, but would be fine with it if it comes with a warning and only runs in the absence of play services."
Plus the complaint about giphy seems to completely miss the point that the more 'random messaging users' Signal attracts the better from a POV of deniability/etc.
Although the masking effect may be useful, my immediate thought was how much extra code and buffer overflows had been added to the client. Android doesn't have any sandbox mechanism like pnacl to contain such code.
In addition to Moxie's comment about using Java, you're more broadly confused, I think.
Pnacl provides sandboxing, but it doesn't seem to provide any protection against buffer overflows. Android apps are also sandboxed, so I'm not sure what your point was.
Android (at least recent versions) has both NX pages and ASLR, both of which are specifically designed for these kinds of attacks. Sandboxing isn't, really, especially if your sensitive content (messages!) are inside the sandbox, obviously.
Perhaps I did not isolate my concerns in sufficiently deliberate language.
You may be aware that of late there have been numerous buffer overflows (or other parsing problems) in standard image parsing libraries. Where these are implemented in Java that may be less of a concern, but this type of task is often handled by native code. And while more Java exploits are via breaking the verification in clever ways, via reflection or priviledged calls or pickling, that does not rule out that processing external data can lead to an inconsistent state. It might not be a problem with gifs, if they are small, but animated gifs can be large. Or maybe java
See this discussion on Android image processing:
https://code.facebook.com/posts/366199913563917/introducing-...
The point of PNaCL is that you can use it to sandbox components within the same process/permission set, you don't have to rely on the OS. It has a much smaller attack surface than Java.
You talk about NX and ASLR being useful in the same post as you say buffer overflows can't happen. In any case, while they may be designed to restrict attackers, they are by no means sufficient. There are Java ROP gadget chain builders! JVMs use JIT, which inherently means they are creating new code. Eg. see jit spraying.
are you part of that knife fight? calling the article writer a hipster in this comment, and what seems to amount to "It's not wrong to criticize Signal. but don't because telegram is worse and more likely to win" in your other comment (since they arn't asking for libresignal to take over, just for a decent alternative to exist which currently probably does not)
It seems a really strong and a bit aggressive of an attitude to have against a person's opinions
No, because I'm not affiliated with any messaging applications. Nor, by the way, am I saying that the author is --- I don't know them. I'm saying it's a good thing to know about the conversation.
Rereading my post here, I can see why a reader would infer from it the idea that the author might be a sockpuppet. I don't believe that! I was thinking more about the kinds of comments on message boards that say Signal is a "honey pot". I could have written that more carefully, so, sorry about that.
GCM has practically nothing to do with the security/privacy of Signal, but it is the #1 "concern" that people who don't understand cryptographic messaging security feel they must relate about Signal.
My main concern with GCM is that it's unavailable on fully open OS builds, so requiring it compromises the security of the device as a whole, rather than Signal in particular.
That's one of several things that are reasonable not to love about Signal. Criticism intended to urge Open Whisper Systems into changing their Signal policies are reasonable. A statement that someone would recommend less secure messaging solutions to investigative journalists is another --- something I find much harder to be supportive of.
There are alternatives with comparable or better security, but they tend to have other flaws. Most of the alternatives including Wire and Riot ALSO depend on GCM, otherwise they either lack push or force ridiculously bad battery life. They also have bad UX since they don't ask the user for a battery optimization exception permission, so the user would have to somehow know it's required or they'll break after a while in the background.
Conversations / OMEMO is a great Android messaging client, but it's ONLY available for Android and a desktop client (Gajim OMEMO plugin). It can use OTR (which it marks as less secure) but there isn't even a decent iOS OTR client anyway. ChatSecure iOS will probably get OMEMO and push support along with becoming a more decent client but it's going slowly. Until that happens, Conversations is problematic because there isn't a decent way to talk to iOS users.
Nobody is saying Signal has less secure cryptography than others. But being able to run it in CopperheadOS without loading microg would make the whole setup much more secure. And one cannot dissociate both things.
What confuses me about the post is that the author does not make it clear if he recommends that journalists run CopperheadOS. It sounds like he does not recommend this, but rather opposes Signal's dependency on Play on general principals.
But if his journalists are using Android or iOS anyway, there's no practical advantage in Signal not depending on GCM or the Play Store, and some real disadvantages (like less secure updates). So the whole complaint seems like rather contrived to me.
(I would contest the claim that running a massive, not-practically-auditable open source OS is actually any more secure than running iOS or Android+Play Services, but whatever.)
The point of CopperheadOS is not that it lacks Play Services... and Play does not provide more secure updates than an app store like F-Droid. In fact, Play abuses system privileges to bypass the signature system used by Android. It will happily clobber an app with another with a different signature. It moves all the security checks for that into the cloud... completely bypassing the standard trust-on-first-use signature system. Official builds of Signal could be hosted via an F-Droid repository, although there's no point when it depends on Play.
My point was that there's no real merit to the complaint that Signal requires Play Services if you're going to use an OS with Play Services installed anyway. One can reasonably argue that Signal should work on non-Play Androids, but since his target audience is non-technical users, it seems likely that they are all using (and are more secure using!) off-the-shelf iOS or Android phones, which implies a significant reliance on your vendor anyway.
Do you have any pointers on how Play bypasses local signature verification? I'm surprised about that.
> it seems likely that they are all using (and are more secure using!) off-the-shelf iOS or Android phones
In what sense are they more secure using stock Android than CopperheadOS? They wouldn't be installing it themselves either way. It's a product available for purchase too... have you done any research into what it is before making claims about it?
> Do you have any pointers on how Play bypasses local signature verification? I'm surprised about that.
Play contains a bunch of privileged / platform signature apps. They don't follow the regular permission rules. An unprivileged app not signed with the platform key cannot do automatic upgrades and counts as an unknown source. The Play Store chooses to bypass the trust-on-first-use signature checks of the package manager too. Upgrading apps via F-Droid or manually will perform the signature checks, but the Play Store does not. Try installing an app from F-Droid on a phone with Play, and note how Play will happily clobber it with an update signed with a different key. On the other hand, F-Droid won't do that even if you sign it with the platform key as CopperheadOS does to mark it as a unknown party source.
What's the threat? An attacker who can observe only traffic on the wire (e.g. an ISP) probably gains nothing from observing GCM, since a) it's probably hard to distinguish different types of GCM messages and b) the attacker can just observe traffic to the Signal servers directly.
An attacker who cannot generally passively intercept (but not decrpyt) traffic on the wire but can passively intercept traffic to/from the GCM servers would be foiled by not using GCM, but that's a very narrow case.
Hipsterism? That's horseshit. TFA is completely reasonable. At least 3 of these issues have prevented my privacy conscious friends from using it.
Especially the phone number thing. Phone numbers are quite sensitive. In some cases, the USG uses phone numbers alone for targeting drone strikes. They're enough to pull your credit report.
The 10th wants you to use something else because they're working on an attack for that "something else", and want their paper to be splashier when it's released. :)
When reading critiques of messaging software, keep in mind that messaging is a fucking midnight back-alley knife fight of a market. For whatever reason --- I think because (a) basic chat software is pretty easy to write, with a near- hello- world payoff similar to, say, blog software for Ruby on Rails and (b) because there have been multi-billion-dollar acquisitions of messaging tools --- there are a lot of different messaging products. Messaging is a network-effect market, so all the different vendors are fighting for users.
I don't think Signal has sockpuppets (it's just not their style), but I know several other "secure" messaging applications do.