Huge respect for Moxie, but the requirement of a phone number really is a dealkiller.
1. Phone number requires a service provider
2. Service provider owns the baseband and root of your phone.
3. $government makes a "lawful request" of Verizon et. al.
to install keyloggers/screenshotters on your phone.
4. Your "secure" commms are compromised.
Signal needs to work on comprehensively rooted devices connected only via wifi for the above threat model to go away.
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.
It's not that we don't find #2 laudable, but optimizing for #1 takes precedence when we're making decisions. It's totally possible for you to install Signal on an iPod touch with a VoIP number, for instance, but that takes more effort than the common case we're designing for.
Any chance of not requiring access to the whole contact list? I think there are pickers that allow selecting one contact - or better yet, one could allow adding contacts inside Signal.
Probably not because they check that against the list of people who have Signal installed so they can send encrypted messages to the people who support it. They talk more about how they try to do this privately in [0].
I had a problem where one of my contracts uninstalled Textsecure, and went back to the vanilla SMS app. Now all the messages he received from me are garbled. Somehow they need a way to disassociate phones AFTER the app has been uninstalled.
which is silly. that should be fine for people already advertising their contact list for facebook, wasapp, etc. but there should have been a isolated account setup for people not doing so
Plus it still leaves people open to metadata analysis. The phone number has to be verified, meaning a text message is sent from Signal HQ to your device, clearly marking you as a Signal user.
I'd say only being available on Google Play is an even greater dealkiller. Telegram (which is, to be honest, not quite comparable) is on F-droid, that I like.
> 2. Service provider owns the baseband and root of your phone.
My service provider doesn't own my baseband. They own the SIM I put in my phone, and that likely gives them a lot of access to my device, but I doubt it can be used to perform key or screen logging. (Nexus 4, bought SIM free)
I disagree that a phone number is required. You don't have one here, nor on Facebook should you use that. Identity doesn't need to be tied to a phone number and arguably .. shouldn't be.
How is centrali[zs]ation important? Mail works transparently and you don't know a thing about the stack behind a random address, right?
I'd side with the GP: The 'one server, ours' and 'your phone number is your identity' limitations are what I'd like to see go away. Prioritizing the 'no phone number' over 'hosting my own server', as far as I'm concerned.
>use of the phone number is necessary to make it not shit
Why? People who actually care about encrypted communication the most will just see it as unnecessary leakage of private data.
One of the best things about internet based communication is that we don't have to rely on traditional concepts like phones and phone numbers.
I should be able to sign up and chat with anyone on any internet capable device, phone or no phone.
Essentially, every large provider (e.g. Facebook, GMail) of network services
ultimately uses phone numbers now as a common thing that can't be infinitely
reproduced. They underpin all high quality antispam on large Internet systems.
This is why I chose to switch to SMSSecure. I've encountered a "bug" where I can be autoconnected to a known wi-fi (at say the library or a coffee shop) that requires authentication. Since my phone sees me as connected to wi-fi, it tries to send my messages via that channel instead of 4G data. Since I haven't authenticated to the wifi (phone never left my pocket), I don't receive any messages.
When I arrive home a few hours later, my phone blows up with a bunch of missed messages.
For me, the big thing that will make signal usable as a chat system is multi-device access. I'm at a computer most of the time, and much rather use my keyboard. Hell I would even hack the iOS client and make it an OSX client once they have multidevice support baked in. The ability to seamlessly move between my phone, tablet & computer is vital, so I use iMessage.
Whisper is working on a chrome version, so I am excited for the eventual multi-device.
Then to make money, maybe Whisper can make Signal: The Slack Edition and sell it for $4/month/user. They will host your WhisperSlack servers, but with client side encryption, never know it's contents! Even with compliance exports.
They do plan to use other identifiers than the phone number but I don't know how high a priority it is. My knowledge about this is probably a year old.
I wonder if they opt-out of Google Now on Tap. Google has made its spying the default on Android 6.0, and developers have to know to opt-out of it, otherwise private Signal communications could be collected by Google.
Wow, tough room! So much negativity. Whisper Systems, thanks for making encryption simple enough that my Mom can use it, and open enough that I can trust it. That is the success story here.
That's not really how the world works though. People have de facto ownership over projects. A lot of the features are things which the project have repeatedly rejected. Very few people are going to spend time on things they believe are futile. The technology isn't the problem here, it's the leadership of the project.
TextSecure used to be on fDroid, then this happened https://f-droid.org/posts/security-notice-textsecure/. Now it's a GPlay exclusive. I don't have GAPPS so now I can't get it. I'd assume many privacy conscious people don't have GAPPS. I understand the technical hurtles, but it's too big a pill to swallow.
Conversations uses XMPP, not whatever custom stuff WhisperSystems worked up for Signal. Are you talking about OMEMO[0]? That's their implementation of Axolotl over XMPP. So same crypto, yes, but different protocol.
Thanks for this! Seems to cover most of my bases. Secure, on F-Droid and gappsless. Here's hoping for a mainstream XMPP resurgence. Not holding my breath though. I had played with Jitsi before too, have to see how these compare.
I can understand somebody deciding to focus on the users with Google Play Services, but I find very hard to trust a 'Secure' application which writes sensitive in the logs.
If the app runs in an android version < 4.1, logs are readable by any application.
Assuming that by "GAPPS" you mean the Google Play Store etc., my strategy has been as follows:
- copy all data to a computer
- wipe the phone
- set up a google account with bogus information
- install all the apps i might ever want to use
- delete the account info and remove google stuff
- copy personal data back onto the phone
This is a big hassle, so I only do it once a year or so, but it seems to work ok.
Of course I have no way of verifying that the phone actually deletes my data when I tell it to, or that it actually deletes the Google stuff when I tell it to, or really much of anything about what it is doing or who it is talking to, so I still don't trust it - but I mistrust it slightly less, I suppose, than I would if the google apps were running.
You might be interested in Racoon[1], which is a desktop client (Java) for downloading apps from the Play Store, or into BlankStore [2][3], which is an alternative mobile client.
This is a fork of TextSecure/Signal which drops the dependency on GCM and uses WebSockets instead (it seems quite up-to-date with origin as well).
For anyone wanting a pre-build copy, there is a non-official F-Droid repository hosting both the "main" Signal and the WebSocket fork here: https://fdroid.eutopia.cz/
I'm pretty sure it requires gapps, although I did see a websockets version so not 100%. Also, keeping your own builds up to date is possible, but a hassle. For anyone else doing that https://f-droid.org/repository/browse/?fdid=fr.kwiatkowski.A... is an easy way to ensure your apks are up to date without a repo store.
This event spooked me forever against Textsecure. I've seen moxie's reasoning for moving to Gapps, but I don't know if I (or the the unix world) agree with it. If I had a gun pointed at my head, this tactic (making an insane choice that boils down to "it's encrypted. what could possibly go wrong?") would be my canary of choice. I'd probably mix in some Lennart Poettering, "it's the future, get on board," to make it extra-obvious, though.
One of the reasons I didn't install WhatsApp is the sheer quantity of permissions it wants (on Android).
Yes, I realise that this is part of Android's broken security model.
But the Signal app also wants access to practically everything. Device & App History, Identity, Calendar, Contact, Location, SMS, Phone, Photos/Media/Files, Camera, Microphone, WiFi Connection info and Device ID and call info.
Call me paranoid, but making an app with all those permissions seems kind of the obvious place for backdoors and similar.
If there was a 'light' version of the app which only required access the internet, then I'd be much more likely to install and use it. (And maybe if I ended up trusting it, then later install add-ons / the full version later).
I'm not associated with Signal or Moxie (though I've been a silent fanboy for ~15 years-- [[hey Moxie if you're reading this and still are hiring, ping me - contact info is in my profile]]), but I'd inherently trust the application more than an average application or company because:
a) Moxie has a track history of having a lot of personal integrity with regards to security. Some might say this is blasphemous but I'd put him up there with Bruce Schieder.
b) The whole source is available on GitHub, compile the APK and see if it matches.
c) it's incredibly easy to take an apk and disassemble it, to see if there are backdoors to begin with if you are really that cynical.
Don't get me wrong, I'm a tinfoil hatter. I use GPG, run my own MTA for anything even remotely important, use DDG over Google, donate to the EFF and use their HTTPS Everywhere plugin, have all of the Ad-Opt outs enabled that Google/Doubleclick/etc make available but try to obscure, etc. I'd be willing to bet that Google is collecting way more information than Signal is.
But hey, that's why rev-eng is so important. A wiser man than me once said "Don't turn it on, take it apart" ;)
Last I looked, no, but the immediate cause of nondeterminism I saw was the zip entry timestamps in the apk. I didn't bother looking further down the chain.
> I'd be willing to bet that Google is collecting way more information than Signal is.
I don't understand this sentences. It's quite obvious that Google is collecting way more information than Signal and almost anyone else. I'm curious, what did you mean?
I suppose he refers to information collected with the Signal app alone. The thing is that all information that is sent via Google is encrypted, so it's not of much use. I only wonder how the connection between two clients is setup, and if Google gets to know which Google user talks to which other Google user.
In terms of privacy tools, I work for a company that makes one aimed for the general internet user (i.e. someone who doesn't know what DNS is). Do you have any comments on our extension? https://redmorph.com
We aimed to put adblock/ublock/donottrack all in one extension and coupled it with vpn and proxy paid services.
This issue is intrinsic to the security model of Android before Marshmallow.
If an app is going to be able to send a contact, share a location, make a phone call ... all these permissions need to be demanded upfront, which I understand can be scary.
You also need to keep in mind that nobody is going to use "secure messaging" if it's a pain to use. You obviously don't want to be copy pasting contact information in the app for instance.
I'm glad to see that Android is following iOS's permission model where permissions are only asked at run time.
It's exactly why marshmallow is changing the permissions model. All of those permissions are necessary if you want an app that:
* can show a contact's name on a message they sent you
* can save public keys and access them
* can send/receive messages with multimedia
* can uniquely identify your device and you as a user (to generate your private key with unique primitives)
Off the top of my head iIdon't know why it asks for calendar permission, but we could inspect the source...
The point is, if you're trying to make a mass market app, you have to offer competitive features... And that requires a lot of permissions.
No idea about device history. Identity to know your number. Contacts for contact discovery (using a privacy protecting protocol). Location for location sharing. SMS because you can send SMS with it. Phone because it can call from it. Media and camera because you can share media. Microphone for calls. WiFi connection for a bit more stable connectivity. Etc...
In Android Marshmallow you can deny / disable any of those permissions. And apps compatible with API Level 23 won't ask for those permissions from the start.
>Yes, I realise that this is part of Android's broken security model.
Well, with Marshmallow, they have no excuse. The permission model is now very similar to iOS's one and any app can start with 0 critical permissions (basically anything related to personal info) and ask the permissions at runtime.
For either Android or iOS, you still have to trust that an app won't abuse the permissions you give it though.
This is great news, and thanks to everyone involved. I've been using TextSecure for a while, and it's really "pretty good security made easy". Yes it is not perfect for the super privacy-conscious (depends on Google Play services and all that) and a fork with these features might be useful, but if I understand the motivation correctly, the main goal is to make good crypto accessible to the masses.
I do have a personal gripe with that, though. I'm hoping a "high up" might read it so I am posting it here. The only people in my contact list who use the app are crypto nerds. It's really hard to get traction. I thought that the TextSecure people had a great idea to solve this chicken and egg problem; a unified messaging app that would handle your sms, and send secure messages wherever possible. One feature that I find is missing though, is the ability to semd broadcast (unencrypted) sms texts. In my experience (Europe, people around 30) this is used a lot, and a drop-in replacement for the built-in messenger would need to have this.
Actually, I would like to see this happen so much that I would be willing to do the work, if someone is willing to provide the handholding...
Guys, cut with the negativity. I'm a crypto nerd as well, and with my other truly paranoid friends we use Chatsecure which does not require your number, is compatible with Tor, etc. However, my mom uses Signal, my father yesterday called me via Signal and he's fuckin' 67 years old. That is truly amazing and I admire Moxie et.al for the work they do.
Do you seem to forget that it is encryption for the masses. Not only for the few tin foils like myself. And even if it uses GCM, it's still an great, since i could never persuade my non-paranoid friends to contact me only via Chatsecure. They would say - "why the fuck can't you be like a normal person and use whatsapp or fb messenger?".
I really want to start using TextSecure (or Signal now I guess), but the only thing holding me back is it depends on Google Play Services. I love what they're doing and can understand the decision, but still thinks it sucks a bit that the best option for secure communications is so tied into Google.
It seems like you don't want to install Google Play Services on your device. My sense is that this isn't because you find the communication over GCM to be inherently offensive (it's just a tickle, after all), but because you don't want to run proprietary software.
There's a very small number of people who find this to be very important, and my experience has been that the strategy is to loudly complain whenever anything depends on play services. Just tactically speaking, I don't think this is going to work in the end, in the same sense that simply refusing to have a mobile phone won't work anymore -- slowly, the circumstances around this technology will make it impossible to refuse.
What I don't understand is why nobody just writes an API-compatible open source implementation of play services. Even if it only supported GCM and nothing else, that'd unlock an enormous swath of apps, and would only require writing a basic implementation of the GCM network protocol.
I'd love to know more if I'm misunderstanding the challenges around doing that. Right now it's part of the reason that I don't pay much attention to that crowd -- everyone seems very willing to complain, but nobody seems willing to do what seems like pretty straightforward work to solve their own problem.
Has been working reasonably well for ~10 days now. Note that I'm on Android 4.2, so I might have missed something with regard to newer Android versions.
just debunking the bogus "you are a nerd that has a pet peeve against google services". this affect lots of users overseas or in poorer markets than san francisco.
amazon phones don't ship with google service. cheap samsung models (most dual sim ones) sold overseas don't ship with it either. the cheap chinese phones don't have any google service. ...and those are only the ones i saw. i'm sure india/africa/europe have even more cases.
Close, it's less about propriety software and more about centralisation of services. I definitely tend towards open-source but it's not a dealbreaker, I just don't want to live in a world where my life is completely tied to Google. As good as a lot of their apps are, I hate the idea of the "ecosystem" that these companies are building.
I just want a messaging app that messages and doesn't imply a bunch of other services from another company. I'm aware that's easier said than done, I just hope the end-game of instant messaging isn't "Apple or Google?". To continue your comparison with mobile phones, you can have a SIM from any network and still communicate with people.
I'm going to try GcmCore that's been posted in this thread, it sounds interesting.
To be completely honest, it's not a die-hard opinion and will no doubt change a bit in the future. Technology is progressing and changing so fast, I don't want to go with the flow without questioning directions it's going in.
I know this is a niche choice, I don't expect anybody to cater to it specifically, I'm just happier putting together smaller apps that do what I want instead of installing an entire ecosystem. Hope that all makes sense.
EDIT: Just realised after pressing send that the difference in my mobile phone analogy is the customer obviously pays to use it, maybe I'd be happier with paying for the network, I don't know. Doubt there's a market for that though!
I'm not an Android developer so I hope my mental picture of what GCM does isn't off.
> My sense is that this isn't because you find the communication over GCM to be inherently offensive (it's just a tickle, after all),
Using GCM still means that Google could suddenly stop to relay the messages for some users, right? (Say, those who seem to be using a non-official reimplementation of GCM...). Then the service would suddenly stop working for these users. So I'd still rather be able to avoid relying on the GCM backend at all, if that's possible.
> What I don't understand is why nobody just writes an API-compatible open source implementation of play services
Couldn't the Play Services API change without warning? It is sensibly designed so another implementation wouldn't be too hackish?
People shouldn't have to reimplement such things by mimicking Google's API. In principle, there should be a documented and stable standard, not hacky reimplementations.
I agree, though, that probably the way to go would be to first build a different messaging system like this (maybe using XMPP as a backend?).
It's mostly because there aren't any real alternatives. Building a world wide push messaging network is really hard (you have to deal with carriers a lot and convince them not to close your long running connections after 5 minutes). That said, the servers support websocket connections as well. I don't know the current state of client support. Also, a Chrome/Chromium extension is in the works.
Making push notifications work well is hard, so it's better to just use what's available. There are alternatives, but the alternatives aren't free at all. See: https://pushy.me/
See here for a version that uses websockets instead of Google services. It's usable on Blackberry OS 10 so should be usable on other non-google devices.
it does require to have the google play services installed in the first place. so for those who i.e. run cyanogenmod without the google play services installed, it's unfortunately not possible to use Signal/TextSecure.
It sends messages through Google's messaging framework. Of course the messages are end to end encrypted, so there's no security risk. It's just really hard to set up a global push messaging framework unless you have the clout of, say, Google.
I believe it doesn't actually send the message content through GCM anymore, but just notifies the client that a new message is available and tells it to connect to Open Whisper Systems' server for the content.
Great! I've been using Signal for iOS and while it's not yet comparable to WhatsApp feature-wise, it's for sure good enough to use.
I find it very difficult to get people to switch from the walled gardens of iOS messaging and WhatsApp (WhatsApp dominates the Dutch market for interesting historical reasons). I've been able to get a handful of privacy conscious friends to switch to Signal/TextSecure, hopefully the cross-platform branding makes this a bit easier.
You can run your own server, but there's no federation.
The reason for that I imagine is that they want a privacy preserving automatic lookup method (a single server can confirm phone numbers and allow privacy preserving contact list comparisons for its own clients), and aren't convinced of using a model where the public key is the identifier instead of your phone number.
Have you actually tried it, or do you know somebody who have tried? Is the client really fully independent on Whisper servers? Can it work without the mobile connection, just with WiFi?
Does the voice communication work?
I'm asking all this because it seems that the server code was earlier in "you can look but it's not enough to run it" state?
I've run the server source as a private textsecure chat app. You can run your own without the proprietary gapps framework app too by mimicking what GCM does on your own back end, and it works with wifi if you change the identifiers to email/nicks instead of phone numbers, but this was for a small number of coworkers nothing of massive scale. This was for business communication from China since at that time TS wasn't working very well behind the GFC but they added another server around that time (I assume, all connections got better) so we abandoned our hacked fork for regular TS/Signal.
I have read of people on the mailing list who appear to have the server running.
There used to be some documentation about running it, but it was removed from the repo (presumably because they didn't want to dedicate resources to supporting it, but that's just a guess).
Why is a browser extension needed in this case? Does not the browser expose a source of randomness that would be enough to write the rest of the crypto in JS and use that?
> That's excellent. Installing and using GPG (or GPGTools or GPG Keychain or whatever it's name is) on OS X is awful.
I don't understand what's so difficult here. The biggest problem is understanding how PGP works, and having to type a password now and then. I use it all the time, to sign - not encrypt - my mail.
Finding the app (not the source code), finding out what three names mean (as already discussed), finding which app to launch, realising it only works with Apple Mail and the shell are all parts of the current experience.
As was mentioned on another HN thread, why the ridiculous name? "Signal" is an already widely used term when talking about mobile communications. With cell phones in particular.
"I'm trying to get signal on my phone" or "I'm trying to get Signal on my phone". Great(!)
Naming conflicts are a major problem - legal trademark implications, branding issues, searchability, etc etc. A name collision with someone, especially in a remotely similar industry, is problematic.
IronChatApp.com is available. ("Steel"|"Lock"|"Forti"|<anything that conveys security>) + ("Chat"|"Talk"|...).
I'm not sure, there are tons of professional marketing/branding/PR firms who do this really well. TextSecure et al were acquired, IIRC. If the parent company has 50k to throw around, approaching W+K might be a good investment.
Edit: Mea culpa. It was WhisperSystems not OpenWhisperSystems which was acquired, both of which were founded by Marlinspike. This, incidentally, proves my point that naming similarities (WS vs OpenWS) within a similar domain (both mentally associated as "moxie" projects in my mind, in this case) can lead to problems.
That the literal translations of the word 'signal'. At least in Germany that is not used for talking about a phone signal. It's 'empfang' (reception) instead. I am sure other languages differ as well?
What happened to short authentication strings? The SAS protocol is nicely documented in the Silent Circle Instant Messaging Protocol paper [1], but when I go to "Verify identity" in the app I'm asked to verify an obnoxiously long pair of hexadecimal strings.
The phone call feature supports it (with a curious lack of documentation), but it would be easy to imagine a UI that allowed verification without making a phone call and without allowing users to screw it up: one phone shows the SAS string, the other phone asks you to type it in, and neither phone allows IMs to be sent while doing this.
Supporting android 2.3 is the equivalent of supporting Windows XP at this point. Why do it? Those Android 2.3 devices will be vulnerable as hell anyway, and I imagine it just makes it hard to support them, too, taking precious time from working on new features or cryptography. IMO, you should support only Android 4.1+ and up.
Also, I'm confused as to why Signal still asks to be my "default SMS app" when I thought the code to encrypt SMS texts was removed from TextSecure? Why would I still want my SMS's handled by Signal?
Because you want to store them on your phone encrypted, so that no one else can read them without knowing your passphrase?
Sure, the fact they're transmitted to your carrier in a 100% readable form removes most of the benefit of this, but it can still stop prying eyes from reading your texts.
Also, it's trying to be like iMessage. You have a single messenger, where you default to unsecure SMS for those contacts that don't have Signal, but default to secure messaging for those that do, all in the one app without you having to think about it.
I'm glad it's not called RedPhone for Android users, they may get it confused with YouRed I mean YouTubeRed I mean RedTube or whatever it's called now. In all seriousness though - what was (is) with the trend of apps with Red in the name? Red to me gives the idea of danger or something that's stopped / blocked.
Ah! That's quite interesting and now that you say it I of course remember seeing red phones in films in such situations. Thank you for taking he time to reply.
It uses Google Cloud Messaging. There needs to be a server in between and I believe GCM is free. Consider a situation where Bobs phone is switched off. Alice sends a message and turns off their phone. Now, Bob turns in their phone. How do we get the message Alice sent to Bob?
Give me some open source code that I can run on my own server to manage the notifications for me and for my friends, and allow me to tell the client app on my phone to use it.
That's way better than forcing me to rely on a specific Google server and protocol, which further requires proprietary software on the client.
In addition to what @newjersey said, you also need to handle push notifications, which in the context of a mobile phone aren't cheap at all. This is because you need infrastructure and because keeping connections open drains your battery and making it work well is wasted developer effort. This is why it is better to use whatever is available, like GCM on Android, APNS on iOS, or maybe Pushy (see pushy.me) or whatever Amazon does if you want distribution on alternative stores.
I just updated, after which I checked the settings. I noticed that auto-downloading in MMS text messages was enabled (moxie stated for a prior version that it was not, at that time), whereupon I changed the settings to disable. I may well be misinterpreting what I was seeing, but better safe than sorry.
(I'm stuck on Android 5.1 (not 5.1.1) on a Verizon phone. I was thinking of the ongoing Stagefright problems.)
Unfortunately when I used Redphone previously the call quality is pretty bad. The volume of the call would get screwed up and I know it's not to do with the signals (lol) because I would hang up and call the person back without redphone and it would work perfectly.
Redphone and Signal are all backdoor applications with bugs and exploits that i have found. Even the server is backdoor. Nobody in the security scene could use this, except a kid.
Seems like the persistence for automatic VoIP authentication confirmation is currently disabled. Meaning you need to confirm our again each time. But have they confirmed this is in the release, not just in a development branch?
They have been encouraging people to read the two words on the screen on the start of every conversation forever, so I'm not really worried. Hopefully it will get back in, though.
ZRTP/S is an extension to ZRTP protocol. It is designed to make ZRTP-secured calls work across Circuit Switched communication channels such as the traditional telephony networks (GSM, CDMA, PSTN, ISDN, etc) where internet protocol is not available.
On these telecommunication technologies peers can have a sort of “serial connection” through which they send and receive raw digital data.
The communication channel is so narrowband (9.6kbit/s) that it is not possible to run IP (internet protocol over IP) over it.
So, PrivateWave and Philip Zimmermann jointly designed and implemented ZRTP/S. It is a transport and security protocol for Voice over Circuit Switched channel, carefully adapted to be extremely narrowband and minimalistic.
After a year of researching and development, PrivateWave created a library, libzrtps. The library allowed PrivateWave to release the 1st version of PrivateGSM product - PrivateGSM CSD. It allows users to communicate securely in a point-to-point fashion with the ZRTP end-to-end encryption protocol and with a bandwidth as small as 5400bit/s.
Full specification of ZRTP/S and Source Code will be soon published. Anyone willing to create his own project, improve and eventually establish interoperability between Circuit Switched secure telephony (ZRTP/S over GSM) and Packet Switch secure telephony (ZRTP over IP) can benefit from the publications.
Interoperability represents one of the design goals of the ZRTP/S protocol.
Their android app description says they need an IP enabled network. GSM is not it. They may have it in their lab, but it's not in a real life useful product. Because it is not possible.
