One of the stated reason is "issues with various countries".
They really need to be more clear here. What issues, which countries? Are governmental pressures against encryption the real reason for the move? How much weigh these particular issues have over the support cost? That would be quite lame from Cyanogen to be weak that way and may make me reconsider installing this on my phone if they are susceptible to outside pressure.
If they are willing to remove encryption features to please totalitarian states, what backdoors are they also willing to include?
More importantly, they are pushing people towards Signal. Are those same "various countries" also pushing them to push us to use Signal, and if so why?
It's possible this is less of a "kowtowing to dictatorial states" move and more "we can't afford to comply with somebody's law" [1]:
As of 2009, non-military cryptography exports from the U.S. are controlled by the Department of Commerce's Bureau of Industry and Security. Some restrictions still exist, even for mass market products, particularly with regard to export to "rogue states" and terrorist organizations. [...] custom cryptographic software, and even cryptographic consulting services still require an export license.
You might argue that trying to regulate software to keep it from falling into the hands of terrorists is a fool's errand, and you'd be right, but until 1996 [2] it was illegal to export cryptographic software in the first place.
I expected them to become weaker on privacy the moment they partnered with Microsoft anyway. If you're still expecting Cyanogen to care about your privacy, you can forget about it. Time to move on to something like Copperhead OS, once it gets supported on more devices.
Oh, and fun fact. Copperhead OS was initially built on CyanogenMod for device compatibility purposes, but they eventually dumped it for AOSP because CM's code became too complex/insecure.
The WhisperPush feature had some major issues. It really does seem like it could have been a support nightmare, especially considering how easy it is to just download TextSecure/Signal. Registering my device with WhisperPush in the past created a conflict with installing TextSecure, even after opting out of WhisperPush. The only way to switch to TextSecure was to manually unregister my phone number through the terminal with a curl command I found on a github issue page. That isn't something that is ready to be preinstalled on the general public's devices.
> If they are willing to remove encryption features to please totalitarian states, what backdoors are they also willing to include?
That's a rather uncharitable interpretation. If a state was ordering them to include a backdoor in the next release, their options boil down to either 'include a backdoor' or 'shut down the service'[0]. Implying that a service that chooses the latter is more likely to also include a backdoor doesn't seem justified.
[0] (or 'have the resources for a massive secret legal battle', which may not even be possible depending on the nation state and nature of the order).
They may very well be prevented to explicitly name the what and who, but then it essentially becomes a trust issue.
If there is now one less security feature to please anonymous (for now) states, how to trust them not including other "features" on their requests? Uncharitable, and a tad paranoiac, as it may be...
Your trust model doesn't make sense to me. A trust heuristic that penalises even the least worst public action they could take on being served with a backdooring+gag order -- i.e. shutting down the service to avoid complying -- is effectively rewarding services that take no public action at all, ie silently comply.
Such a heuristic isn't paranoid -- if anything, it's rather credulous (by applying comparatively less scrutiny to services which operate out of the same jurisdiction (one known to serve orders of this type) yet which somehow happily continue operating).
It only makes sense on this specific case as something slipped through. So now, without more (possibly unobtainable) details we are left wondering.
In general, we are in desperate need of an effective Warrant Canary system. Being able to trust is important and difficult.
The problem with installing Signal on CM is that it's only available from Google Play and requires some Google components. You cannot install it from F-Droid on a Google-free Android.
And the maintainer has no interest in fixing this. There was a very long thread on Github where all of his concerns around this were addressed and solutions found, but he doesn't give a shit. I don't think Signal should have any kind of first class support in CM until it can be used without nonfree software.
Signal does not have any specific support in CM.
That's why WhisperPush was great, same technology, directly integrated and no need for Google Play. It's disappearance is bad for Cyanogen users in countries without GPlay.
And CM are not transparent as to who and why. If difficulties with specific countries, they should be explicitly named.
You do see the big trust issue for the users here? Warrant Canaries, or something similar, become a necessity in today's world.
The thing is : in this case we already know there were unspecified issues with anonymous countries. And they are now corrected I guess?
And without much more details, that may well be enough of a dead canary for the security minded to turn to something else.
> There was a very long thread on Github where all of his concerns around this were addressed and solutions found, but he doesn't give a shit.
I gather that you read the thread, so I won't go point by point and explain the reasonableness of his responses to the issue. I will -however- link to the Github issues that I remember that contain relevant discussion. [0] (Issues 127 and 281 are particularly relevant. 282 is included for the folks who don't understand that Signal for Android is distributed under the terms of the GPLv3.)
Moxie cares about providing solid, functional, easy-to-use, as-idiot-proof-as-possible communication encryption software. His target audience is everyone, not just the technically skilled. To that end, he wishes to make it very difficult for non-technical users to get Signal from a source that is substantially less secure than the Google Play App Store.
Anyone is free to download the source and build and sign their own binary. If you're technical enough to do this, you're presumed to be technical enough to understand the risks you're taking by doing this. For everyone who is not sufficiently knowledgeable to build from source, any binary package distribution mechanism needs to be at least as secure as Google's, and provide the additional features mentioned in Issue 281.
Also notice that Moxie supports the effort to replace use of GCM with Websockets. [1] Google does security well, but Moxie is neither beholden to them, nor is he opposed to equally secure and capable replacements to the services that Google provides.
Whisper Systems is carefully doing excellent work with Signal. Software like this is a great benefit to society.
>[...] non-technical users to get Signal from a source that is substantially less secure than the Google Play App Store.
F-Droid has signed apps.
>[...] Google does security well, but Moxie is neither beholden to them, nor is he opposed to equally secure and capable replacements to the services that Google provides.
Google is a known collaborator with three letter agencies (remember that famous "SSL added and removed here :)" diagram?). It's grossly unacceptable for security related software to require Google Play Services (spyware) on the end user's phone.
If I'm remembering the discussion correctly [0], at the time that Moxie felt that distribution by F-Droid was entirely unsuitable because of -among other things- their insecure code signing key handling practices. Remember that Moxie's target audience is everyone, not just technical users. I elaborate on this point in a couple of my other comments in the sub-threads.
> Google is a known collaborator with three letter agencies...
People say this. I contrast it with the fact that Google now configures its US datacenters (and the links between them) as if they were sited in hostile nations such as China. Switching from the "friendly nation" configuration to the "hostile nation" configuration was a crash project after the Snowden revelations. The project was not cheap. The situation on the ground is -always- more nuanced than can be expressed in a soundbite.
> It's grossly unacceptable for security related software to require Google Play Services (spyware) on the end user's phone.
* Can you point to a reliable, credible source that has analysed Google Play Services and determined that they are spyware, by any reasonable definition?
* As I mentioned in other comments in this thread, Moxie is not opposed to either distribution in non-Google App Stores, nor is he opposed to replacing the use of GCM (AFAIK, the only part of GPS that Signal uses) with Websockets. However, any replacement must be at least as secure and functional as what it replaces. Check my other comments in the subthreads for more information.
> Google is a known collaborator with three letter agencies (remember that famous "SSL added and removed here :)" diagram?)
The SSL diagram indicates not Google's participation; it shows that NSA was wiretapping their datacenters without their knowledge. PRISM indicates Google collaboration, though.
But see, the presence of Google Play in your phone does not magically allow Google or NSA to listen to Signal conversations.
The easiest way for them to do this would be sending a fake update with a backdoor. This is way more intrusive, targeted and detectable than tapping cables or getting access to Google data.
>The easiest way for them to do this would be sending a fake update with a backdoor. This is way more intrusive, targeted and detectable than tapping cables or getting access to Google data.
I'm not sure how familiar you are with Google Play Services, but it's designed to do exactly this. It's what Google came up with when they got fed up with OEMs failing to distribute newer versions of their things to end users. It can silently install updates and has access to almost every permission on your phone, and cannot be removed.
> I'm not sure how familiar you are with Google Play Services, but it's designed to [permit Google to silently update any application on the phone].
Unless Google also deactivates signature verification for the originally-not-signed-by-Google app that it pushes to the target's phone, the design of both Android and the Android Market make this impossible. You can't silently update an app signed with one key with an app signed with a different key.
If -however- you're talking about Google installing software that snoops on the conversation between the Signal software and Signal servers, then -in that case- Google gets nothing that any other adversary that has access to at least one node between those two points gets... namely, undecryptable cyphertext.
If you're trying to make the stronger claim that Google inserts special code (that they don't include in AOSP) that they use to read the unencrypted data of interest from RAM and transmit to their servers, then I reply:
"All modern computers -including Apple devices- suffer from this class of problem. You have to trust everyone who wrote kernelspace code loaded into your system, the OS authors, the people who put the boards in your computer into their housing, and the folks who made the boards and chips to begin with. This is a hard problem. Frankly, Google's solution to this problem is just about the best consumer-level solution in the industry, and keeps getting better as time goes on."
Ugh. Sorry, "Google gets nothing that ... gets" should read: "Google gets nothing that ... wouldn't also get". <---This is why you shouldn't comment while dead tired! :(
There are two problems I have with Signal - although I generally love it.
* It's not possible to use without a phone number. If you want to use it on a WiFi only device, you're out of luck.
* Which wouldn't be so bad, but there's no way to transfer between devices. You can't take an encrypted backup (on Android) and because you use their encryption keys, moving to another device means other Signal users get scary messages about not trusting you.
Minor problems & edge cases, sure - but still frustrating.
Another problem is, Signal is broken by design. NSA cares about metadata, not content. Signal exposes a lot of metadata to Google CM, which is in relationship with NSA. They also forbid releasing their app outside of Google-Play story, and that makes it even worse broken...
> If we were going to rank our priorities, they would be in this order:
> 1) Make mass surveillance impossible.
> 2) Stop targeted attacks against crypto nerds.
As long as US Army is not using metadata to shoot people with hellfire missiles on American soil, Signal is good enough for general population.
If you want perfect protocol - work on Vuvuzela. But good luck porting traffic analysis resistant solution to mobile phones with their limited battery capacity.
> on American soil, Signal is good enough for general population.
What do you know, general population of the world does not live on American soil.
I can't trust Moxie after he called Google, Microsoft and Apple having absolute control over people's good thing, and called people having control over their own devices "going back to the old broken desktop security model".
Can you trust someone like that? It all makes me think that Signal is some kind of honeypot.
> I can't trust Moxie after he called Google, Microsoft and Apple having absolute control over people's good thing, and called people having control over their own devices "going back to the old broken desktop security model".
When speaking about non-technical, generally-clueless-about-computers people? This is ABSOLUTELY the correct attitude to have. Being able to trick someone into installing softare that reports back everything you do on your computer by getting the user to Punch The Monkey is a BUG, not a feature. The screaming hellpit that is the state of PC security is very bad for the average computer user.
For technical users, systems (like Secure Boot, along with a chain of bootloader/kernel/userspace software verifiers [0]) that let you -say- securely attest that you trust an alternative source of software are really good, when implemented properly. They help prevent drive-by malware installation, as well as let you know when your machine has been tampered with. This is a GOOD property to have.
What about users who want to run their homebrew software (or even start to learn how to code), but don't want to be bothered with code signing key enrollment? On the one hand, I guess -in this world- they're left out in the cold, if they're not doing something in the browser. On the other hand, any programmer is going to quickly face challenges far greater than any non-pathologically-bad key enrollment mechanisms... if the would-be non-web-programmer never gets over this hurdle, it's very likely (in its absence) he would have been stopped by any of the other couple-hundred difficult things along the way.
[0] It's late, so some of these verifiers (particularly the userspace one) might not exist in any mainstream distro.
Sender and recipient's mobile phone number, length of the body, time and date of communication - for every conversation using Signal. Which is pretty much all the metadata you need.
This is good since it protects you from snooping from ISPs/carriers.
You are still exposed to Google/Apple, since it can easily combine your contact information with traffic information and with great deal of probability detect who was the recipient.
I still would take it over encrypted SMS, where this data is open to carriers and carriers are basically perma-owned by everyone.
The recipient is clear. Google can known with perfect certainty whether you receive messages using Signal. The sender of a message is not; only Moxie has any real ability to see who communicates with who. Google and those pwn Google can only see who receives messages, how many, how long, when.
3) Google knows that Alice is in Bob's contacts, and Bob is in Alice's contacts
Those three pieces of data should be enough. I don't see why Google can't do time correlation of those messages. Both Alice's and Bob's contact lists are very finite. It might be not obvious for single message, but for series of messages (and people chat this way) it should be very obvious who is talking to whom.
Number 1 is wrong, if I read the code correctly. The messages go from the sending phone to a whispersystems server via a protocol on top of HTTP, not via Google.
Can you point to the parts in the spec for the TextSecure protocol where this information is leaked? I was under the impression that a passive adversary could get
* Time of Tx to Signal server
* Rough message length
* Time of Tx of message from Signal server to recipient (assuming that they were listening on that path, too)
Is my understanding incorrect? Can a passive adversary inspect the data from a TextSecure/Signal client and determine more (or just the above) information from the data sent from the TS client to the TS server?
No single passive adversary gets all three. The information moves from the phones to *.whispersystems.org, then in a big fat stream to Google, then from Google to the recipient phones.
If the passive adversary has enough listening posts, it's totally possible for them to be reasonably certain that they probably got all three, unless some sufficiently clever stuff is happening either at the WS servers, or in Google's servers.
> ...Marlinspike apparently doesn't like the idea of independent builds of TextSecure and RedPhone so much...
Except:
(Feb 2013) "So that's where we are. I believe that the decision not to distribute prebuilt APKs achieves the following balance:
1) It does not encourage the average user to tick "allow 3rd party APKs" in Android settings.
2) It allows "power" users who can appropriately manage the risks to install TextSecure without Play by building from source.
The thesis essentially being, if you aren't able to build TextSecure from source, you probably aren't capable of managing the risks associated with 3rd party sources." [0]
and
(Jul 2013) "Hey @rickbarton , to my knowledge we have not forbidden anything. People have requested that we distribute official binary APKs outside of the Play Store, which we are currently choosing not to do for several reasons (#127, #281). If we can address those issues we would be happy to distribute binary APKs.
However, this does not "forbid" anyone else from doing whatever they please. ..." [1]
Other things:
* The author neither links to nor provides screenshots of, nor quotes from the Twitter comments that he references. This is a bit of a red flag.
* The author asserts that "Moxie is not open to arguments and wants TextSecure to be distributed only via Google Play. He already locked this discussion.", which is plainly not true. If it was true, Issue #127 would be closed, and Moxie would not have made the comment that he did on issue #281. [2] It's also notable that the discussion lock didn't happen until 2015-01-09... a year and a half after the requirements for official distribution outside of Google Play were laid out in the comment attached to issue #281.
The fellow running the Eutopia.cz F-Droid repo clearly has an axe to grind, and is either unable to, or in too much of a hurry to understand the actual situation on the ground. When dealing with security software, you really, really want skilled, careful, meticulous people to be in charge of design, implementation, and packaging. This guy doesn't seem to be such a person.
You should be able to use it on a wifi only device: install (sideload?) Signal, enter the phone number you want to register and wait for the timeout, then you'll get the verification code via phone call.
The decision to not allow exporting the key mitigates certain kind of attacks. I think the wording of the warning is appropriate and not that scary.
There's a fork [1] which is trying to address some shortcomings I consider very important:
- Doesn't need access to Google Play
- Won't need Google Cloud Messaging (websockets instead)
I would really like these features to be supported in the official client. I don't understand why moxie doesn't reckon that these are legitimate concerns. Leaking metadata can be dangerous.
* Remember that anyone can stand up a Signal server, and build a custom Signal client that will associate with the server that you stood up, rather than the official Signal servers.
Did you read my comment (and the followup in the subthread)? It kinda sounds like you didn't.
If you didn't, please go back and read them, and the first ten or so comments of each bug I link to. The "reservations" about F-Droid have to do with its unsuitability for securely distributing software, and have nothing to do with a desire to prevent distribution of Signal through non-Google App Stores.
I had read the whole discussion when it was posted originally.
And while I understand moxie's concerns about fdroid, and I would like fdroid to fix these, I'm not sure if he is making the correct compromise. Getting access to Google Play throughout the regular route implies getting closed stuff from Google into your phone...
> Getting access to Google Play throughout the regular route implies getting closed stuff from Google into your phone...
IIRC, getting access to software through the F-Droid marketplace explicitly required (at the time the big discussion was made (~3 years ago)) users to expose themselves to the risk that a compromise of F-Droid's online signing key (that -IIRC- wasn't even contained in an HSM(!)) would open them up to silent replacement of any and all software installed through F-Droid by the attacker. Note that "the attacker" could also be "anyone associated with F-Droid".
Despite what one might think about their for-profit datamining, Google has a really good track record with regards to the nitty-gritty of computer security.
When Moxie looked at what F-Droid provided, it was entirely inadequate to securely distribute software to TextSecure's target audience. Because TS/Signal is not currently officially distributed on the F-Droid market, I have to assume that it still cannot provide what is required to securely distribute Signal.
And, to top it all off, the F-Droid folks are so lazy that they write things like this:
"The latest version of the application is 0.6.2, and the security flaw has now been fixed. However, the author has not published any source code corresponding to the binary he released of this version, and far from wishing to help anyone stuck with his previous disastrous mistake, he actually asked for the application to be removed from our repository as he wants to distribute it via Google Play only." [0]
TS's source has been distributed via GitHub for ages. The version that the F-Droid guy says didn't have publicly available source at the time of his post appears to have been published for two weeks prior to his post. [1] If the guy who wrote that blog post is still in a position of responsibility at F-Droid, I don't trust the organization to pay sufficiently close attention to detail to package any security-critical software.
I'm assuming you already have a phone number that you'd otherwise regularly use. (does anyone not??)
If that's the case, then you can register it to Signal on an iPod and not have to worry about base-band attacks on iPhone/Android devices. That's the point.
61 comments
[ 5.5 ms ] story [ 120 ms ] threadWhy not just use signal and skip the special cyanogen version?
As of 2009, non-military cryptography exports from the U.S. are controlled by the Department of Commerce's Bureau of Industry and Security. Some restrictions still exist, even for mass market products, particularly with regard to export to "rogue states" and terrorist organizations. [...] custom cryptographic software, and even cryptographic consulting services still require an export license.
You might argue that trying to regulate software to keep it from falling into the hands of terrorists is a fool's errand, and you'd be right, but until 1996 [2] it was illegal to export cryptographic software in the first place.
[1] https://en.wikipedia.org/wiki/Export_of_cryptography_from_th... [2] https://www.eff.org/press/archives/2008/04/21-37
https://copperhead.co/android/
Oh, and fun fact. Copperhead OS was initially built on CyanogenMod for device compatibility purposes, but they eventually dumped it for AOSP because CM's code became too complex/insecure.
That's a rather uncharitable interpretation. If a state was ordering them to include a backdoor in the next release, their options boil down to either 'include a backdoor' or 'shut down the service'[0]. Implying that a service that chooses the latter is more likely to also include a backdoor doesn't seem justified.
[0] (or 'have the resources for a massive secret legal battle', which may not even be possible depending on the nation state and nature of the order).
If there is now one less security feature to please anonymous (for now) states, how to trust them not including other "features" on their requests? Uncharitable, and a tad paranoiac, as it may be...
Such a heuristic isn't paranoid -- if anything, it's rather credulous (by applying comparatively less scrutiny to services which operate out of the same jurisdiction (one known to serve orders of this type) yet which somehow happily continue operating).
That's easy to say when you aren't the person who'll be subject to criminal liability for violation of a gag order.
I gather that you read the thread, so I won't go point by point and explain the reasonableness of his responses to the issue. I will -however- link to the Github issues that I remember that contain relevant discussion. [0] (Issues 127 and 281 are particularly relevant. 282 is included for the folks who don't understand that Signal for Android is distributed under the terms of the GPLv3.)
Moxie cares about providing solid, functional, easy-to-use, as-idiot-proof-as-possible communication encryption software. His target audience is everyone, not just the technically skilled. To that end, he wishes to make it very difficult for non-technical users to get Signal from a source that is substantially less secure than the Google Play App Store.
Anyone is free to download the source and build and sign their own binary. If you're technical enough to do this, you're presumed to be technical enough to understand the risks you're taking by doing this. For everyone who is not sufficiently knowledgeable to build from source, any binary package distribution mechanism needs to be at least as secure as Google's, and provide the additional features mentioned in Issue 281.
Also notice that Moxie supports the effort to replace use of GCM with Websockets. [1] Google does security well, but Moxie is neither beholden to them, nor is he opposed to equally secure and capable replacements to the services that Google provides.
Whisper Systems is carefully doing excellent work with Signal. Software like this is a great benefit to society.
[0] https://github.com/WhisperSystems/Signal-Android/issues/127 https://github.com/WhisperSystems/Signal-Android/issues/281 https://github.com/WhisperSystems/Signal-Android/issues/282
[1] https://github.com/WhisperSystems/Signal-Android/issues/1000
F-Droid has signed apps.
>[...] Google does security well, but Moxie is neither beholden to them, nor is he opposed to equally secure and capable replacements to the services that Google provides.
Google is a known collaborator with three letter agencies (remember that famous "SSL added and removed here :)" diagram?). It's grossly unacceptable for security related software to require Google Play Services (spyware) on the end user's phone.
If I'm remembering the discussion correctly [0], at the time that Moxie felt that distribution by F-Droid was entirely unsuitable because of -among other things- their insecure code signing key handling practices. Remember that Moxie's target audience is everyone, not just technical users. I elaborate on this point in a couple of my other comments in the sub-threads.
> Google is a known collaborator with three letter agencies...
People say this. I contrast it with the fact that Google now configures its US datacenters (and the links between them) as if they were sited in hostile nations such as China. Switching from the "friendly nation" configuration to the "hostile nation" configuration was a crash project after the Snowden revelations. The project was not cheap. The situation on the ground is -always- more nuanced than can be expressed in a soundbite.
> It's grossly unacceptable for security related software to require Google Play Services (spyware) on the end user's phone.
* Can you point to a reliable, credible source that has analysed Google Play Services and determined that they are spyware, by any reasonable definition?
* As I mentioned in other comments in this thread, Moxie is not opposed to either distribution in non-Google App Stores, nor is he opposed to replacing the use of GCM (AFAIK, the only part of GPS that Signal uses) with Websockets. However, any replacement must be at least as secure and functional as what it replaces. Check my other comments in the subthreads for more information.
[0] And I may not be, it's goddamn late.
The SSL diagram indicates not Google's participation; it shows that NSA was wiretapping their datacenters without their knowledge. PRISM indicates Google collaboration, though.
But see, the presence of Google Play in your phone does not magically allow Google or NSA to listen to Signal conversations.
The easiest way for them to do this would be sending a fake update with a backdoor. This is way more intrusive, targeted and detectable than tapping cables or getting access to Google data.
I'm not sure how familiar you are with Google Play Services, but it's designed to do exactly this. It's what Google came up with when they got fed up with OEMs failing to distribute newer versions of their things to end users. It can silently install updates and has access to almost every permission on your phone, and cannot be removed.
Unless Google also deactivates signature verification for the originally-not-signed-by-Google app that it pushes to the target's phone, the design of both Android and the Android Market make this impossible. You can't silently update an app signed with one key with an app signed with a different key.
If -however- you're talking about Google installing software that snoops on the conversation between the Signal software and Signal servers, then -in that case- Google gets nothing that any other adversary that has access to at least one node between those two points gets... namely, undecryptable cyphertext.
If you're trying to make the stronger claim that Google inserts special code (that they don't include in AOSP) that they use to read the unencrypted data of interest from RAM and transmit to their servers, then I reply:
"All modern computers -including Apple devices- suffer from this class of problem. You have to trust everyone who wrote kernelspace code loaded into your system, the OS authors, the people who put the boards in your computer into their housing, and the folks who made the boards and chips to begin with. This is a hard problem. Frankly, Google's solution to this problem is just about the best consumer-level solution in the industry, and keeps getting better as time goes on."
Nothing changed really, except that we have one less bloat in the CM rom.
* It's not possible to use without a phone number. If you want to use it on a WiFi only device, you're out of luck.
* Which wouldn't be so bad, but there's no way to transfer between devices. You can't take an encrypted backup (on Android) and because you use their encryption keys, moving to another device means other Signal users get scary messages about not trusting you.
Minor problems & edge cases, sure - but still frustrating.
Read more here: https://fdroid.eutopia.cz/
> If we were going to rank our priorities, they would be in this order:
> 1) Make mass surveillance impossible.
> 2) Stop targeted attacks against crypto nerds.
As long as US Army is not using metadata to shoot people with hellfire missiles on American soil, Signal is good enough for general population.
If you want perfect protocol - work on Vuvuzela. But good luck porting traffic analysis resistant solution to mobile phones with their limited battery capacity.
Not American soil... but... NSA 'drone strikes based on mobile phone data'
http://www.independent.co.uk/news/world/politics/nsa-drone-s...
What do you know, general population of the world does not live on American soil.
I can't trust Moxie after he called Google, Microsoft and Apple having absolute control over people's good thing, and called people having control over their own devices "going back to the old broken desktop security model".
Can you trust someone like that? It all makes me think that Signal is some kind of honeypot.
...
Now, when you've suddenly realized that people:
1) will not stop using mobile phones
2) mobile phones are tracking devices
3) preventing mobiles from tracking you is well beyond skills of both average tech person and average joe
4) average person is not capable of keeping malware away from their machine
What do you propose? Can you do better than moxie? Or will you continue to spread FUD about best available tech?
When speaking about non-technical, generally-clueless-about-computers people? This is ABSOLUTELY the correct attitude to have. Being able to trick someone into installing softare that reports back everything you do on your computer by getting the user to Punch The Monkey is a BUG, not a feature. The screaming hellpit that is the state of PC security is very bad for the average computer user.
For technical users, systems (like Secure Boot, along with a chain of bootloader/kernel/userspace software verifiers [0]) that let you -say- securely attest that you trust an alternative source of software are really good, when implemented properly. They help prevent drive-by malware installation, as well as let you know when your machine has been tampered with. This is a GOOD property to have.
What about users who want to run their homebrew software (or even start to learn how to code), but don't want to be bothered with code signing key enrollment? On the one hand, I guess -in this world- they're left out in the cold, if they're not doing something in the browser. On the other hand, any programmer is going to quickly face challenges far greater than any non-pathologically-bad key enrollment mechanisms... if the would-be non-web-programmer never gets over this hurdle, it's very likely (in its absence) he would have been stopped by any of the other couple-hundred difficult things along the way.
[0] It's late, so some of these verifiers (particularly the userspace one) might not exist in any mainstream distro.
You are still exposed to Google/Apple, since it can easily combine your contact information with traffic information and with great deal of probability detect who was the recipient.
I still would take it over encrypted SMS, where this data is open to carriers and carriers are basically perma-owned by everyone.
1) Google can see Alice send message via Signal
2) Google can see Bob receive message via Signal
3) Google knows that Alice is in Bob's contacts, and Bob is in Alice's contacts
Those three pieces of data should be enough. I don't see why Google can't do time correlation of those messages. Both Alice's and Bob's contact lists are very finite. It might be not obvious for single message, but for series of messages (and people chat this way) it should be very obvious who is talking to whom.
* Time of Tx to Signal server
* Rough message length
* Time of Tx of message from Signal server to recipient (assuming that they were listening on that path, too)
Is my understanding incorrect? Can a passive adversary inspect the data from a TextSecure/Signal client and determine more (or just the above) information from the data sent from the TS client to the TS server?
If the passive adversary has enough listening posts, it's totally possible for them to be reasonably certain that they probably got all three, unless some sufficiently clever stuff is happening either at the WS servers, or in Google's servers.
Hmmm...
I wonder why they don't link the tweets?
Except:
(Feb 2013) "So that's where we are. I believe that the decision not to distribute prebuilt APKs achieves the following balance:
1) It does not encourage the average user to tick "allow 3rd party APKs" in Android settings.
2) It allows "power" users who can appropriately manage the risks to install TextSecure without Play by building from source.
The thesis essentially being, if you aren't able to build TextSecure from source, you probably aren't capable of managing the risks associated with 3rd party sources." [0]
and
(Jul 2013) "Hey @rickbarton , to my knowledge we have not forbidden anything. People have requested that we distribute official binary APKs outside of the Play Store, which we are currently choosing not to do for several reasons (#127, #281). If we can address those issues we would be happy to distribute binary APKs.
However, this does not "forbid" anyone else from doing whatever they please. ..." [1]
Other things:
* The author neither links to nor provides screenshots of, nor quotes from the Twitter comments that he references. This is a bit of a red flag.
* The author asserts that "Moxie is not open to arguments and wants TextSecure to be distributed only via Google Play. He already locked this discussion.", which is plainly not true. If it was true, Issue #127 would be closed, and Moxie would not have made the comment that he did on issue #281. [2] It's also notable that the discussion lock didn't happen until 2015-01-09... a year and a half after the requirements for official distribution outside of Google Play were laid out in the comment attached to issue #281.
The fellow running the Eutopia.cz F-Droid repo clearly has an axe to grind, and is either unable to, or in too much of a hurry to understand the actual situation on the ground. When dealing with security software, you really, really want skilled, careful, meticulous people to be in charge of design, implementation, and packaging. This guy doesn't seem to be such a person.
[0] https://github.com/WhisperSystems/Signal-Android/issues/127#...
[1] https://github.com/WhisperSystems/Signal-Android/issues/282#...
[2] https://github.com/WhisperSystems/Signal-Android/issues/281#...
The decision to not allow exporting the key mitigates certain kind of attacks. I think the wording of the warning is appropriate and not that scary.
- Doesn't need access to Google Play
- Won't need Google Cloud Messaging (websockets instead)
I would really like these features to be supported in the official client. I don't understand why moxie doesn't reckon that these are legitimate concerns. Leaking metadata can be dangerous.
[1] https://fdroid.eutopia.cz/
> Leaking metadata can be dangerous.
You should
* Read about how Signal's crypto works
* Remember that anyone can stand up a Signal server, and build a custom Signal client that will associate with the server that you stood up, rather than the official Signal servers.
But AFAIK moxie has some reservations about making it available via f-droid too.
If you didn't, please go back and read them, and the first ten or so comments of each bug I link to. The "reservations" about F-Droid have to do with its unsuitability for securely distributing software, and have nothing to do with a desire to prevent distribution of Signal through non-Google App Stores.
And while I understand moxie's concerns about fdroid, and I would like fdroid to fix these, I'm not sure if he is making the correct compromise. Getting access to Google Play throughout the regular route implies getting closed stuff from Google into your phone...
IIRC, getting access to software through the F-Droid marketplace explicitly required (at the time the big discussion was made (~3 years ago)) users to expose themselves to the risk that a compromise of F-Droid's online signing key (that -IIRC- wasn't even contained in an HSM(!)) would open them up to silent replacement of any and all software installed through F-Droid by the attacker. Note that "the attacker" could also be "anyone associated with F-Droid".
Despite what one might think about their for-profit datamining, Google has a really good track record with regards to the nitty-gritty of computer security.
When Moxie looked at what F-Droid provided, it was entirely inadequate to securely distribute software to TextSecure's target audience. Because TS/Signal is not currently officially distributed on the F-Droid market, I have to assume that it still cannot provide what is required to securely distribute Signal.
And, to top it all off, the F-Droid folks are so lazy that they write things like this:
"The latest version of the application is 0.6.2, and the security flaw has now been fixed. However, the author has not published any source code corresponding to the binary he released of this version, and far from wishing to help anyone stuck with his previous disastrous mistake, he actually asked for the application to be removed from our repository as he wants to distribute it via Google Play only." [0]
TS's source has been distributed via GitHub for ages. The version that the F-Droid guy says didn't have publicly available source at the time of his post appears to have been published for two weeks prior to his post. [1] If the guy who wrote that blog post is still in a position of responsibility at F-Droid, I don't trust the organization to pay sufficiently close attention to detail to package any security-critical software.
[0] https://f-droid.org/posts/security-notice-textsecure/
[1] https://github.com/WhisperSystems/Signal-Android/commit/f666... [2]
[2] And the initial import date on the GH repo jives with the date on the notice that TS had been released as OSS. [3]
[3] https://web.archive.org/web/20111225144326/http://www.whispe...
You can use it on a WiFi only device. I currently have signal installed on a brand new iPod touch 6th Gen.
Its a device for using Signal messaging and phone calls only.
On a separate smart-phone, I entered the phone number, registered, waited for the phone call and then entered the verification code in the app.
I applied as much hardening as possible to the iPod and tether it either to my regular phone via WiFi or via a dedicated 4G modem i also have.
Easy and significantly safer (i think) as it mitigates base-band attack issues.
If you buy a temporary SIM, and that number is recycled, a new user can register it with Signal.
If that's the case, then you can register it to Signal on an iPod and not have to worry about base-band attacks on iPhone/Android devices. That's the point.