To me, security is not a binary property but rather a sliding scale. WhatsApp say they use end-to-end encryption and they have a strong financial incentive to be telling the truth. No hacker has demonstrated that WhatsApp are lying and the Wikileaks dump suggests the CIA has been unable to intercept messages in transit. Given this information I would rate WhatsApp at least 'reasonably secure'.
I'm not giving much to the various "whatsapp backdoor" allegations but I'm curious to why they'd have financial incentive to provide privacy.
Most of their userbase likely still doesn't care about security and they do belong to Facebook - so if anything, they'd have a financial incentive not to use effective crypto.
If hackers could get access to WhatsApp and dump all messages to Wikileaks it would make the company look very bad and a significant number of users would switch to something else. If security is not that important to users, why pretend to add end-to-end encryption at all?
Teen Vogue just suggested people should use WhatsApp instead of Snapchat because it does end-to-end crypto. I don't think it's true any more that the general public doesn't care about security, if it was ever true.
Facebook cares mostly about penetration for Whatsapp, to ensure that no other messaging app takes over.
Free product advertising worth $N targeted to the more influential product adopters, who will then amplify said advertisements.
That's my guess, anyway.
If you want a completely free software smartphone experience, it is simply not possible at the moment. Even Replicant[1] still hasn't cracked the baseband puzzle (and is still struggling with the firmware for a couple of phones).
So no, Android is definitely proprietary -- even if some parts are not.
If you want a completely 'free' (as in GPL) cell phone experience, you can setup a OpenBTS transmitter and transmit at the 900mhz range which is commons property. To stay legal in the US, your antenna has to put out less than a watt, but the setup allows you to even use off-the-shelf phones and trunk into normal phone lines via standard POTS software. Your device would have to be something a-la http://alumni.media.mit.edu/~mellis/cellphone/ (just a janky setup, but just a proof-of-concept -- you can patch together components from DigiKey pretty easily these days; if you want free-silicon, I think the closest you're going to get is https://en.wikipedia.org/wiki/OsmocomBB or maybe some soft cores, but if you're actually going to take that soft core to tape-out, you're probably going to be running 6 figures just for masks...)
Initially looking to reuse old phones with the Calypso chipsets, the project is now working on producing their own. Design files are completed; funding for the dev boards is about 66% complete.
https://www.freecalypso.org/fcdev3b.html
Mailing list is fairly active too.
While (AFAIK) there isn't a regulation stopping someone from selling radios that have completely free software basebands, you can bet that the manufacturer will be prosecuted if users suddenly start outputting radio waves that don't follow regulations (suing users is harder than suing a manufacturer). As a result, there's a disincentive for manufacturers to ever sell free software radios (because by definition they would have to allow modification).
[1] https://www.infoq.com/news/2015/07/FCC-Blocks-Open-Source
Even if manufacturer provides the code, it can preinstall additional closed source programs. For example, Facebook app or some "telemetry" app that are closed source. My chinese noname phone contained an app that was trying to send my phone number and other identifiers to China as a part of a "sales report" (exact URL was http://bigdata.adfuture.cn /reboot/salesCountInterface.do ). And one can only guess how many data does Facebook collect.
What the end user gets is a phone with a binary blob inside.
I think there should be a strict requirement banning collecting any data without consent from user. No "anonymous" "analytics" and telemetry, no crash reporting, no advertising ids, no checkboxes checked by default. There can be only legal solution to the problem of mass surveillance by software companies. Every byte your device sends to network can end up in the hands of the hackers from developing countries or NSA.
- Signal code: https://github.com/whispersystems/
Telegram has had known flaws, which have been discussed in part here:
- Telegram protocol defeated. Authors are going to modify crypto-algorithm https://news.ycombinator.com/item?id=6948742
- A Crypto Challenge For The Telegram Developers https://news.ycombinator.com/item?id=6936539
- Telegram (initial discussion) https://news.ycombinator.com/item?id=6913456
https://hn.algolia.com/?query=telegram&sort=byPopularity&pre...
In fact, Facebook Messenger's implementation of Signal has very questionable security right out of the box, because if one party "reports" an encrypted conversation, the whole thing is decrypted and sent to facebook support staff.
The Signal Protocol provides end-to-end encryption so you don't have to trust the intermediate parties/servers involved in relaying the message (e.g. you don't have to trust Facebook's servers), and to protect against the other person reporting and revealing your conversation to someone else, the Signal Protocol provides message repudiation [1], which effectively gives the sender plausible deniability because the receiving party cannot prove to a third party that a message came from you.
[1] https://en.wikipedia.org/wiki/Signal_Protocol#Properties
See https://github.com/WhisperSystems/Signal-Android/issues/1181
Let's not make the perfect the enemy of the good.
There's few of the big corps I trust as little as Google.
If you were really worried about what a particular binary would do, trusting that the binary matched the source and studying runtime behavior would both be a waste of time compared to fully analyzing the binary in question.
If you treat the software as a black box and only study run time behavior, you have no idea if you have tripped a countermeasure that silences the malicious behavior; if you study the control flow directly, you can look for such countermeasures.
It would be great to find such a countermeasure, and be able to trigger it reliably, or assert the behavior on a permanent basis. Considering that particular weakness of such countermeasures though, wouldn't the safest [for the attacker] default countermeasure likely be to simply crash the device?
A user that knows about malicious code (which you would have to in order to trigger it to go silent) in a binary just shouldn't use the binary at all though.
The broader point is more important: compiled software isn't a black box, treating it like a black box is not the only or best way to analyze it.
But this sort of pessimism isn't really useful. The attitude that "anything is insecure if there is any closed source software anywhere in the stack" means that it's impossible to advance security, because it's almost impossible to avoid binaries (i. e. firmware).
Apple, for example, has done a few things that are laudable in this field – i. e. risking a public court fight with the FBI to keep the iPhone secure. If we say that such actions are meaningless because they ship binaries, they have no incentive to do such things. Just rolling over and giving the US gov big-pipe-access to everything like yahoo did becomes the better business proposition.
Similarly, what do you answer when a friend who works at the EPA asks you how to securely contact a journalist? If it starts with ordering a custom open-firmware mainboard from somewhere in China, your advice will be ignored.
* If there is a weak layer in the stack, from the physical layer to to UI, then the system is not secure. Even if your messaging app is secure, your messages are not secure if your OS is not secure
* If the source code is not available for review, the software is not secure
* If you or someone you trust has not done a full and thorough review of all components of the stack you are using, the software is not secure
* Even if the source code is available, the runtime activity must be audited, as it could download binaries or take unsavory actions or connections.
* On the same note, if you do not have a mechanism for verifying the authenticity of the entire stack, the software is not secure.
* If any part of the stack has ever been compromised, including leaving your device unlocked for five minutes in a public place, the software is not secure.
I could go on, and I'm FAR from a security expert. People compromise way too much on security, and make all kinds of wrong assumptions when some new organization comes out and claims that their software is the "secure" option. We see this with apps like Telegram and Signal, where everyone thinks they are secure, but if you really dig down, most people believe they are secure for the wrong reasons:
* The dev team seems like honest and capable people
* Someone I trust or some famous person said this software is secure
* They have a home page full of buzzwords and crypto jargon
* They threw some code up on github
* I heard they are secure in half a dozen tweets and media channels