No way anyone else at FB could have built this app and given it away for free for years for that price.
No way. Totally worth it. 19bn $.
Sequoia's deck on the amazing sclaing of 32 devs supporting that many users? well, guess what, they did it through taking shortcuts. Who would have guessed. Totally flabbergasted.
Your entire SMS history is available to any app with permissions. Most people don't even know that, or are not bothered by it. This is literally feature parity with default SMS. WhatsApp is about messaging that is simple and functional. Security is not even a main selling point.
If you want security, there are apps for that. Good luck getting your friends to use it.
Didn't the founder specifically cite growing up under an oppressive regime as a key motivation behind WhatsApp?
That's a fair stance. I don't have strong feelings vis a vis WhatsApp, so this is more of a general statement :
I think the illusion of secure communication is more dangerous than insecure communication. People who think they can't be spied on will expose themselves in ways they otherwise wouldn't.
It is not a few blips. They have consistently shown to be unable to implement any kind of effective cryptography. Take this case as an example. They seem to have tried to prevent such kind of attack by encrypting the data on the SD Card with a static key. How hard would it have been to generate a random key and save the key on the internal storage?
An other example is the transport, i.e. client-to-server encryption. Even their new protocol looks like it has been hacked up by someone who learned his/her cryptography by 5 hour wikipedia reading: https://blog.thijsalkema.de/blog/2013/10/08/piercing-through... . You would think that for a market value of 19x10^9 dollar you could afford to hire a single cryptographer or IT security specialist. Especially after you have been criticized for your bad security for years.
> If you want security, there are apps for that. Good luck getting your friends to use it.
We are not even talking about difficult usability decisions here where strong end-to-end encryption has to be visible in the user interface to allow fingerprint checking. This is about the most fundamental security measures, like if you connect to your server use TLS (and check the certificate) or if you encrypt something don't use the same key everywhere.
I mean, yeah. That's what permissions are for.
If one wanted to criticize Android for having such broad SD card permissions, there may be an argument there, but given the current state of things, it's trivial for apps to securely encrypt files they put on the SD card (they store the key in internal storage, which is much better-protected.)
And my friends are already using it; I guess the luck was not really needed.
Which is the problem with this kind of "market". It's basically theft, yes, stolen merch does sell well. Join the game, this is how the rules are played, take a page from the CIA's book. Have fun!
They took a lot of shortcuts, which turned out really well for them. Simplification made for a very fast client and a low-latency, low-bandwidth protocol.
Cashing out billions why we criticize from a web forum.
Security is a cost center and potential source of user-friction. User Data Integrity is a "nice to have". Privacy is considered only from the angle of "what can other users see through normal operation".
And that market is driven by the consumers themselves.
This is not a test of "technical superiority". This is working against your users' best interests. One mistake is understandable, and sometimes forgivable, but you don't bilge it twice so cavalierly if you rank on the give-a-damn scale. (I say "cavalierly" because, as I noted elsewhere in this thread, I can't shake the feeling that this is the result of a design decision, not a technical failure.)
Whatsapp could also use TextSecure's ratcheting protocol, too. Why aren't they? Beats me. Maybe they prefer weaker security for their users.
Because of this, they get no reward from the market if they actually focus on security. Instead they focus on things the market DOES reward them for, which is being fast, never being down, being available everywhere, for the cheapest price, with no annoying ads.
They only have 35 engineers, what they could do is limited. So security becomes priority #50 like for most start ups and only a few token hours efforts are put into place. That single AES key was probably implemented 3.5 years ago.
Um, am I the only one that thinks 35 engineers is a pretty good size team to get a good amount of work done?
It takes extraordinarily good engineering practices and discipline to get 35 engineers working as well as you'd imagine WhatsApp could have.
You could also have a user-supplied passphrase with email recovery. Or any of a dozen other best practices that exist. This isn't exactly a new problem, there are plenty of solutions that are far superior to rot13 (which is basically all this is)
I accept there is a good solution, but I don't think you are thinking about the problem broadly.
The people using your software are more important than your fucking term sheets, man.
WhatsApp has some blame, but Google should have figured out how to let applications sandbox data on the SD card without having to do roll your own AES key management system. It could have been as simple as put the data in a folder named "private/appname/".
It's called put your data in /data. You get a private app data folder by default. /sdcard and /data are both internal storage on the majority of phones, neither points at a physical sd card slot.
And seriously, who wants their messages stored on /sdcard anyway? You pop out the sdcard and all your text messages vanish? What kind of brain dead decision is that?
And Android external storage is explicitly not for sensitive, in-the-clear data. Ever. It doesn't matter what Google "should have" done. They documented What Not To Do, and then WhatsApp went ahead and Did.
I have come to the conclusion after a bit of research, the only way to make this backup work is to require a passphrase, or for the OS to provide sandboxing. Android 4.4 provides the necessary sandboxing. I am sure WhatsApp will use it.
I don't agree with WhatsApp's choice to not require a passphrase, but I at least understand their thinking. They chose frictionless backups with the risk that malicious apps would be able to read you text messages. That is not the choice I would like, but it is not a choice made by an invertebrate.
Hacker News at times reminds me of this scene from the Princess Bride:
That may be the problem. WhatsApp has focused since the beginning on making their app available on as many devices as possible (They even have symbian compatibiity).
My WhatsApp database is almost 500MB, this is more than many low end Android phone's internal memory. Therefore, they decided to store the database on the SD card.
I don't think that this should be a problem had they decided to implement proper encryption on the database.
I'm not an expert and this is just pure speculation, so please, take as it is.
>Which is where the database should have just been stored in the first place, and not on the public SD card
I was just guessing why WhatsApp may have decided to put the database on the SD card. But maybe I didn't understand what kllrnohj was referring to when he said "database".
EDIT: Also, that's why I said:
>I don't think that this should be a problem had they decided to implement proper encryption on the database.
> ZUCK: yea so if you ever need info about anyone at harvard
> ZUCK: just ask
> ZUCK: i have over 4000 emails, pictures, addresses, sns
> FRIEND: what!? how’d you manage that one?
> ZUCK: people just submitted it
> ZUCK: i don’t know why
> ZUCK: they “trust me”
> ZUCK: dumb fucks
Do you always check whether what you are about to write/post has been written before?
It only gets copied there when you use the build in backup feature (Settings -> Chat Settings). Else, it sits "safely" under /data/data/com.whatsapp/databases like every other Android sqlite database.
But nonetheless, WhatsApp was and is not really known for its safety...
Still, I think Google is taking the wrong approach: the insecure /sdcard partition is the place where most of the storage is in nearly all Android phones. If your app needs to store larger amounts of data, that is the place to do it. Now, there are methods to use that storage a lot more securely than this, but the way Android works really leaves developers no other option than storing this stuff on the SD card.
Google should lock down access to the SD card even more, but they'll probably cause an uproar and break many apps.
/sdcard and /data are on the same partition these days, you should just be using the app's private folder if the data is sensitive in the slightest. Which in this case it clearly is, and it's not even large data.
Google should probabl MTP from the start and just formatted SD cards with one of the ACL supporting filesystems to get security right. But as the saying goes... it's easy to be a general after battle :)
But I kind of disagree with your wonderings. The problem here, isn't "base competence"--it's that it's harder to suck people into your funnel when you have frictional stuff like passphrases or verification. I cannot see an eventuality where this isn't the result of malice, where this isn't user-hateful by design. That bothers me profoundly.
Bruteforcing the 4-pin digit is easy "math-wise", but complicated in practice because you can't really access the data on the flash (not even dumping it, as it's fully encrypted with a hardware key), and the device will not pair to a new PC/Mac without first unlocking; so you would also need physical access to a paired PC/Mac.
For the newest devices, fingerprints can't really be bruteforced (not because of complexity, but the because the hardware locks down burning its secret after a few attempts) and Apple advises using a complex password as a fallback for the fingerprint; basically the password is the real secret for encryption, while the fingerprint hw just holds a temporary unlock secret which selfdestroys if bruteforced; this is why the user is always required to enter the password after a reboot.
Of course you might still have a 0-day root exploit to use if you're NSA (or somebody with $300K to invest), and that's where I concede the "not fully safe".
If they put the database in their isolated storage then no. Apps are sandboxed to their own isolated storage folder and cannot get access to the other apps folder (the source of your pain)
Edit: Spelling is hard
Let's hope Facebook helps their development team.
I am speechless by such a statement.
Wrong. You spake.
I remember writing a rooted script for Tasker to get the actual messages to my pebble, since WhatsApp still doesn't expose them through their notifications.
I fired an SQL query to their sqlite database everytime a notification from WhatsApp came in to see what the new message actually contained.
This is basically what Android apps have access to when requesting STORAGE permission.
Surely it is the same "problem"?
I would have to think this would be something EVERYONE would be upset by.
Have you never noticed this when you grant apps permissions? All of this is clearly written on the permissions list -- READ_EXTERNAL_STORAGE is explained there in layman's terms (as in, "this app will be able to read and write files on your SD card" or something similar).
And now, in KitKat, there have been some major changes in how the SD card can be accessed by apps, which I don't fully understand (never had to develop for KitKat only). But only a small percentage of users have KitKat installed.
If you're really storing sensitive things on your SD card, you should probably look into using some type of app for encrypted file storage (there are many on the market).
To an end-user, WhatsApp is essentially an SMS application, except it doesn't use SMSs. Given that, this doesn't seem like the end of the world.
Please be aware of who has physical access to your phone.
1. So basically, if you're installing an app AND you're allowing the app to access all of your phone (and its dirty secrets)
2. I don't see why whatsapp would encrypt the chats (I might be very wrong on this one), isn't it better if we can access them offline through a computer if the phone crashes?
3. Bigger picture: at first, dividing permissions and asking for the user to accept them was a good idea, but now we tend to accept anything because in the end, we want to use the app. Same problem with facebook login, google login, where we tend to accept whatever info websites request just to get to the app.
The idea of handling the SD card has a global shared filesystem that totally bypasses the application sandbox is a security disaster from the get go. Fortunately, SD cards are on the way out, and Google doesn't even bother to fix it at the system level since they're dropping it anyway at some point.
I don't know about you, but I'd rather not sacrifice my freedom to manage storage for a little temporary security...
it seems pretty obvious that this was the case
OpenSSL's aes-192-ebc gives me a slightly shorter, but well-formed db.
WhatsApp is storing to external (on most devices FAT) storage (which was SD card on older devices, it's usually a separate directory/partition on newer ones) which does not have any ACL-like system due to FAT backwards compatibility.
Now? Well, it still has a lot of potential. Even Google seems kind of embarrassed by it, compared to the Chrome brand.
On the side note, from old news I remember Google is indeed pushing forward with Chrome-brand, specifically Chrome OS.
"webserver" is a hyperlink, but it just links back to the blog. Anyone know what he's referring to here?