We are also interested in a TextSecure implementation for the desktop!
Right now the protocol includes multi-device support, so the foundation is there for developing desktop and tablet apps that work seamlessly in conjunction with your phone. Our first desktop implementation is likely going to be a browser extension, feel free to jump in and get involved with that if you'd like.
How does multi-device implementation work (for the layman).
Are the messages only delivered to the 'logged in' clients? So if I am logged in on the desktop my message exchanges are also sent to the phone client? But any messages I send/receive from my phone while logged out of my desktop are synced through the server on login?
There are some links in the article. Granted you could've easily missed them since the color is some washed out grey. Moxie should consider making the links a more visible color.
Thanks. Now I tried to follow the links and I still don't understand how they managed to achieve that "The new TextSecure protocol doesn't require a round trip key exchange process."
I'd still like to know how actually their solution protects from MITM.
Fingerprint verification protects against MITM attacks. The application provides a nice interface where two users can scan a QR code to easily compare fingerprints. A hexadecimal fingerprint is also readily accessible.
Prekeys are prerecorded responses to connection initiation: in the alternative world with no prekeys this is what you'd get when you've opened a connection.
Okay, it seems the server is open source? And the protocol supports federation? Could I just run my own server and it will just work™ with users on a different server?
Are you basically presenting me with an option next to xmpp/otr?
When I looked at it (which is already a couple of months ago), federation wasn't “just works™”. A new server needed to be explicitly permitted into the federated network by WhisperSystems. Every server has a full copy of the list of clients and on which server they are and servers trust other severs completely when they claim “we serve the user with phone number 555-123456”.
Aww, that is a shame. I was imagining something like the XMPP server "cloud" where everyone can easily setup their own server, eg for a more private setup with their closer friends (who would then be motivated to use that server).
Not if you want it to be “SMS based”, by which I mean: use phone numbers as identifiers. A server can’t easily prove to another that it serves the user with a specific phone number. There’s no cryptographic proof possible, there’s no hostname part like in email. You can verify by sending a text message, but that gets expensive if you need to do it often.
This is trying to combine 3 points on Zooko's Triangle [1]: You want human-meaningful names (which phone numbers are, because they map to existing things), so you have to make a trade-off between decentralization and security. WhisperSystems opted for security for some reduced decentralization. For something that’s aiming to replace text messaging, I can’t really blame them for that choice.
It's a shame there isn't a standard means to associate keypairs with existing phone numbers in a way that doesn't involve establishing new trust. A <your_phone_number_here>.yourcarrier.com DNSSEC secured subdomain provided by your existing carrier that can be coupled with BrowserID perhaps. All you need is a cryptographic tie-in, right?
Hemlis is XMPP+GnuPG based, so (according to TextSecure developers - but most agree) bad for asynchronous communication (XMPP) and without perfect forward secrecy (GnuPG).
It is released and 100% open source, unlike Hemlis, which is still under development behind closed doors and will be opened "as much as possible" (which tells us nothing about implementations, code quality, privacy features, openness or license).
For starters, Hemlis is not open source. That should stop you in your track right there. If it doesn't, maybe the fact that they actually had to switch to another crypto system for Hemlis after much negative feedback from the community, should tell you more about their experience in this. But even that new one doesn't offer anything resembling forward secrecy. I think Hemlis will be more of a Threema clone, which also isn't open source.
Intercept legislation that applies to makers of non-interconnected (i.e., doesn't touch the PSTN) chat functions is extremely unlikely. I'm guessing whisper falls into that category.
I use Silent Circle myself, but I assume on Whisper you can't just type in a normal mobile number and have the chat message go to the right person. If you can, then those chats at least are subject to intercept, and maybe the other chats (whisper-whisper chats) are too. I don't remember how all those rules shake out/how courts have decided.
Upon compiling TextSecure from source and installing it on my phone (I don't have the play store), I've discovered it requires the Play Store to do the "iMessage" style messaging over data. I guess the encryption is still done on-phone before being sent through whatever data API, but I still wonder if that (the play store being installed) might enable key-sniffing? Perhaps that's somewhat negated by users having a strong passphrase though?
Yes it would make them susceptible...if, like Lavabit, they actually held private keys that secured your communications. They don't.
While I have the utmost admiration for Levison's stand, the fact that Lavabit held centralized private keys for its users was a very bad technical and security decision. Moxie has more about this here [1].
Now some may be wondering, what's to stop Whisper Systems from backdooring TextSecure by court order? In a word, this: [2]. The TextSecure client is open source. Not only can the community scan the source for something suspicious, but we can build and verify the binaries ourselves.
The fact that the app is open source is nice, but realistically speaking very few users will build their own copy from source over just downloading an existing binary from Google Play or the Apple App Store. Nothing (but garden variety trust in the source of the binaries) is stopping a situation where there is a clean open source version and then a version with a backdoor built into binaries submitted to the app stores.
And even if you are one of those paranoid users who builds from source, a backdoored central build could still impact you personally unless you're sure everyone you are messaging has also built their own from clean source.
Personally I wouldn't worry too much about this scenario playing out, but I don't see that the client being OSS really buys you much safety practically speaking.
This is true, but at least it lets a small group of people do the verification work and post in a public place if the publicly distributed binary stops matching up with the one built from source.
Yeah, but you have to trust that someone (who is really independent and not in on the backdoor) is actually doing that. Also, the fact that all binaries distributed through mobile stores have to be signed with a private key makes this a more difficult proposition with mobile software than it is with desktop software. (Unlike desktop EXEs you can't just hash the resulting binaries).
I supposed you could pull apart the container format (apk or ipa) and compare the .class files (Assuming Java, I haven't looked at this software so I don't know if it is standard Android or a lot of NDK stuff) or ObjC object files one by one to look for discrepancies versus a local build using the same tools... hopefully someone volunteers to do that and keeps doing it again on each new release.
It all comes down to the idea that if you the user have concerns with the app, you the user can take the approrpriate measures to verify, given enough time.
For iOS I believe that decrypting the binary and doing an objdump, then comparing the resulting assembly is a reasonable approach to ensuring that two builds do the same thing. Comparing objdump results won't protect against particularly insidious backdoors like those injected through data resources or binary headers, but in tandem with a source audit should give a fairly respectable degree of assurance.
> For iOS I believe that decrypting the binary and doing an objdump, then comparing the resulting assembly is a reasonable approach to ensuring that two builds do the same thing.
Not a chance.
And if someone is doing this, we are well past "particularly insidious".
You have to trust everyone who claims the binary is clean, yes. But the vendor must also trust all these conspirators! And they can't bribe everyone - it only takes one honest guy with a decompiler and it's game over.
This is not a case of "many eyes make all bugs shallow, so all OSS software is safe". This is a case of "many eyes will look at my covert code, can't take the risk of discovery". Debian SSL is not comparable because it was an accidental (if stupid) bug. We are talking about deliberate malice, not bugs (which are inevitable in open and closed code alike).
At the state actor level do you really think you will be able to distinguish a stupid bug and an intentional flaw? Its not like they will make it call home with a bunch of code, they would just use a class of attack not well known and you wouldn't be able to tell the difference. That's all it takes, one little hole.
I imagine certain organisations knew about buffer overflow bugs long before they were used publicly, so imagine if this was the 70's and you saw some strcpy calls peppered into some useful code, would you really be able to know 1) the class of attack exists and 2) if it was intentional or not?
Yeah, but that is always a threat with any code ever written by anybody other than oneself. The only assurance against that is if one writes their own code compiled with their own compiler and run on their own fabricated hardware. Oh, and implementing their own security algorithms. Which means any data exchange would be impossible.
I know that I have grabbed the apk's from Google Play before and then decompiled them to compare with the original sources. What I did was compile my own version, then decompile it again and compare those source with the decompiled original sources.
There were some differences where the compiler/decompiler made a different decision, and that had to be checked out manually but in the end it was a pretty nice experience.
But what is the alternative to open source for securing communications? From my perspective, you've just described problems with commercial app stores, the extra effort required to build from source, build reproducibility, and the effort required to audit software. NSA and their global colleagues aren't going to simply go away due to having their activities publicized for the nth time.
Well, there's not really any practical alternative. And I do think it being open source is much better than it being closed source, as long as people are aware that ultimately unless you build it yourself you can never be sure of the security inside (and even if you do build it yourself, you have to be sure there are no subtle bugs either intentionally or unintentionally introduced).
I think you're right that the scenario is unlikely to happen, and I think it is for this and related reasons an OSS client actually offers you a great deal of additional safety over a closed-source one:
1) It allows you to ensure that your personal copy doesn't contain code that does overtly malicious things, like backdoor your computer.
2) An open-source client may not be an automatic certificate of good faith, but a closed-source client is practically a certificate of bad faith/incompetence when your business is security. (indeed, this scenario is predicated on the vendor attempting to capitalize on that very fact - and even if successful, the base-rate probability is still massively in favor of OSS)
3) It is very difficult to hide malicious code in a binary for which the source is available for comparison. It is comparatively very easy to hide malicious code in a closed-source binary.
4) If there is cleanly-building source available, not only users but many vendors (including most Linux distros) will package their own version from that. Many people who don't build the source themselves will still get a clean version.
5) The risk of discovery would be high and the consequences, catastrophic. Sooner or later someone will compile your source, compare the result with your binary, and find something suspicious.
It is overwhelmingly unlikely that an attacker would opt for this strategy. OSS is much safer.
It would be really nice if WS moved to deterministic builds. Really helps with not everyone having to compile themselves (if somebody is checking the source).
Kind of-- some older code was (is?) copyright WS, newer code is OWS, in both cases everything is GPLv3 and all future code will continue to be OWS & GPLv3.
I'd really like to try their new app, but they only distribute it through Google Play. That excludes an awful lot of their potential users, especially those who most care about privacy.
You should build it yourself if you actually care about privacy. This is excellent practice, instead of encouraging you to trust some third-party website like their own.
"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."
Telling users without Google Play to "just build it yourself" is arrogant an unacceptable. I find Moxie's response to this criticism arrogant and condescending. This is a major reason why I'm not using TextSecure, even though I would like to be.
He gave sound reasons why building it yourself is currently the only secure distribution method outside the Play Store.
I didn't find his tone to be arrogant at all. You're conflating arrogance with correctness, and though many people on the internet use both simultaneously, they are two separate things.
Another good option would be submitting it to the F-Droid [1] repository of open source apps for those of us who prefer not having Google's proprietary pieces of software on our phones.
Could somebody explain why it was tied to SMS in the first place? And given that, why it's trying to undo its connection to SMS?
Separately, what's the difference between this and OTR? Is it just trying to just be a better OTR (and I support this endeavor, competing OTR connections over one chat channel creates a hassle). And as such, why is it only on Android, you could just as well write a Pidgin plugin right?
The chat is referring to the padlock icons on messages, which are closed.
The open padlock in the notification bar means that your passphrase is currently cached and anyone that picks up your phone can read your text secure messages. How frequently your phassphrase gets flushed and must be re-entered is a user setting.
I'm very excited to see this for iOS! I never really trusted iMessages but the most painful part of iMessages is the vendor lock-in. Now I don't have to worry about the type of device that my friends use.
Will there eventually be support for using your email address as your identifier instead of a telephone number?
In a world of IP connected devices, the need to tether your self to the telecom cartel for an identifier is outdated. It would be ideal if future versions of TextSecure let you log in with just your email and then you could run the app on your tablet, desktop or any other devices without a SIM.
Moxie, it's probably pointless to do it now, but right before or soon after Whisper is finished, you need to set-up some crowdsourcing of language localization for Whisper. Doesn't have to be anything complicated. Just arrange all the text nicely in a txt file and let people download it and then upload the file for a certain language.
I think localization could give a great boost to Whisper in countries where English isn't the native language or that well known, and it doesn't cost you much to do this. But as I said, it's probably best to just wait until Whisper is finished, if it's coming out this year.
Like all sensible crypto systems it doesn't matter if the server is compromised, encryption is done client-side. The project is open-source, so you can verify this for yourself.
Cyanogen runs one of the nodes. I'm not sure where Whisper Systems receives their funding from. At one point Twitter was involved with them, though I believe that is no longer the case.
This is probably the most optimistic thing in security in the past year. Thank you!
It's still tricky to get security due to the platforms on which software runs, but now users can make reasonable choices about which platforms to trust, and by not tying your messaging application to hardware with a black-box baseband, users actually have a decent chance.
Hopefully there will be more progress on baseband-less mobile devices and reasonable networks for those users.
Would kill for the desktop version of this. This team is the gold standard of cryptographically secured messaging; what Colin Percival's Tarsnap is for backup, Whisper is for communications.
Hopefully iOS and Desktop clients help TextSecure take off and beat out the weak crypto apps. Multi-platform is critical these days for messaging apps.
Is it? I just updated to Cyanogen 10.2.1 and TextSecure is definitely a different app from Messaging. Or is this an 11.x feature?
Edit: Oh, I see. Added as a silent feature in 10.2 messaging app. There is no visible indication that secure communication is happening (or possible). Ok. Better than nothing, and a good default.
CM really needs to change the onboarding process for TextSecure since I've never enabled it because I don't understand it.
Mainly that "seamless" migration between SMS and data channelled messaging is not something I want to happen because SMS costs me a fortune on my plan, whereas low-volume data costs me nothing.
To that end, the options for the TS process during setup should make it clearer how data charges/SMS charges will be racked up, and indicate accordingly.
Most users flocked to WhatsApp to avoid SMS charges. So, I think SMS push should've been off by default. Many users won't find out until it's too late.
Right but what I'm saying is: this is not indicated when it's presented to you. And worse, it's not clear how it interacts - i.e. does TextSecure send an SMS with a hash to find the real message, or does it check if both devices are online (I now know its the latter).
But there's no way to tell at the most important moment - when this new thing is being put in front of me, and claiming to do things with a service that has a usage charge to me.
It would be much better if SMS defaulted to off, it was made clear what it was, and SMS Push added as a "would you like to?" option instead.
Telegram's been around close to a year or so now. They are an established mainstream app and they look like an obvious "WhatsApp replacement" if one is looking for one. Far fewer people are looking for a secure IM app per se, so your numbers aren't really that surprising. Regrettably, unwashed gray masses don't give a flying f#ck about quality of the crypto, so TS doing crypto better is not a tangible conversion benefit.
i actually think the sign up process of textsecure is more obvious than telegrams.
but i found that use it to transparently send sms when needed super confusing to people.
people don't want to use sms. if they did they would just use that instead.
in cyanogenmod it's even more confusing. cyanogenmod integrated it to their base system, but you have no way of knowing if the text message you just sent is really encrypted or not (unless the other party tells you since he's running textsecure), i'm guessing/hoping that'll improve though
Telegram's website has got a great layout that encourages you to install right on the first page. TextSecure's looks like a badly designed startup pitch deck. While Telegram uses misleading language that takes advantage of normal people's cognitive heuristics, TextSecure has in-jokes about anarchists and socialist revolutionaries. They're completely out of touch with normal users.
> Now that the new TextSecure for Android is out, Christine and Fred assure us that TextSecure for iOS will be available in short order. The protocol includes support for users to have multiple devices, and Matt is working on a desktop client.
We've got a browser extension in development, with the possibility of using an email address instead of a phone # as ID-- no promises on time line though.
I had downloaded RedPhone and TextSecure. My contact list was a glorious zero people (everyone I know uses WhatsApp).
A few months ago I thought about using Threema and the like, but realized nobody's gonna switch with me. So I stayed. Didn't even try to convince anyone.
The day after FB bought WA my non-tech, not-concerned-about-NSA friends started to switch to Threema. On their own. Because Facebook.
Heck, they were even discussing all that on Facebook, as far as I know... that's irony.
So now most people I regularly chat with are on Threema.
And while I don't trust them (especially their competence -- although using NaCL is a good start) nearly as much as I trust Moxie, this issue is closed now. Nobody is going to move again without a very good reason.
The two people I regularly chat with still on WA can't use Threema, because they are still on Android 2.3.
But Threema really needs multi-device IDs. And the ability to change a group's composition. Other than that it's cool. You feel right at home, the emoticons look the same (from the same lib, I guess). And this whole "scan the other guy's public key" is not just a good idea, it's even close to gamification ("only two more people until everyone's green!").
And that's why I don't believe in some meaningful market share for Whispersystems. They are virtually unknown in non-tech circles. They still don't have an iOS app. Yes, I know, there were more important things up to now.
Still, the window of opportunity is closing. In three weeks no "normal" person is going to switch messaging service anymore. Everyone either stays at WhatsApp, or has already agreed with their whole circle of friends on another service.
Everyone I explain text secure to loves it and starts using it immediately. Its a dropin text message replacement app. It's main competition is android owners who can pick between text secure and the Hangouts app that had replaced the default SMS app.
Tend to agree. If it had've had an iOS version and a little broadcasting of what it is and does, it could have been in Telegrams or Threema's position now, post FB aka Borg acquisition.
It's going to be hard going to reflow the already interconnected with this. Wish it wasn't so.
I have been able to compile it myself, so I could install it on my tablet.
You can register an Account using any phone number.
Just wait until the SMS verification fails, you then have the option to request an automated call, and get a verification code that way.
The biggest weakness of this kind of app is it still exposes lots of interesting data for traffic analysis. It's a huge improvement over what we have today, but I'd really like something where you can't see who is talking with whom (when, how frequently, etc.), as well as can't read the content.
Unfortunately doing this with mobile is really hard, due to bandwidth and power. agl's Pond is probably the best effort in the space so far.
Damn. I wish this was native on the blackberry. I could emulate it, but SMS support wouldn't work - and I am not sure if emulating a secure system really is the way to go.
Why will anyone trust something based/developed in the USA related to security? It's a compromised jurisdiction. For anyone creating security products who wants to be credible will need to be based somewhere that respects privacy.
Every single US citizen is complicit? Man, I would hate to be this jaded. Some of us are fighting against mass surveillance as hard as we possibly can.
This is as silly as saying that all of the people who live in North Korea are brutal dictators.
That's not what xmr claimed; what was said is that the US is a compromised jurisdiction, and of course everyone developing something in the US is subject to that jurisdiction.
It was never implied in xmr's post that every US citizen supports mass surveillance, only that they may be legally forced to participate in it.
Even as an Android user, I'm anticipating the iPhone release as the idea of a cross-platform iMessage replacement (seamless SMS/IM) that's also secure and open source is very exciting to me.
213 comments
[ 3.0 ms ] story [ 237 ms ] threadRight now the protocol includes multi-device support, so the foundation is there for developing desktop and tablet apps that work seamlessly in conjunction with your phone. Our first desktop implementation is likely going to be a browser extension, feel free to jump in and get involved with that if you'd like.
Are the messages only delivered to the 'logged in' clients? So if I am logged in on the desktop my message exchanges are also sent to the phone client? But any messages I send/receive from my phone while logged out of my desktop are synced through the server on login?
A likely candidate is the link from "TextSecure V2 protocol".
I'd still like to know how actually their solution protects from MITM.
Fingerprint verification protects against MITM attacks. The application provides a nice interface where two users can scan a QR code to easily compare fingerprints. A hexadecimal fingerprint is also readily accessible.
Are you basically presenting me with an option next to xmpp/otr?
So in that case I'll stick with xmpp for my use case - self-hosting is just something that I wouldn't want to give up.
This is trying to combine 3 points on Zooko's Triangle [1]: You want human-meaningful names (which phone numbers are, because they map to existing things), so you have to make a trade-off between decentralization and security. WhisperSystems opted for security for some reduced decentralization. For something that’s aiming to replace text messaging, I can’t really blame them for that choice.
[1] = https://en.wikipedia.org/wiki/Zooko%27s_triangle
1 - https://missingm.co/2014/02/fighting-dishfire-the-state-of-m...
Doesn't that make them susceptible to a search warrant forcing them to give up the private keys (or equivalent) to TextSecure, ala Lavabit?
I was surprised; seems like a good basic target.
I use Silent Circle myself, but I assume on Whisper you can't just type in a normal mobile number and have the chat message go to the right person. If you can, then those chats at least are subject to intercept, and maybe the other chats (whisper-whisper chats) are too. I don't remember how all those rules shake out/how courts have decided.
While I have the utmost admiration for Levison's stand, the fact that Lavabit held centralized private keys for its users was a very bad technical and security decision. Moxie has more about this here [1].
Now some may be wondering, what's to stop Whisper Systems from backdooring TextSecure by court order? In a word, this: [2]. The TextSecure client is open source. Not only can the community scan the source for something suspicious, but we can build and verify the binaries ourselves.
[1] http://www.thoughtcrime.org/blog/lavabit-critique/
[2] https://github.com/WhisperSystems/TextSecure/
And even if you are one of those paranoid users who builds from source, a backdoored central build could still impact you personally unless you're sure everyone you are messaging has also built their own from clean source.
Personally I wouldn't worry too much about this scenario playing out, but I don't see that the client being OSS really buys you much safety practically speaking.
I supposed you could pull apart the container format (apk or ipa) and compare the .class files (Assuming Java, I haven't looked at this software so I don't know if it is standard Android or a lot of NDK stuff) or ObjC object files one by one to look for discrepancies versus a local build using the same tools... hopefully someone volunteers to do that and keeps doing it again on each new release.
https://github.com/WhisperSystems/TextSecure/issues/127
For iOS I believe that decrypting the binary and doing an objdump, then comparing the resulting assembly is a reasonable approach to ensuring that two builds do the same thing. Comparing objdump results won't protect against particularly insidious backdoors like those injected through data resources or binary headers, but in tandem with a source audit should give a fairly respectable degree of assurance.
This process would be quite easy to automate.
Not a chance.
And if someone is doing this, we are well past "particularly insidious".
I imagine certain organisations knew about buffer overflow bugs long before they were used publicly, so imagine if this was the 70's and you saw some strcpy calls peppered into some useful code, would you really be able to know 1) the class of attack exists and 2) if it was intentional or not?
There were some differences where the compiler/decompiler made a different decision, and that had to be checked out manually but in the end it was a pretty nice experience.
1) It allows you to ensure that your personal copy doesn't contain code that does overtly malicious things, like backdoor your computer.
2) An open-source client may not be an automatic certificate of good faith, but a closed-source client is practically a certificate of bad faith/incompetence when your business is security. (indeed, this scenario is predicated on the vendor attempting to capitalize on that very fact - and even if successful, the base-rate probability is still massively in favor of OSS)
3) It is very difficult to hide malicious code in a binary for which the source is available for comparison. It is comparatively very easy to hide malicious code in a closed-source binary.
4) If there is cleanly-building source available, not only users but many vendors (including most Linux distros) will package their own version from that. Many people who don't build the source themselves will still get a clean version.
5) The risk of discovery would be high and the consequences, catastrophic. Sooner or later someone will compile your source, compare the result with your binary, and find something suspicious.
It is overwhelmingly unlikely that an attacker would opt for this strategy. OSS is much safer.
You can built it yourself.
"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."
>The only secret is to [really] begin.
Nice one Moxie ;)
I didn't find his tone to be arrogant at all. You're conflating arrogance with correctness, and though many people on the internet use both simultaneously, they are two separate things.
[1] - https://f-droid.org/
What was it?
https://github.com/WhisperSystems/TextSecure/issues/53
You'll find a more interesting discussion about the reasons for not distributing TextSecure through alternate repositories on issue 127 though.
https://github.com/WhisperSystems/TextSecure/issues/127
Separately, what's the difference between this and OTR? Is it just trying to just be a better OTR (and I support this endeavor, competing OTR connections over one chat channel creates a hassle). And as such, why is it only on Android, you could just as well write a Pidgin plugin right?
https://whispersystems.org/blog/advanced-ratcheting/
If so, why is the padlock open? :)
The open padlock in the notification bar means that your passphrase is currently cached and anyone that picks up your phone can read your text secure messages. How frequently your phassphrase gets flushed and must be re-entered is a user setting.
In a world of IP connected devices, the need to tether your self to the telecom cartel for an identifier is outdated. It would be ideal if future versions of TextSecure let you log in with just your email and then you could run the app on your tablet, desktop or any other devices without a SIM.
http://www.nirsoft.net/countryip/index.html
I think localization could give a great boost to Whisper in countries where English isn't the native language or that well known, and it doesn't cost you much to do this. But as I said, it's probably best to just wait until Whisper is finished, if it's coming out this year.
Also a beautiful UI, and I can't wait for the iOS versions.
Good work, Whisper Systems!
It's still tricky to get security due to the platforms on which software runs, but now users can make reasonable choices about which platforms to trust, and by not tying your messaging application to hardware with a black-box baseband, users actually have a decent chance.
Hopefully there will be more progress on baseband-less mobile devices and reasonable networks for those users.
Congrats on the new release.
While TextSecure still only has 100k+ installs on Android: https://play.google.com/store/apps/details?id=org.thoughtcri...
Despite Telegrams known crypto failures: http://www.reddit.com/r/Android/comments/1yrv46/after_gettin...
Hopefully iOS and Desktop clients help TextSecure take off and beat out the weak crypto apps. Multi-platform is critical these days for messaging apps.
We really need to encourage folks to use these genuinely secure messaging apps rather encryption fairy dust like Telegram
Edit: Oh, I see. Added as a silent feature in 10.2 messaging app. There is no visible indication that secure communication is happening (or possible). Ok. Better than nothing, and a good default.
Mainly that "seamless" migration between SMS and data channelled messaging is not something I want to happen because SMS costs me a fortune on my plan, whereas low-volume data costs me nothing.
To that end, the options for the TS process during setup should make it clearer how data charges/SMS charges will be racked up, and indicate accordingly.
But there's no way to tell at the most important moment - when this new thing is being put in front of me, and claiming to do things with a service that has a usage charge to me.
It would be much better if SMS defaulted to off, it was made clear what it was, and SMS Push added as a "would you like to?" option instead.
Telegram's been around close to a year or so now. They are an established mainstream app and they look like an obvious "WhatsApp replacement" if one is looking for one. Far fewer people are looking for a secure IM app per se, so your numbers aren't really that surprising. Regrettably, unwashed gray masses don't give a flying f#ck about quality of the crypto, so TS doing crypto better is not a tangible conversion benefit.
The android version looks _exactly_ alike (except for different color scheme).
Just because you disagree with one datapoint doesn't mean you can't compare them.
but i found that use it to transparently send sms when needed super confusing to people.
people don't want to use sms. if they did they would just use that instead.
in cyanogenmod it's even more confusing. cyanogenmod integrated it to their base system, but you have no way of knowing if the text message you just sent is really encrypted or not (unless the other party tells you since he's running textsecure), i'm guessing/hoping that'll improve though
In either case, TextSecure works, so...
Is a desktop version in the cards?
EDIT: Yes, yes I can't read :D
https://twitter.com/moxie/status/438020504780152832
A few months ago I thought about using Threema and the like, but realized nobody's gonna switch with me. So I stayed. Didn't even try to convince anyone.
The day after FB bought WA my non-tech, not-concerned-about-NSA friends started to switch to Threema. On their own. Because Facebook.
Heck, they were even discussing all that on Facebook, as far as I know... that's irony.
So now most people I regularly chat with are on Threema.
And while I don't trust them (especially their competence -- although using NaCL is a good start) nearly as much as I trust Moxie, this issue is closed now. Nobody is going to move again without a very good reason.
The two people I regularly chat with still on WA can't use Threema, because they are still on Android 2.3.
But Threema really needs multi-device IDs. And the ability to change a group's composition. Other than that it's cool. You feel right at home, the emoticons look the same (from the same lib, I guess). And this whole "scan the other guy's public key" is not just a good idea, it's even close to gamification ("only two more people until everyone's green!").
And that's why I don't believe in some meaningful market share for Whispersystems. They are virtually unknown in non-tech circles. They still don't have an iOS app. Yes, I know, there were more important things up to now.
Still, the window of opportunity is closing. In three weeks no "normal" person is going to switch messaging service anymore. Everyone either stays at WhatsApp, or has already agreed with their whole circle of friends on another service.
It's going to be hard going to reflow the already interconnected with this. Wish it wasn't so.
...TextSecure is an SMS replacement. Your contact list is your contact list.
Does nobody you know receive SMS messages?
Of course I can still send unencrypted text messages. Are you trolling me?
Anything that is not public key encrypted must be considered unencrypted.
https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2 https://www.whispersystems.org/blog/advanced-ratcheting/
You can register an Account using any phone number. Just wait until the SMS verification fails, you then have the option to request an automated call, and get a verification code that way.
So far it seems like it's working.
Unfortunately doing this with mobile is really hard, due to bandwidth and power. agl's Pond is probably the best effort in the space so far.
[[citation needed]]
Is there an in-depth analysis of what data is exposed with the current protocol?
This is as silly as saying that all of the people who live in North Korea are brutal dictators.
It was never implied in xmr's post that every US citizen supports mass surveillance, only that they may be legally forced to participate in it.