Storing critical data to external storage (which is clearly explained as unsecure in http://developer.android.com/guide/topics/data/data-storage....) is a huge security hole. This kind of basic oversight makes me wonder about base competence of WhatsApp developers - anyone with basic understanding of the OS would get that anyone can read external storage.
One important point here: In the article the author says that the location of the database is /sdcard/WhatsApp/Databases. That's not entirely correct.
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...
This needs to be at the top. The fix here is very simple then - prompt the user for a passphrase when doing a backup, allow no passphrase for a "friction free" if you really want to, but give the user the option.
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.
> the insecure /sdcard partition is the place where most of the storage is in nearly all Android phones.
/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.
This is true on Nexus phones, but it's a mount point (not "emulated") on Samsung or other SD-card-equipped phones, which I think--not sure--is more of a majority.
No, on Samsung & other SD-card-equipped phones /sdcard points to internal storage and there's some other path, like /sdcard2, that points at the actual SD card.
Yeah I agree - increasing the size of internal storage was a blessing for my/our apps in terms of security (no more storing of secure data on shared storage due to lack of space).
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 :)
My last gig was with a medical software company, storing and uploading physician recordings. The first thing I did in the process of building the file system component was to set up AES based off a passphrase and never let it out of memory (not safe against a rooted phone rummaging through memory, but that user's acknowledging the risks by doing so). It took me, like, a day, with tighter performance requirements than storing text messages will ever have.
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.
I think that the problem is that "user-hateful" is the opposite of what's actually happening here: we're still at a state where security is something that users don't actually like, because it often puts the burden directly on them. Viewed cynically, what's happened here is that we have received "the software that we deserve".
