Archive for January, 2016

The app permission model on iOS and Android is broken: here’s how to fix it

Tuesday, January 26th, 2016

The permission model on smart phones is all wrong, and everybody knows it. I’ll use Android as an example, mainly because I’m more familiar with it, but I don’t imagine iOS is much different.

When you install an app on your phone (or tablet – which is just an oversized phone after all), it asks you whether you will allow the app to have various permissions on the device — can it see your location? Access your contacts? Your camera? The network? The set of possible answers is, unfortunately, very limited: yes or no. No means you can’t install the app, yes means you accept whatever it says.

There are two problems with this model:

(a) You have no idea *why* the app wants each permission. There is only an assertion that it does, but not what it will do with that access. Often, the reason is quite legitimate and benign, but it’s entirely up to the phone’s owner’s imagination to figure out why the heck app A needs permission B.
(b) The set of possible responses is too limited. It’s either accept the app, with all the permissions it wants, or do not install it at all.

These problems lead to a third problem, which is habituation. Since the reason for apps to demand permissions is opaque and the only option is to not install the app which, presumably, the user actually wants, users stop reading the warnings and just blindly accept all apps with all permissions, no matter how bizarre.

I’d like to suggest a slightly more nuanced model, one that could easily be implemented by the phone OS vendors, that would improve the situation a great deal:

(1) Require app vendors to provide a bit of text next to each permission, that explains what they will do with the access they require. Users don’t have to read this – perhaps just click through on the permission to see what it’s all about.
(2) Provide a forum for interested users to complain to the OS vendors, in the context of their app markets, when they detect (through debugging, network diagnostics, etc.) that app vendors actually use permissions in ways that they did not initially indicate. Basically catch out liars. If an app vendor is caught lying about what they need permissions for, and the OS vendor confirms that, then add a warning to the app installer saying “but the vendor is lying here.” I bet there would be very few lies very quickly!
(3) Enhance the OS to be able to send simulated data to apps, in place of the permissions they seek, under user control. For example, if I install an app that wants access to my camera, and I do want to run the app but don’t really want to give it camera access, I should be able to feed the app fake/random images. Same goes for network access – let the app think it’s hitting the networking API, but connect it to a loopback interface only. App wants to see my contacts? Feed it random contacts. This way, I can have more fine grained control over permissions, not just “yes, everything / no, no app” without breaking the app’s code.

As an app vendor, I’d be perfectly happy to live within these constraints. We publish apps that do want access to contacts, cameras, the network, etc. We have perfectly good reasons for these permissions and would love to be able to explain those to users at installation time. If users want to feed our app simulated data, that’s fine – they will lose some functionality, but gain some comfort. That’s totally fine.

As a phone user, I’d also love to have this kind of control. Install the apps I want but limit what permissions they get based on my personal preferences.

So how about it, Google and Apple? These are technically minor enhancements with a major, positive impact on the security of your app ecosystems.

When deploying security software – be sure it’s written by experts

Tuesday, January 12th, 2016

A colleague pointed out this interesting thread, about a variety of security exploits in Trend Micro’s ‘Password Manager’ module:

The nature and severity of the exploits are … breathtaking. The slow and indecisive response of the vendor is similarly amazing. For TrendMicro customers, the conclusion is simple: don’t install this thing. More generally, it’s clear that the team who built the product has a very weak grasp of security. Is it just this team, or the whole company? Who knows? What about other vendors in the IT security space?

It turns out that other security products, theoretically designed to protect you, actually introduce their own exploits, as discussed here, and herefor example.

That’s quite scary, because most users think they are improving their security posture by deploying such software, but (a) these programs require very deep OS privileges to run, and (b) these programs are, it seems, sometimes written by people who don’t have the skills required to write secure code. The consequence is that users, thinking they are doing the “right thing,” are actually endangering themselves.

What to do?

First, I’m not much of a fan of anti-malware software. The OS (Linux, Mac, Windows, etc.) is more secure than most people imagine — most vendors have been taking security quite seriously for years now, have pretty good designs and usually respond promptly to any discovered vulnerabilities. Do turn on the security features of your OS, do encrypt your filesystems, do keep your software actively and promptly patched, do avoid sketchy web sites, and you should be fine. Where’s the anti-malware program in that narrative? Notably absent!

Second, if you do go for anti-malware, keep an eye on public disclosures of exploits. If a vendor has been caught doing egregiously dumb things – as TrendMicro has here – then avoid them. Who knows what other products have been infected by the same clueless development practices?

Safe computing!