> it's possible enough to tear through our binaries

No, it's not "possible enough" and I strongly suspect you fully realize that.

A backdoor doesn't need to be in a form of an IF statement or something comparably obvious and silly. It can be a weakly seeded PRNG that would allow a "determined party" to brute-force the key exchange in a reasonable time. That would take man-years to fish out from a binary, and that's without considering that you may (be forced to) distribute an altered binary on demand and to specific targets only.

So in the end all we have - realistically - is in fact just your word. There's no way for you to prove that you are trustworthy by pointing at some random binary. The only option is to distribute reproducible builds from an audited open source.

Distributing an altered binary to specific targets should be impossible as WhatsApp don't control the distribution, Apple and Google do. They would also have to be complicit too for a targeted attack to be feasible. By having to distribute the same binary to everyone it is much harder to conceal a backdoor

Are you sure that there's no way for whatsapp to download and execute some code which will lead to upload of protected information?

Simple example: I'm sure that whatsapp main window is webview. Imagine that application inserts some kind of resource (e.g. CSS) from whatsapp server. So now whatsapp server can serve slightly altered CSS which will leak secret data via custom fonts, etc and you won't be able to find that, unless you're intercepting all traffic and can decrypt it (and apps nowadays love to pin certificates).

This is imaginary attack, I have no idea whether whatsapp does that. But HTML is a powerful and dangerous beast, yet it's used a lot in applications for rich media.

Juniper reveled the Screen OS backdoor with a quiet patch over Christmas. Within a month the backdoor was fully understood.

They had a diff, they knew where it was. This helps a lot.

I disagree that it would take man-years to fish that out from a binary. Black hat and white hat hackers do this all the time.

I agree. The crypto used is industry standard, and the actual process all the way from random number generation to deriving a key is relatively easy to follow.

Active ways to attack the client to make it leak the key are far more worrying - but even an open source project wouldn't protect against that.

Again, it may very well be a vanilla TLS, but then you have a bit of code in some obscure corner that repoints random() to an alternative weaker implementation when some conditions are met, including, for example, not being run under a debugger and not having certain popular functions trampolined.

Good luck finding even this without a fine comb. And that's us just getting started with code flow obfuscation.

No source = no trust. It's as simple as that.

Unfortunately, the WhatsApp terms of service say you must not "reverse engineer, alter, modify, create derivative works from, decompile, or extract code from our Services"

In (at least) the US this wouldn't hold up in court if they went after you: https://cr.yp.to/softwarelaw.html.

Of course if WhatsApp detected an abnormal or tampered version of the app, they can suspend or disable your account. I'm sure security labs that do reverse engineering of this sort probably do it on test handsets with burner numbers and identities so it wouldn't affect any personal accounts they use.

Perhaps, I just thought it was an odd thing for the head of WhatsApp to say: You don't have to take our word on this - just do this thing that we prohibit in our terms of service.

Whatsapp is owned by Facebook. Facebook has never been a leader in corporate governance, or even solid moral decision-making.

This should be completely believable for a company that relies heavily on user and community trust.

That said, @wcathcart: in community with deep technical expertise like Hacker News, folks do consider how many possible channels and means there are to confidentially leak information from applications.

You're correct that in the general case it's likely that tech-savvy users would scan a popular app like yours and find any 'obviously-placed' backdoors. It's an observational and opportunistic approach, akin to the way a passer-by might spot a poorly locked bicycle on a street.

Unfortunately there's an extra level of complexity here - any app may have unusual behaviors that a sophisticated attacker could trigger for individual users to exploit them - and it's really, really hard for the security-conscious of us -- who might never see or meet those users -- to truly trust that your app is doing what you tell us it is, whether that's end-to-end encryption in all situations, or anything else.

The reason is that without being able to see how the app is written, verify that it's genuinely the same compiled version running on all devices, and audit the behavior it will have under exceptional circumstances -- external observers just don't know.

I'm not expecting you to make the source freely available, incredible though that would be - but attempting to explain the potential disconnect in dialogue you might find with some commentors.

I'm not sure it wasn't answered before, but why do you refuse to open-source the client app, since, as you say it yourself, you try to have no secrets on the client-side, encryption is supposed to be e2e, technology is well known and implemented in many alternatives and basically there seems to be nothing to protect in the app itself?

Please implement a warrant canary while you still can, before you are legally compelled not to.

> tear through our binaries

That's explicitly against your terms of service.

We now have explicit, written authorization from the head of WhatsApp to reverse engineer ("tear through") the binaries. The ToS only prohibits unauthorized reverse engineering. I agree with you that it was disallowed prior to this comment, but I think it's OK now.