My understanding is that they can prevent you from removing warrant canaries but they can't force you to continue announcing "I have not received a secret warrant".
In places where there are limits to what the government can do to an with you, its possible to resist.
EX: https://en.m.wikipedia.org/wiki/West_Virginia_State_Board_of...
The US government can’t legally compel you to lie, but may restrict what you can say.
We know that the legal bar for forcing someone to speak or not speak is high (compelling state interest), but national security has usually been held to pass such a bar.
Warrant canaries are nice to have, but viewing them as something which provides proof of absence of government meddling is incorrect.
That wouldn’t even be illegal, since they never hit you with a wrench - you just imagined they were about to go xkcd on you
It reads like your product is already compatible with govt ease dropping
You don't have to take our word on this -- I wouldn't want you to. As others on this thread have pointed out it's possible enough to tear through our binaries that if we did have a backdoor it would be discovered.
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.
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.
Signal has the same issue.
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.
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.
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.
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.
That's explicitly against your terms of service.
Hassan https://www.clipart.email/
Sometimes this leads to us being blocked. We were blocked in Brazil, for example, but that block was overturned in the courts.
It'd indeed be interesting to know if the FSB had some kind of baseband vulnerability that they'd used willy-nilly to facilitate dragnet surveillance.
I suspect William Binney was right though - blanket surveillance is just expensive and hides your needles in a mountain of hay; you really want high quality in the data you store in order to ease extraction of meaningful information / intelligence.
(that's not to say that aggregate meta data isn't interesting - just that with actual content noise is a problem)
Have you considered architectural changes that will allow for the app to be compiled and deployed by an affiliate corp outside of these jurisdictions?
So will WhatsApp refuse to comply, if this goes forward?
And is that even possible?
I do appreciate that Facebook has the resources to fight. To fight an NSL, even. But IANAL, and have no clue.
Any comment on this?
https://www.theguardian.com/world/2013/sep/11/nsa-americans-...
We believe people have a fundamental right to have private conversations. End-to-end encryption protects that right for over a billion people every day.
We will always oppose government attempts to build backdoors because they would weaken the security of everyone who uses WhatsApp including governments themselves. In times like these we must stand up both for the security and the privacy of our users everywhere. We will continue do so.
Will, Head of WhatsApp