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.
Oh my, Google’s little accident places them in quite a tough spot. They certainly don’t want to enable users to block collection while still running the apps since this could block google’s own data collection from apps as well…
The EFF has framed the issue extremely well; There’s no way google can come away looking like a good guy unless they give users back the privacy controls.
Edited 2013-12-13 16:34 UTC
EFF… and FTC :
http://bgr.com/2013/12/06/flashlight-app-sharing-data-illegally-ftc…
Kochise
Nixing privacy controls does make things harder.
Every application I install gives a list of permissions required before actually installing it. Just read through those. I absolutley have refused to install some applications that require unnecessary access to things like address books, etc. As long as that list of requested permissions remains during install at least there’s some way to tell what to kill.
Too bad some of the stupid google stuff that can’t be uninstalled wants permissions that I think are unacceptable.
bnolsen,
Yea, as an android user myself, I’d much rather be allowed to define my own information privacy policy than get a blunt choice to run (giving the app all the permissions requested by the author) or not to run at all. The app sandbox is very capable of fine grained privacy controls, so there’s absolutely no legitimate reason for the OS to force us to grant access to private numbers/contacts/etc just to run a program.
This would be a good opportunity to mention CyanogenMod Privacy Guard, since they don’t have the same conflict of interest that google has with regards to user privacy.
http://www.androidcentral.com/cyanogenmod-updating-privacy-guard-20…
If you have Jelly Bean or Kit Kat you can disable the Google apps. That’s built into the OS now.
As in don’t be evil, obvious? I mean if you live on Earth in 2013 and still trust corporations or governments, you need your head examined.
In WinRT the permissions are granted piecemeal at call time. So it doesn’t actually ask you for location permission until the app tries to access the Location API for example.
This lets users make a decision when it actually matters and when they’re less inclined to just click through the dialog.
You mean the same way UAC doesn’t?
Uh, sure. I guess.
Well, the warnings in WP are specific – “Needs location information,” “Needs access to your address book.”
Each one is different, short, and actually explains what is actually going on in a single line of text, while UAC prompts are none of these things.
Doesn’t change users’ behavior, unfortunately. Give them a click-through and they’ll click through it to get what they want.
It is easier to determine whether or not an app actually needs a permission once you’ve used it. If a calculator app is asking to upload all of your contacts, the user has already interacted with and come away with a reasonable expectation of what the app should be able to do.
It also like the poster below me mentioned allows for granularity in the permission model. From the start the API is designed to fail fast if the capabilities aren’t declared in the manifest and explicitly authorized by the user.
App developers code with this in mind which means that apps don’t blow up when specific permissions are denied.
Except that apps don’t ask for such permissions. They ask for very generic sounding things… like read your Camera Roll(or was it access pictures?) or Read your Contacts. It would be very stupid of the data pirates to actually tell you that they are uploading your data anywhere.
No, but to be fair it’s no better on Android: when people install applications via. the Play store, most people never read the security notice and just click the “Yeah, whatever, give me the app” button.
What happens if you decline the permission?
API returns an error, app can’t use functionality.
“API returns an error, app can’t use functionality.”
Absolutely, unfortunately the old all/nothing policy would have made this difficult for most developers to test. I still think it’s a bridge that must be crossed, better to do it sooner than later.
It’s not really such a complicated software engineering problem… I’d create a new app flag somewhere to enable/disable permission exceptions. New applications would throw exceptions by default for the developer to handle, old applications might return dummy data instead so they could continue running without breaking and without revealing private information which a user has opted out of sharing.
Edited 2013-12-13 21:47 UTC
I think its as simple as a manifest flag indicating call site grants vs install site grants for permissions.
If the permissions are a no opt at install time the the API will never throw an exception because it’ll always have the permissions.
If its the new, better granular mode then then the developer must know to check for unhandled exceptions.
A great side effect of this is that it allows revoking granted permissions after the fact, should, say a report come out saying XYZ app is shady.
I meant as a user, what happens if you decline?
Do most app writers just shutdown the app? Or do they gracefully allow you to continue using the ap, despite the fact that you declined its request to look at your contacts to spam all of them with an app related spamvertizement?
Do most apps ask everytime you want to perform the action it requests the permission, or are they typically configurable from a menu in the app/operating system?
It would be best to combine both methods, for the app to tell you upfront the permissions it will ask for, and for the app to ask when it wants to use something that will require that permission.
For now, I enjoy the Cyanogenmod method of configuring privacy settings in the OS. If you deny an app a privileged, it doesn’t know you denied it so it can’t exact its revenge.
If I’m getting multiple prompts for every app I install, that sounds like it could get incredibly annoying, very quickly.
disclaimer: I work for Mozilla
While working on Firefox OS I always found it’s permissions model far more reasonable than Android’s. 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. 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.
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.
[1] https://developer.mozilla.org/en-US/Firefox_OS/Security/Security_mod…
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.
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.
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.
[2] https://play.google.com/store/apps/details?id=com.twofortyfouram.loc…
[3] https://play.google.com/store/apps/details?id=se.badaccess.locale.nf…
[4] https://play.google.com/store/apps/details?id=com.twofortyfouram.loc…
More interesting than the permissions, what exactly is your FxOS phone? I seriously considered buying one recently, but can’t justify the cost/value proposition of the ZTE open when the Moto G is only twice as much…
I’m using an Alcatel One Touch Fire, IMHO it’s much better than the ZTE Open (more solid build, better screen, etc…) and costs about the same. More importantly it’s not hard to root it and roll your own build (see the links below).
Personally I’m using a 1.2 build I made myself which has quite a few extra features compared to the 1.1 version with which this phone ships and is also much faster; the underlying Gecko engine was bumped from version 18 to 26 across those versions and the JS engine alone is almost two times faster. This build is also almost fully stabilized, IIRC it will be finalized 1-2 weeks from now.
If you don’t feel adventurous though this phone should also get the 1.2 update from the vendor once they feel confident with it which probably means 3-6 months from now.
BTW the LG Fireweb is an even better device however it’s not available on the free market yet (it’s currently sold only in Brazil) and I am not yet aware of a method to root it in order to roll your own build.
http://k.japko.eu/alcatel-otf-hackers-guide-1.html“>Alcatel
https://groups.google.com/forum/#!msg/mozilla.dev.b2g/03-lhAr7Bm0/FO…
Could you write a review of your device? Or maybe a youtube video? If you are afraid of being biased maybe give it to a friend to review?
FirefoxOS is still very much mysterious.
I think I could make a review and in fact having worked on it I’m pretty good at pointing out flaws and limitations of the current devices. However it would be fairer to review the current shipping release which is 1.1. These devices will be updated to 1.2 (which I’m already using) but aren’t there yet and the jump between the two versions is quite significant.
What I have seen from FxOS 1.1 it feels like a test version. If this is wrong a review would be very nice. If this feeling is right I think it would be better to review 1.2 and just explain that this is a future version that will come out in a month.
Looks as though someone has posted a tool that re-implements the App Opps feature. Who knows how long Google will permit the app to remain on the Market.
https://play.google.com/store/apps/details?id=com.colortiger.appopsi…
**EDIT** Spoke too soon. It seems the app crashes on the latest Android 4.4.2
Edited 2013-12-14 00:01 UTC
The word scroogled has a new meaning. The good folks at NSA are happy I guess. They can protect the world from terrorists without doing any work. Just transform one of the most used app into a trojan.
And Google can collect more user data.
Edited 2013-12-14 02:18 UTC
It is no longer a word used by douche bags?
As an Android developer I understand Google’s choice. Android apps today expect all permissions to work when the app has been installed, and close to zero apps have implemented a way to deal with a denied permission post-installation. If I develop an app that uses a specific permission, and forget to declare that permission in the app’s manifest, it will crash when trying to use it. The same will happen if one disable a permission through App Ops in most apps when the permission is needed.
I would like Google to do something about the situation. Some of the more privacy-sensitive permissions could be asked when needed, iOS-style, like location, access to contacts, messages, call state, photos and of course sending messages and making calls. Permissions like access to network, should be allowed at install.
Until developers have updated apps to the new regime, Google should implement App Ops so that if the user disables a permission, the system provides dummy data, like telling the app that the user has no contacts if the app wants to read the contact list, or that the user is on the South Pole if the app asks for location…
Edited 2013-12-14 20:24 UTC
The only reason why Android exists, is to give Google access to everything in every Android device. A sane permission system would have either prevented that or forced them to add explicit exception for them to have access to everything. I guess that would have looked bad, so they just went with giving every developer access to everything (practically nobody pays attention to app permissions, let alone choose not install something because of them).
Cyanogenmod and Xprivacy is the solution:
https://github.com/M66B/XPrivacy
P.S: Use it and say: shut up f*cking G$$gle!
“Cyanogenmod and Xprivacy is the solution:”
Interesting, looks like it was available under the google app store at one point before google banned it. Still, at least android users don’t have to use google’s app store, we can still side-load software google doesn’t approve from other sources.