[sdevlin]

Most of the comments so far focus on the fact that WhatsApp is a closed-source system. And just to be clear, it would absolutely be better to have source code. Source code gives you a 1000-foot view of the application and lets you spot obvious problems quickly.

But source code can also lie to you. To really understand what the application is doing, you need to do what security auditors do irrespective of source code availability. Namely:

1. Disassemble the application binary.

2. Debug the running application.

3. Observe the network traffic.

Here's another thing to think about. Suppose the source code were available. How could you trust that the source code provided matches the compiled binary running on your phone? You would need to perform the above steps to verify.

[userbinator]

This is why I think reverse-engineering needs to be far more common knowledge; maybe to the extent of being required in a CS curriculum just like going in the other direction (from source code to low-level CPU operation) often is. There is far too much blind trust in things at the "lower level", like compilers and libraries, and while it's much harder for the average person to reverse-engineer hardware and verify its operation (requires specialised hardware too), with software it is relatively easy and should be something that every programmer should know at least a little of.

Of course there's the legal aspects of RE, which often dissuade people from even thinking about or discussing it, but I think that just telling people they could if they really wanted to discover exactly what their software was really doing is already sufficiently empowering. No doubt there would be plenty of opposition to this... which would primarily be from the proponents of DRM and the like, who very strongly want software (and hardware) to be treated as "black boxes". But it is, at least with general-purpose computers, relatively difficult to stop people from examining them, and even more difficult to tell if they did --- which is why I think this knowledge of RE is truly liberating.

Stallman's story is also worth mentioning here: https://www.gnu.org/philosophy/right-to-read.html

[higherpurpose]

I would at least like them to:

1) state in their Privacy Policy somewhere that they are using end-to-end encryption and they can't see the messages - this means that if they change that later and get caught, they could get in trouble with the FTC

2) show me somewhere in the app that I'm using end-to-end encryption. This should teach their users that they are using end-to-end encryption, and it would make many more angry if they find out they are "lying" if they're using that interface but without actual end-to-end encryption behind the messages

Unfortunately, Whatsapp hasn't even made an official statement about adopting end-to-end encryption. Only Moxie has. So right now Whatsapp gets all the benefits of the media attention from "using end to end encryption", without having to hold themselves to that promise at all ("hey - you didn't see us say anything anywhere about using end-to-end encryption, did you?!").

So I don't necessarily want to see the source code, but at the very least they should publicly and legally commit to using end-to-end encryption.

[jumpwah]

Well for the reader, here's an interesting recent talk related to your last note: http://media.ccc.de/browse/congress/2014/31c3_-_6240_-_en_-_...

[aroman]

It the source were available, I could compile it into a binary myself and calculate a file checksum and compare it against the binary downloaded from the App Store. Obviously not the case here, but i don't think you'd need to "performs the steps above" to verify.

[scrollaway]

And you would almost certainly not get the same checksum unless they provided you with the exact toolchain they used (which almost nobody does) due to compiler version mismatches or some such.

[mahouse]

Even if you used exactly the same toolchain you would not get the same checksum because the binaries will probably have some other information embedded, such as timestamps.

[tlrobinson]

"deterministic builds" is actually a pretty hard problem with most existing compiler infrastructure. Bitcoin and Tor use a system called Gitian: https://gitian.org/

[s3arch]

Having a source code might help you in skipping the first step(decompile and disassemble), but you have to perform step 2 and 3 to analyse the behaviour of the program.

You might have to perform step 1 , if the source code had compiled third party libraries, which might contain hidden routines to perform malicious operations (such as decryption).

[wglb]

So what would be the next step be when (not if) they don't match?

[jokoon]

mmh

1. having a public repo of the official source code

2. hashing the executable you have on your phone

3. the repo publishes a hash of its compiled executable release

4. the repo approves or reject the binary, based on the decompiling of the application and its comparison with the original source code

5. your os cannot run code that is rejected, or will just warn the user

don't know if a digital signature could be used somewhere in there.

would be much simpler to let system download source code and compile it instead of an executable I guess, but that would require to have much lighter libraries...

[medecau]

Was reminded of: Reflections on trusting trust - Ken Thompson