Hidden “App Ops” Feature in Android 4.3 Lets You Disable Permissions From Apps(droid-life.com)
droid-life.com
Hidden “App Ops” Feature in Android 4.3 Lets You Disable Permissions From Apps
http://www.droid-life.com/2013/07/26/hidden-app-ops-feature-in-android-4-3-lets-you-selectively-disable-permissions-from-apps/
13 comments
and badly-behaved apps will simply refuse to run without all the permissions they (and their ad services) request.
With any luck, those apps will (rightfully) die do to lack of user base. Of course, the cynic in me knows that the unwashed masses will never go to the trouble of dealing with all those permissions, even if they know about them.
BTW, what do you consider "badly-behaved"? I've seen so many "good" apps ask for so much it boggles my mind (as someone else mentioned, WTF does a music player need access to your addressbook?).
With any luck, those apps will (rightfully) die do to lack of user base. Of course, the cynic in me knows that the unwashed masses will never go to the trouble of dealing with all those permissions, even if they know about them.
BTW, what do you consider "badly-behaved"? I've seen so many "good" apps ask for so much it boggles my mind (as someone else mentioned, WTF does a music player need access to your addressbook?).
> BTW, what do you consider "badly-behaved"? I've seen so many "good" apps ask for so much it boggles my mind (as someone else mentioned, WTF does a music player need access to your addressbook?).
Any app which requests a permission whose use isn't instantly obvious from the nature of the app. "Full network access" for a non-multiplayer game. "Location access" for anything that isn't a mapping app or point-of-interest finder (and even the latter ought to allow manual zipcode entry or similar). Contact access for any non-communications app. Phone state access for almost any app that isn't an dialer or call-control management app.
A music player that asks for access to your contacts would fall squarely under "badly behaved".
Any app which requests a permission whose use isn't instantly obvious from the nature of the app. "Full network access" for a non-multiplayer game. "Location access" for anything that isn't a mapping app or point-of-interest finder (and even the latter ought to allow manual zipcode entry or similar). Contact access for any non-communications app. Phone state access for almost any app that isn't an dialer or call-control management app.
A music player that asks for access to your contacts would fall squarely under "badly behaved".
There are some valid use cases for this. "Read All Contacts" is often required to optionally invite your friends. "List running Apps" for crash-reports.
Why can't some permissions be prompt-based, instead of always giving access to apps? Say for contacts, if you want to invite friend you'll allow access to contacts just now.
This is what Mozilla does lately with new HTML5 capabilities in Firefox (e.g. desktop notifications, camera access, location access, local storage), and presumably is also how Firefox OS works. I agree, it's a nice way to do things.
for that matter, it's also how Chrome/Chromium/Chrome OS work.
This is how iOS does it, and I agree, Android should copy this feature.
Here's a thought: permissions shouldn't be asked for until they are needed, and one that should be disabled with no option to override is to spam your entire addressbook.
Just by accessing the addressbook you already have the means to spam everyone, if you are a bad actor.
To prevent that from happening you've got to deny access to the addressbook altogether, which isn't desireable if you don't want to kill the market for Voip/Chat on mobile phones.
Apps like Whatsapp, or the Voip/Xmpp client I am working on for my company just need a way to determine who on your contactlist is available for chat/Voip via your app.
Also: how do you think that apps like Skype enable you to call some landline number for a cheaper rate? They do this by creating a local dialin number that routes the caller to the actual destination.
What could work is that the OS gives hashes instead of the real numbers to the apps, but that would suck for anyone that had a web service that needs those numbers. (for say creating a cheaper dialin number to call some of your contacts)
To prevent that from happening you've got to deny access to the addressbook altogether, which isn't desireable if you don't want to kill the market for Voip/Chat on mobile phones.
Apps like Whatsapp, or the Voip/Xmpp client I am working on for my company just need a way to determine who on your contactlist is available for chat/Voip via your app.
Also: how do you think that apps like Skype enable you to call some landline number for a cheaper rate? They do this by creating a local dialin number that routes the caller to the actual destination.
What could work is that the OS gives hashes instead of the real numbers to the apps, but that would suck for anyone that had a web service that needs those numbers. (for say creating a cheaper dialin number to call some of your contacts)
For apps that are explicitly used to contact people, sure, accessing the addressbook is assumed. But there should not be an option in any app to "tell everyone in your addressbook about this app!", and apps that do this behind the users back (or worse, mine addressbooks for email addresses) should be outright banned. There's a reason I hand out individualized email aliases, even to friends: far too much risk that they will leak the address, intentional or otherwise, and I can disable the alias at a whim.
This will very likely simulate full permissions, or it would be useless.
> badly-behaved apps will simply refuse to run without all the permissions they (and their ad services) request
If this were true it would be an issue on iOS. Its not.
If this were true it would be an issue on iOS. Its not.
On iOS, if an app crashes or doesn't function when permissions are denied, it won't get approved to be in the app store.
The app does not have to crash. It can gracefully exit.
Which, in the end, has the same result - if the user does not grant the permission, the app will refuse to work.
Which, in the end, has the same result - if the user does not grant the permission, the app will refuse to work.
I admittedly don't download much of the App Store's free crapware, but I've never once seen this happen. Do you have an examples of apps that refuse to run when you don't allow a unnecessary permission?
Sorry for late reply. For example, Any.do Cal will exit, if you do not grant access to addressbook.
I do not download crapware either, but I don't have much trust into bizdevs trying to monetize anything. This is the first solution that I would expect.
I do not download crapware either, but I don't have much trust into bizdevs trying to monetize anything. This is the first solution that I would expect.
Well-behaved apps won't ask for permissions they don't need anyway
I would say that this is close to universally untrue -- apps generally ask for permissions that cover the superset of all possible edge conditions, even though only a subset of their users will ever actually need that.. If I'm someone who will never use the contacts feature, for instance, I would love to have the option -- on install -- of saying "Yeah, I understand you want that but no, you aren't getting it". This is a step in that direction.
I would say that this is close to universally untrue -- apps generally ask for permissions that cover the superset of all possible edge conditions, even though only a subset of their users will ever actually need that.. If I'm someone who will never use the contacts feature, for instance, I would love to have the option -- on install -- of saying "Yeah, I understand you want that but no, you aren't getting it". This is a step in that direction.
Fantastic. I barely have any apps on my phone because I refuse to accept the egregious abuse of privacy (why does Pandora or Yelp need to access my contacts etc). Recently some friends recommended WhatsApp, but after seeing the massive wall of permissions it was requesting, I didn't install.
I've been waiting for this feature since the day I got my first android phone.
I've been waiting for this feature since the day I got my first android phone.
What I really hate is that you can pay for and install an app with an acceptable set of permissions, and then later the developer can add new unacceptable permissions essentially changing the product you bought. You can try to defer installation of the new version for a while, but it gets increasingly difficult.
I am of the opinion you should be offered a refund/uninstall if new permissions get added. Or have a way of disabling them like the posting is about.
I am of the opinion you should be offered a refund/uninstall if new permissions get added. Or have a way of disabling them like the posting is about.
It would be nice if there was also a "simulate" option for some permissions. That way the app would think it has a permission when it doesn't. It could return an empty phonebook for contacts or random location for GPS or confirm a SMS was sent when it never went out, etc.
That's exactly what Privacy Guard in CM does.
https://plus.google.com/+CyanogenMod/posts/86LLXrDpVWY
https://plus.google.com/+CyanogenMod/posts/86LLXrDpVWY
Too bad CyanogenMod itself phones home to tell the developers about you.
Only if you opt into it. It's an option under settings. They also tell you what they're sending. If you're truly paranoid, just block Google Analytics in your host file. That's all they're using.
No, it's opt-out, unless the developer's changed his mind:
http://www.androidpolice.com/2013/04/03/cyanogenmod-will-no-...
And, if he does change his mind, it's more likely to be to remove the opt-out feature.
People don't expect Free Software to phone home like common malware. It's shocking. That's why I mentioned it.
http://www.androidpolice.com/2013/04/03/cyanogenmod-will-no-...
And, if he does change his mind, it's more likely to be to remove the opt-out feature.
People don't expect Free Software to phone home like common malware. It's shocking. That's why I mentioned it.
Of all the privacy intrusions you're subjected to, are you seriously making an issue out of optional, transparent, anonymized hardware reports, in a Free Software project, used to compile publicly available statistics[1] on what phones people use the software so the devs can better direct development effort? Really?
[1] http://stats.cyanogenmod.org
[1] http://stats.cyanogenmod.org
I mentioned it because it's shocking that a Free Software project would be so disrespectful of user privacy.
Oh, and it isn't opt-in. It's opt-out, until the developer changes his mind again:
http://www.androidpolice.com/2013/04/03/cyanogenmod-will-no-...
Oh, and it isn't opt-in. It's opt-out, until the developer changes his mind again:
http://www.androidpolice.com/2013/04/03/cyanogenmod-will-no-...
The title of this post is misleading. App ops works exactly like that: it does not disable the permissions themselves but turns those API's into no-ops or returns dummy data from them. Aside from implementation bugs (like [1] which has killed my app completely) it should theoretically have no breaking effects on apps.
[1] https://code.google.com/p/android/issues/detail?id=58043
[1] https://code.google.com/p/android/issues/detail?id=58043
This was a research project at my university a while ago: http://news.ncsu.edu/releases/wms-jiang-tissa/
This is an absolutely amazing feature. I've yearned for this for years, I hope it will arrive soon. Some apps just don't need the permissions they request, or I don't want to give them, or I don't want to use the functionality that needs it. This would allow me to disallow my bookmarking app from reading my contact list.
Fantastic.
Fantastic.
I really like that Google have added this feature, but unfortunately I don't see it helping things much. I'm willing to be that many of the applications requesting odd and unnecessary permissions will be rewritten to simply not work when any one of those permissions aren't granted to them.
I'm willing to be that many of the applications requesting odd and unnecessary permissions will be rewritten to simply not work when any one of those permissions aren't granted to them.
Good. Let them die. If there's really demand for them, better alternatives will pop up.
Good. Let them die. If there's really demand for them, better alternatives will pop up.
It could be using the same strategy as cyaogenmod's Privacy Guard - when enabled, return junk data to that application. (gps at 0N,0W, contacts list empty, etc)
Many programs already won't work since they assume that they have the permissions they asked for.
Heaven forbid your app does error checking!
It does error checking. Would you write a program that constantly checks the config file to see if something changed, or to see if the euid it is running as suddenly changes? Of course not, why would you? And why would an Android app constantly check to see if the permissions it has been granted are suddenly un-granted?
More to the point: why would an app ask for permissions it didn't need in the first place? The most likely thing to happen is that the app would be useless.
More to the point: why would an app ask for permissions it didn't need in the first place? The most likely thing to happen is that the app would be useless.
"More to the point: why would an app ask for permissions it didn't need..."
Ad networks. So wrap the calls to the ad network library in try/catch, and, in most cases, that takes care of the mostly gratuitous permissions.
Ad networks. So wrap the calls to the ad network library in try/catch, and, in most cases, that takes care of the mostly gratuitous permissions.
Or the Ad network code should handle this gracefully?
Not that I'm sympathetic to ad networks that data rape you to support some half-baked behavioral targeting, but one reason they don't now handle it gracefully is that SecuirtyException should in most cases be unhandled, because it would indicate some kind of defective installation. That's why this change has to be phased-in.
Android as a framework is designed in such a way that most of the times you wish to access a feature of the device requires a permission you should be using components that can enforce a security check with the PackageManager or can handle the SecurityExceptions generated from not having a permission. Poorly architect-ed apps will have an issue with this, but those apps already have problems.
No. The Android API has always given the guarantee (and it still does) that your application's permissions will always be there. They can't be revoked during runtime. If it's in the manifest, it's perfectly fine to assume that you have it.
No piece of documentation or sample code has ever encouraged a pattern of "checking if your app has permission X or Y" because it's a total waste of time. Likewise, none of the built-in Android apps or any of the open-source apps from Google developers I've seen do that. There is no point to doing so.
In fact, it's actually bad practice because you're adding a bunch of error checking code for an error condition that's never going to happen. If you're getting a SecurityException for an action that you've explicitly requested the permission for, you're running on a broken API and it's not your responsibility to handle that.
The framework does include methods for checking permissions, but they are generally meant for things like inter-process communication and library code. There's no need to use them for ordinary applications you are building yourself. And nobody does that, rightfully so.
No piece of documentation or sample code has ever encouraged a pattern of "checking if your app has permission X or Y" because it's a total waste of time. Likewise, none of the built-in Android apps or any of the open-source apps from Google developers I've seen do that. There is no point to doing so.
In fact, it's actually bad practice because you're adding a bunch of error checking code for an error condition that's never going to happen. If you're getting a SecurityException for an action that you've explicitly requested the permission for, you're running on a broken API and it's not your responsibility to handle that.
The framework does include methods for checking permissions, but they are generally meant for things like inter-process communication and library code. There's no need to use them for ordinary applications you are building yourself. And nobody does that, rightfully so.
I'm not suggesting that apps do this or even if it is a good idea to have this level of security checks in code. Rather, the Android framework encourages decentralized pieces of code that revolve accessing various capabilities of the API. The kind of paradigms in Android could be considered to be already a bit helpful in that they promote certain kinds of application architecture that may be more easily adapted to doing such security checks.
Ultimately it is a matter of time before something like this does make its way into the core features of Android. It is worth thinking about how Android is both deficient and helpful with its design philosophy regarding that eventuality.
Ultimately it is a matter of time before something like this does make its way into the core features of Android. It is worth thinking about how Android is both deficient and helpful with its design philosophy regarding that eventuality.
Handling an exception is one thing. Designing your app to work gracefully with random permissions denied sounds like a combinatorial explosion of testing and UI design.
It's not very bad on Android. The framework really pushes for a kind of plug-in like architecture where you abstract your core components into things like Services, so thinking about those core features up front goes a long way to creating a common point to handle permission checks. If all else fails, an app could simply extend Application and check permissions at runtime.
I'm sure this was a 'hidden' feature as it wasn't ready for it's prime time. I would expect developers to receive a notification that they need to update applications to support this - or things will be made to simply fail softly to begin with.
Yeah, Google needs to return random or plausibly zero/empty data when a user has disabled the permission. Some Android distros already offer this.
This is a good way to introduce this feature.
Developers: You are now on notice to handle SecurityException and fail soft. in most cases, this should be easy to do, and when it isn't, you can, at least, post a dialog that says" "This app really needs SOME_PERMISSION in order to run."
But since it is hidden, you are not on the hook, yet, to support users that start making use of this feature.
Developers: You are now on notice to handle SecurityException and fail soft. in most cases, this should be easy to do, and when it isn't, you can, at least, post a dialog that says" "This app really needs SOME_PERMISSION in order to run."
But since it is hidden, you are not on the hook, yet, to support users that start making use of this feature.
More info for devs from Mark Murphy/Commonsware:
http://commonsware.com/blog/2013/07/26/app-ops-developer-faq...
http://commonsware.com/blog/2013/07/26/app-ops-developer-faq...
This removes one of my pet peeves about android. Now please allow users full control over uninstalling non system applications. I hate that I cannot uninstall Facebook and Twitter on my HTC one. My past Droid Charge by Samsung (on Verizon) was even worse since it installed a whole bunch of useless applications that I had no way to uninstall. I hated that phone every single time I used it.
That's on your carrier/manufacturer, not part of Android itself.
It shouldnt be on the carrier / manufacturer. Whats innately different about the software on phones as compared on Windows / OSX / linux ... that the user cant be trusted with administrative rights on their machine?
Uhm, yes, that, precisely. Most of Android is on a level playing field - core framework services get elevated permissions under the system group but they're still apps. If you let the user uninstall them, all hell will break loose. It's like removing the svchost.exe process in Windows. Or removing /bin/sh in Linux. The rest just doesn't work without it. Things like Contacts, Calendar storage, Bluetooth, Play Store, Google Backup, etc, etc, are all in /system/app, where manufacturers also put their apps.
If you ask me, manufacturers should be prohibited from adding to /system/app but that's not how the Android licensing works. So, we get un-uninstallable apps (vote with your wallet - buy only Nexus experience!).
If you ask me, manufacturers should be prohibited from adding to /system/app but that's not how the Android licensing works. So, we get un-uninstallable apps (vote with your wallet - buy only Nexus experience!).
Learning the nexus lesson slowly.
With 4.1+ Jelly bean, you can at least disable the system apps. That way, the only thing you are losing is some storage.
This is exactly the feature I've been waiting for to update my old Facebook app install. Ever since they launched FB Home, the normal Facebook app has asked for exorbitant permissions including the ability to see all the apps I have installed and running and even draw on top of them. I've refused to update to that version because I don't want to use Home, and those permissions could easily have been restricted to just the Home application.
As others have mentioned I'm sure some app developers will resort to just erroring out if they can't access something they asked permission to access, but hopefully we'll be able to shame the bigger players away from that.
As others have mentioned I'm sure some app developers will resort to just erroring out if they can't access something they asked permission to access, but hopefully we'll be able to shame the bigger players away from that.
This looks very useful. The Android permission system is pretty good from a technical point of view, but since a lot of apps just require all permissions regardless, and people are trained to disregard this when installing, it's almost moot.
I wonder if Google is using requested permissions in Play rankings. The apps which require _all_ permissions should definitely be ranked lower.
I wonder if Google is using requested permissions in Play rankings. The apps which require _all_ permissions should definitely be ranked lower.
This lets you take those permissions away retrospectively. In many cases I suspect you will find it is a free app's ad network that's asking for ridiculous permissions, e.g. access to location in a flashlight app.
Google is probably reluctant to do things that "harm" competing ad networks for fear of getting sued.
Google is probably reluctant to do things that "harm" competing ad networks for fear of getting sued.
It would make little sense for the finished feature to work retrospectively; apps would just grab the bounty on first launch and then the harm is done before you can get to the settings screen. This looks more like the screen you'd go to if you change your mind about an app. I expect the primary control for this feature to be a just-in-time dialog, similar to permission popups on iOS.
Didn't Google threaten to pull CyanogenMod's ability to distribute Google Play for implementing the same thing a while back?
Citation needed?
Being stuck with old phones has its advantages. My phone only runs CM7, which has this very same feature for some 2yrs.
It's called app goggles or something.
I block internet access to lots of apps thatdo not need,it. And most of them crash when they try to use it.
Eg. Swype tries to connect every time i reboot my phone. Not sure if they are just checking for updates or uploading my personal dict, but since it doesn't try to upload anything while I'm actually writing, i just watch it die every reboot and that is it.
Almost all games i tried i removed access to see running apps and contact list. Very few crashed, meaning they probably expose those api to ads, and they are not using them yet.
It's called app goggles or something.
I block internet access to lots of apps thatdo not need,it. And most of them crash when they try to use it.
Eg. Swype tries to connect every time i reboot my phone. Not sure if they are just checking for updates or uploading my personal dict, but since it doesn't try to upload anything while I'm actually writing, i just watch it die every reboot and that is it.
Almost all games i tried i removed access to see running apps and contact list. Very few crashed, meaning they probably expose those api to ads, and they are not using them yet.
Permissions is the reason why I do not have Facebook installed (specifically the GPS).
Well-behaved apps won't ask for permissions they don't need anyway, and badly-behaved apps will simply refuse to run without all the permissions they (and their ad services) request.
Without the ability to pretend to have the permission but not actually provide useful data, this really won't help much.
On the bright side, at least a subset of these do behave in the sensible way: various reports suggest that calendar and contact accesses will successfully return empty results rather than erroring out, for instance.