[georgemcbay]

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.

[dTal]

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.

[rtfeldman]

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.

[georgemcbay]

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.

[bri3d]

The Whisper Systems people and the community are already discussing this issue, at least for the released Android app:

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.

[lawnchair_larry]

> 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".

[dTal]

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.

[DanBC]

Debian SSL bug lasted a while.

[dTal]

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).

[gnerd]

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?

[Bockit]

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.

[tokenizerrr]

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.

[fragmede]

That sounds fascinating. Mind writing it up so others can do the same?

[tokenizerrr]

Here you go: https://news.ycombinator.com/item?id=7299245

[fragmede]

Awesome, thanks!

[mindslight]

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.

[georgemcbay]

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).