Google Yanks Buried Android Privacy Feature

Google removes an undocumented App Ops control panel from its latest release, Android 4.4.2, that had let users choose which app permissions to enable.

Google Barge: 10 Informative Images

(click image for larger view)

Google, in its Android 4.4.2 release a week ago, removed an undocumented, experimental privacy control panel that had been released inadvertently in July as part Android 4.3.

The control panel, called App Ops, allowed Android users to deny the availability of selected permissions in an app. Though it was not accessible to users without some technical knowledge, it was immediately noticed and made available through Android apps that provided shortcuts to the hidden interface.

App Ops turns Android's permission model on its head. Instead of allowing the developer to present a list of requested (and generally necessary) permissions to the user for all-or-nothing approval, the control panel allowed users to disable certain permissions while leaving others in place.

In a blog post Wednesday, Peter Eckersley, technical projects director at the Electronic Frontier Foundation, praised App Ops Launcher, a third-party shortcut app to App Ops, as "a huge advance in Android privacy." He lauded the Android engineers for "giving users more control of the data that others can snatch from their pockets."

Upon learning that Google's most recent Android update had eliminated the celebrated feature, Eckersley reported that Google said the feature had been released "accidentally" and had been withdrawn because it could break some apps. "We are suspicious of this explanation, and do not think that it in any way justifies removing the feature rather than improving it," he said in a second blog post.

When asked to explain the situation, Google declined to comment.

This is not the first time experimental code has come back to haunt Google. In 2010, when it disclosed that it had been inadvertently collecting WiFi payload data through its Street View cars, Alan Eustace, senior vice president of engineering and research, attributed the lapse to experimental WiFi data-gathering code that had been added to a project designed to collect a narrower, less sensitive set of data about WiFi network characteristics. To address the issue, Google conducted an internal review of its procedures "to ensure that our controls are sufficiently robust to address these kinds of problems in the future."

Perhaps Google's explanation would be less subject to suspicion if the company said that the unfinished software had been accidentally discovered, rather than accidentally released. That shifts the scenario from inattentive engineers to wily users.

Giving users control over an app's ability to access location data and contact data, to post notifications, to use the camera, and so on might have privacy benefits, but doing so also raises issues about where user rights start interfering with developer rights. Should app users have an easy way to deny, say, location data to a game designed to depend on it, like Google's Ingress, thereby rejecting the take-it-or-leave-it permissions request presented by the app maker? There are other issues, too, such as potential increased support costs when users revoke a necessary permission and then seek assistance to restore their no-longer-functional app.

Google had to confront this issue in AdBlock Plus, which it banned from Google Play for interfering with the functioning of other mobile apps. App alterations, whether they aim to block ads, revoke permissions, inject data, or alter an interface, often can be accomplished by the technically skilled. Usually, this isn't a problem. But when it becomes simple enough for anyone to do, and it presents problems for developers or platform owners, you can expect some friction.

Coincidentally, the software engineers working on Google+ might have already come up with an answer in the form of incremental authentication, a more granular approach to permissions. Android engineers, take note.

Thomas Claburn is editor-at-large for InformationWeek. He has been writing about business and technology since 1996 for publications such as New Architect, PC Computing, InformationWeek, Salon, Wired, and Ziff Davis Smart Business. He is the author of a science fiction novel, Reflecting Fires, and his mobile game Blocfall Free is available for iOS, Android, and Kindle Fire.

IT groups need data analytics software that's visual and accessible. Vendors are getting the message. Also in the State Of Analytics issue of InformationWeek: SAP CEO envisions a younger, greener, cloudier company (free registration required).

As a professional software developer, any time I forcibly remove choices and control from my users, I do them a disservice. Yes, some users need heavy-handed automation and guidance. Those can certainly be defaults, but a user who desires to take matters into their own hands, once sufficiently warned, has every right to expect me not only to "allow" such activity, but also not to force my will upon the user by purposefully removing their choice.

As a consumer, no developer or manufacturer can or should tell us what we will or will not do with anything we purchase from them, specifically the hardware we buy which is our personal property after the sale is complete and solely our own to do with whatever we please. Period. The mere concept of a manufacturer thinking that they could possibly dictate or control capriciously what someone does or does not do with their hardware is ludicrous, insulting, and above all - futile and pointless.

I have no desire to materially harm any manufacturer or developer in any way (though I fantasize about choking the crap out of many of them). This is why I am so very much a fan of the Android AOSP, and the excellent work that has been done by teams like CyanogenMod and individuals like ChainFire and Koushik Dutta. Some manufacturers like HTC seem to have at least some notion that it is not antithetical to profitability to work with their customers and fellow developers who want to explore the hardware (HTC directly provides SDKs, APIs, and tools for rooting their devices), instead of against us (Samsung S4, anyone?). I applaud those manufacturers who have caught on, and I invite others to do the same. C'mon! Jump in. We're not sharks. We don't bite (too hard), and the water is fine!

To expand on George_B's post, I have had to pass over the most functional app because it asked for unnecessary permissions (like access to the Android system log) and the developer basically did not care to listen. Without rooting the phone, carrier-installed bloatware cannot be uninstalled. Even if there is rational for specific permissions, it appears that ad delivery libraries inherit the permissions of the app (http://mostconf.org/2012/papers/27.pdf) and I definitely do not want them poking around my phone. Google needs to step up to the security issues with Android, from misuse of permissions to the glacial pace of upgrades from carriers.

Being able to control app permissions has been a feature of CyanogenMod for years. Google and handset carriers are likely not going to release this feature because it gives users too much control in their eyes and yes it can break apps. Carriers want to be able to install their bloatware and by allowing users to control app permissions you can render any app unable to auto start or access the internet which is something carriers and app developers don't want you to be able to do.

Every free app that comes with ads can have their internet permissions taken away so ads never load. This is great for games and other apps that don't need the internet to function.

Having issues with apps starting by themselves that you don't want/use? You can take away their permissions to start themselves and their permissions to see the phone's state even if you can't uninstall them you can essentially disable the app by cutting off the permissions.

Many app permissions seem to over-reach what the app should really need access to. Do simple phone games really need to be able to see my contacts, call history, use the camera, etc.? Most of the time no and disabling these permissions is a great way to protect yourself especially when there are many malicious apps out there.

I will agree with Google that you can break apps. If you take away Facebook App's ability to use the internet the app won't work and an inexperienced user might not understand how to correct an issue caused by taking away permissions. It is certainly something for Advanced users.

This is one of the many awesome features of CyanogenMod and I'm sure other mods for Android too. I base my buying of Android phones based on which models are supported by CyanogenMod and this feature is one of the main reasons why I use CyanogenMod over Vanilla Android, HTC Sense, Motoblur, or any other Carrier/Manufacturer variations.

Our data shows these innovators using digital technology in two key areas: providing better products and cutting costs. Almost half of them expect to introduce a new IT-led product this year, and 46% are using technology to make business processes more efficient.

Among 688 respondents to our Mobile Application Development Survey ó up from 350 respondents in 2012 ó 46% have deployed mobile apps, with an additional 24% planning to in the next year. Whatís the holdup for that remaining 30%? Often, itís a lack of expertise.