Leaky Apps: A New Era of Expectations

Monday, March 3, 2014

Among the long string of revelations about the NSA’s spying tactics divulged by Edward Snowden, is the fact that “leaky” mobile apps such as Angry Birds make a lot more information accessible than users might want to share, such as their age, gender and location.

Considering the smartphone app explosion of the last few years, it's not surprising to find our livelihoods under scrutiny. The ease of installing apps is almost comforting, encouraging smartphone users to drop data into their pocket companions with almost wild abandon, and the media find that stories about lax security are easy click-fodder.

Last week my grandma asked me if it was safe to play Angry Birds on her iPhone. Take note: This same grandmother unwittingly installs trojans onto her desktop computer, without hesitating to ponder her actions.

Her iPhone is a sandboxed, encrypted device running a modern, secure operating system while her Windows machine, laden with malware from ill-advised downloads, is a computer where any application has access to everything on its hard drive.

This divided attitude about PCs and mobile devices is prevalent in today’s technology culture. Not so long ago Apple was chastised for allowing Path to upload the users' contacts to their API servers, yet for the last 20 years, any software you installed on your PC could (and probably did) do the same.

Mobile app developers live in a new era of expectations for us and for the apps we write. And that's a good thing.

In January, Starbucks was publicly humiliated because it was revealed that their app logged the user’s password, name and email address. It didn't matter that it was a private, sandboxed log. Or that you could only read it if you had physical access to the device, which would also have to be unlocked.

As developers, we’ve always been expected to encrypt our data, but now the world is scrutinizing our every misstep. You can’t afford to be insensitive to your user’s data.

Your API should be encrypted with HTTPS. Don't upload any user data without the user’s permission. If your app is a calendar app that has online-sync, then the user is likely going to know that you have to upload their calendar data (with HTTPS!), but before you upload their picture so it looks pretty on your website, you should ask. Don’t store secure information in plain text. You put stars up to cover the characters when they entered the data, so don’t leave that password stored in plaintext on the device itself. And for heaven’s sake, don’t log it!

In practical terms, using a desktop computer poses a much greater threat to personal security. When users download a screensaver, they may also be installing a keylogger. Bluetooth keyboards have frighteningly weak encryption. There are brand-name routers with more than 50 million units sold, yet 90 percent of their owners have never updated the firmware—firmware containing vital security fixes; these are almost certainly potential targets for hackers and once hacked they could get much more valuable personal data than that offered by apps that are a bit “leaky”.

We live in an age where everything is becoming Internet enabled—I own 14 devices that can play movies from Netflix. It seems perverse that The New York Times criticizes Rovio for “leaking” the user-submitted genders of their players when many smart TVs on the market are running Java or Flash, both of which are highly hackable. Really, what's worse? A third party knowing whether you are male or female, or a third party installing a bitcoin-mining backdoor on your television?

Nonetheless, the software running our mobile devices and PCs is merging, and it’s incumbent upon developers to be ahead of the security curve. You can bet that certain developers have had their Starbucks cards revoked and have encountered a few angry birds of their own. Let’s learn from their experience.

This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.