What's troubling is, that their security track record has been abysmal from the start. In that regard, the acquisition sends entirely the wrong message.
The market's been sending that same message for years.
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.
It sends a message that caring about your users' trust, that doing what's right for them, is for suckers.
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.)
No it isn't 'prefer'. It's that users don't care about this kind of security in practice, they only care about the kind of security from other people in their personal lives, which is more about privacy controls than actual security.
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.
Every security researcher goes through this phase when it dawns on them no one gives a shit about security. It leads to a few years of depression, and then going to work for people who, for whatever reason, really do care about security.
Just out of curiosity, where would you store the unique AES key, that wouldn't break the UX in many ways? For instance, not losing messages when you upgrade your phone.
Storing the key is easy, you put it in your app's private data folder. Which is where the database should have just been stored in the first place, and not on the public SD card.
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)
This API wasn't available until Ice Cream (4.0). I don't know WhatsApp user makeup, but I wouldn't be surprised if this "system" is a holdover of what was available to them in Eclair.
I don't think you are evaluating the tradeoff at all here. WhatsApp won by making a friction free experience. You are adding email and pass phrases, or any one of the dozen things that make it harder to use.
I accept there is a good solution, but I don't think you are thinking about the problem broadly.
There is no "tradeoff" here for a reasonably vertebrate hominid. When you demand user trust, security is core. If it's not core, go home because you cannot be trusted to make adult decisions.
The people using your software are more important than your fucking term sheets, man.
You do realize all desktop software has this same vulnerability. I think you are being a tad hyperbolic.
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/".
> Google should have figured out how to let applications sandbox data on the SD
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?
I think the widespread practice of Android applications storing potentially large data in /sdcard dates to a time when /data was extremely small on most phones, and would fill up quite rapidly if you had a large number of applications installed. I don't think that's the case any longer, at least certainly not for an SMS app.
OS X doesn't have that problem when using sandboxed applications. I choose to opt out by installing non-sandboxed applications, but I know that I'm doing so and I don't install non-sandboxed stuff from people I don't trust. I also have much more accessible tools for inspecting the behaviors of applications, should I want to do so, on OS X than Android - I can do my own homework if I have a notion. (I don't expect end users to do so, but the option is there.)
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.
For what it is worth, I wasn't interested in a privacy debate, but rather technical advice.
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.
Yes, I did, I wouldn't be replying if I hadn't. But I was replying to the parent comment.
>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.
Store it in private and keep a copy on WhatsApp's server if the internal storage is lost during an upgrade (I'm assuming Android apps can't sniff each other's packets, can they?). It's not secret-from-whatsapp, they can read your messages regardless. Then the data in external storage would be comparatively safe from other apps on your phone.
One might think Facebook did their due diligence and said, "DANG, you got all these users with this big of a hole just laying right out there? Here, have some money."
Haha! But seriously given the leaked chat messages from when Zuckerberg was still not the polished CEO and less mature [1], your argument seems plausible.
> 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
This is actually the first time that I'm posting this, but yeah I don't fault Zuckerberg. That was one of the reasons that I added that he was perhaps less mature then. Thought processes & some beliefs change over time and I'm not saying he is the same person now that he was then.
