Doesn't that make them susceptible to a search warrant forcing them to give up the private keys (or equivalent) to TextSecure, ala Lavabit?
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.
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.
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.