Linked by Thom Holwerda on Fri 13th Dec 2013 15:40 UTC

Yesterday, we published a blog post lauding an extremely important app privacy feature that was added in Android 4.3. That feature allows users to install apps while preventing the app from collecting sensitive data like the user's location or address book.

After we published the post, several people contacted us to say that the feature had actually been removed in Android 4.4.2, which was released earlier this week. Today, we installed that update to our test device, and can confirm that the App Ops privacy feature that we were excited about yesterday is in fact now gone.

If there's one thing that needs some serious love in Android, it's the application permissions. I carefully look at them every time I install an application, but I'm guessing most people don't. While there's only so much stupidity technology can solve, Android's application permissions are, indeed, quite overwhelming at times. I'm not a particular fan of modal dialogs every time an application needs permission for something (the iOS way) either, so I'm not sure how this can be addressed in a user-friendly way.

App Ops seemed like a decent compromise that allowed for lots of finetuning of permissions, per application. Luckily, I'm using a custom ROM that re-enables it, Google be damned. Google claims App Ops may break some applications - well, that's not really any of my concern. If an application breaks because I do not give it permission to find out if I'm on the toilet or not - there's always an uninstall button.

So, Google better have some serious improvement in mind for application permissions, or they're just making sure regular users don't get into the habit of blocking Google's data collection. I hope the former, but I'm reasonably sure it's the latter.

Permalink for comment 578619
To read all comments associated with this story, please click here.
Member since:

The basic idea (which is shared by WP as another poster mentioned above) is that permissions are granted only when actually needed by the app and the user is prompted at that time with a (potentially helpful) message [1]. While this doesn't fix the social problems associated with any click-through approaches it gives you the ability to have an app do only what you want it to do.

That was the same model that Mobile Java used, up to the point that permissions were as fine grained as individual files. Just choosing a image to edit in an image processing package had you click through a number of permission dialogs.

If you don't go fine-grained, then you grant generic file access once, and the application can access some other thing afterwards without you suspecting it.

The simplest example is something like a camera app which needs permission to write pictures to the SD-card and also to use geolocation. While I'm OK with saving pictures to the SD-card I'm not OK with having them tagged with the coordinates were they were taken so I usually forbid it from using geolocation services. This scenario - which I use every day on my FxOS phone - is simply not possible in Android's model.

Well, the standard camera application lets you decide whether you want your pictures tagged or not... That's a built-in application. If you don't trust it to do what you say, you probably will have the same problem trusting the OS to enforce permissions.

Android's model also has a completely idiotic side-effect: applications are not designed to have optional features depending on the permissions they're granted: it's all or nothing. So if feature X which you'll never use needs permission Y you're still forced to give that particular permission to the app and this automatically grows your security perimeter even if you're not using that feature.


There's a nice automation application for Android called Locale [2]. As an automation program, it lets you trigger action when you reach some location, when your calendar shows up some event, when you are in range of some cell tower or wifi hotspot, etc...

Then you could have a wide variety of actions triggered, like changing settings (brightness, volume), starting or stopping other programs, playing music, sending an SMS, showing a notification, sending an email...

This kind of program could potentially use all permissions out there. What they did was to use Android's intent system to make each one of the triggers and each one of the actions a distinct "plugin", distributed as a distinct app with its own set of permissions. So you know what permissions to expect in the location trigger module or in the SMS sending action module, for instance, and you can choose not to install them.

This might be a more difficult way to build Android applications, but the opportunity for modular permissions is already there. See [3] and [4] for examples.




Reply Parent Score: 4