• state of the art crypto
• open source
• free as in beer
• Available for Android and iOS
• no decentralization
• use of the phone number
* Nice modern UI
* Integrates with SMS
* Supports group chats
* Uses MMS for group chat if not all members have Signal
* Not really buggy or hard to use
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.
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.
Apple offer a similar tool when leaving iOS https://selfsolve.apple.com/deregister-imessage
Please consider my suggestions here.
I would argue that an identifier is just that: an identifier. It does not need to be a number nor does it have to be for an indefinite amount of time.
Lastly, please consider disabling the debug log by default
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)
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.
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.
This fantastic post from Mike Hearn, who was on the GMail spam
team and now makes P2P decentarlized stuff, explains it all:
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.
When I arrive home a few hours later, my phone blows up with a bunch of missed messages.
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.
TextSecure also uses the FLAG_SECURE window flag by setting, so NoT among other things is blocked.
the client WAS. the server i don't think was ever.
I'm completely baffled that the Textsecure people insist on using the gapps package, which is of course an extreme privacy risk.
Conversations uses XMPP, not whatever custom stuff WhisperSystems worked up for Signal. Are you talking about OMEMO? That's their implementation of Axolotl over XMPP. So same crypto, yes, but different protocol.
The things I don't like about Signal / Textsecure are:
- Requires Google / Apple services
- No easy way to self host
- Accounts bound to a phone number
- No desktop client ("Being worked on" for months now...)
All these things can be solved for me by using XMPP with Conversations on Android.
So maybe the right thing to do is to stop complaining. Signal / Textsecure is just meant for other people than me.
If the app runs in an android version < 4.1, logs are readable by any application.
- 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.
Both are FOSS projects.
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/
SMSSecure is an acceptable alternative (for text messages), available on F-Droid.
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).
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" ;)
compile the APK and see if it matches
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?
We aimed to put adblock/ublock/donottrack all in one extension and coupled it with vpn and proxy paid services.
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.
* 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.
Access to the microphone is sort of justified for a voice app, quite a bit of the others are needed for "full featured" messaging.
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.
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...
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?".
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.
An open-source replacement of Google services. You can use Signal with this.
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.
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.
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!
> 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?).
Only real problems I see are hosting costs and preventing misuse, plus some minor coding work.
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.
Doesn't Signal require my phone number? Isn't it dependent on the Whisper servers? Why isn't it a walled garden then?
Because the client and server are both OSS?
Did anybody try to run his own server? Can such setup really work?
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.
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?
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).
1. Web client. (I send most of my texts from my laptop, which means I use Hangouts)
2. Search messages on the client.
Thanks for a great product and keep up the good work.
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?
Something that's still OSS and cares about UX (like Signal on iOS) would be fantastic.
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.
Another study on a different client, but same thing: http://www.scmagazineuk.com/modern-pgp-is-unusable-according...
"I'm trying to get signal on my phone" or "I'm trying to get Signal on my phone". Great(!)
The name was changed after Whisper was launched https://whisper.sh/
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.
No, moxie's previous company (Whisper Systems) was acquired by Twitter (iirc), Open Whisper Systems is a different project. See https://en.m.wikipedia.org/wiki/Open_Whisper_Systems and https://en.m.wikipedia.org/wiki/Whisper_Systems
Bosnian (Latin): signala
Yucatec Maya: señal
Querétaro Otomi: señal
Serbian (Latin): signal
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.
* Signal for the security piece.
* Ricochet.im for the Tor (optional?) and anonymous endpoint
* Burner for the idea that we can have lots of throwaway identities (if so desired).
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?
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.
In the cheesy TV show from the 60s, Batman and the police commissioner had literal red phones that they used to talk to each other.
That's way better than forcing me to rely on a specific Google server and protocol, which further requires proprietary software on the client.
(I'm stuck on Android 5.1 (not 5.1.1) on a Verizon phone. I was thinking of the ongoing Stagefright problems.)
There seem to be concerns about the security of it.
This is what I have been waiting for.
It would probably make more sense to define something similar to ZRTP that does all signalling in-band through the audio channel.
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.