Google accidentally allows users to control apps access in Jelly Bean, but kills the feature in KitKat
Android KitKat release included a new privacy feature that allowed users control how apps can access their personal information and phone functions. However, we did not have a chance to rejoice for too long because Google took the feature away from us. It turns out Google did not even intend to roll out this feature, so it happened by accident, and in a few days it was removed. The blunder has made some noise on the Internet, and unhappy users and tech experts argue who is to blame.
How to control apps permissions in Jelly Bean 4.3
1) Jelly Bean 4.3 had this experimental app-control feature in July 2013 when Jelly Bean was released. However, it was not accessible for regular users because it was not in the standard Android interface, so most users did not even know it was there. Thanks to some open minded developers, who created app-style shortcuts to manage apps permissions, the feature became known. AppOps Launcher by Pixel Monster, for instance, has been downloaded 10.000+ times, if the Google Play statistics are accurate.
2) Root your device, but consider all pros and cons of a desperate measure.
Too Late If You Updated to KitKat
However, Android 4.4.2 KitKat update killed the feature so the shortcuts won’t work leaving users defenseless, as usually, against apps requesting permissions they do not need to function, but just because Google makes them entitled to breach users’ privacy.
The experimental code in Jelly Bean allowed users control what functions of the phone and stored data can be accessed by applications they install on their devices. For example, if you don’t want a game to be able to access your contact list, you can use the permissions manager to deny this particular app the access to your contacts. Since these ridiculously frivolous privileges aren’t necessary for most apps to function, your actions won’t affect their performance. Simple and transparent, isn’t it? So, why Google kept it secret and removed from KitKat altogether?
Apps Permissions Debacle
The code was, or could have been, a huge step towards re-gaining user trust. The hypocrisy with the public letter to Obama certainly isn’t. Apps permissions has been a big deal in the anti-Google scrutiny lately. The Electronic Frontier Foundation project director Peter Eckersley wrote on the subject of apps manager disappearance in KitKat:
“The disappearance of App Ops is alarming news for Android users. The fact that they cannot turn off app permissions is a Stygian hole in the Android security model, and a billion people’s data is being sucked through. Embarrassingly, it is also one that Apple managed to fix in iOS years ago.”
Google’s response sounds lame – the feature was experimental and rendered some of the apps dysfunctional, so App Ops has been removed. Its release was an error in the first place. Does it even make sense that Google released its Android update with at least one untested and undocumented feature? The developers never saw any documentation from Google to be able to use the unsupported feature. Rumor goes that the feature shortly appeared in Jelly Bean as a result of the war between Diane Hackborn, an Android product manager, and Dave Burke. Allegedly, Hackborn removed it on August 1; Burke put it back the next day, so the release had it.
It is worth mentioning that the ability to turn off network access for apps and deny apps access to functions that are not core to their functionality are already available on CyanogenMod and some other Android-based variants. Google, on the other hand, has no plans to share the information about if or when the permissions manager feature would be available as a standard feature for all Android users.
Why Android is lagging behind Apple’s iOS in Privacy and Security?
Android framework program manager Dianne Hackborn says killing user control of app permissions was ‘fixing security holes.’ Let us summarize what we already know. Your smartphone knows more about you than any device and gadget you use: it goes where you go; it listens when you talk; it records when you text, it follows your physical location, apps you download and use, your Internet browsing activity, people in your contact list, emails, passwords, credit card details. If anyone should gain unlimited access to your smartphone, they would most probably find out how to control your life.
Smartphones are not just personal devices; they are intimate to users, with so much delicate information about their owners. And guess what – Google, as well as apps you install, have access to that information.
The British Information Commissioner’s Office has recently released app guidelines stating that the consumer awareness of this problem is growing. YouGov, commissioned by the ICO, has conducted a survey of 2.272 British citizens, 59% of which are downloading apps without reading terms and conditions, but 62% are highly concerned about privacy issue. More than 40% chose not to install applications that requested access to phone features and data storage due to privacy fears.
The main problem with Android is that it gives you no choice – if you want an app, you have to accept its sneaking and eavesdropping on you. Google is perfectly fine with the situation, but as a consequence users start publicly complaining about it online by downgrading apps in Google Play. OpenSignal, an app that feeds back data on signal strength in different locations, got highly criticized for requesting access to read contacts. James Robinson, OpenSinal’s chief technology officer said, “The decline is all due to poor ratings on Android 4.4, where the ratings have dived from 4.3 to less than 4 in under a week.”
The poor reviews are consistent about the same issue – nobody seems to understand why the app would want that much access, and everyone wants to be able to block it.
With the escalating consumer discontent with how big companies treat their private data, why is Google lagging behind Apple for more than a year, refusing to fix the issue and disallowing users to revoke permission granted to apps?
How Apple handles trouble
In February 2012, a social startup Path, used by iPhone devices, has been fined $800.000 for accessing and uploading user locations, contacts and device information to its servers. Before that, no one ever wondered what permissions apps for iOS were enjoying because the apps would not ask your permissions. They would just grant it to themselves when you install them. The FTC fined the Path; the Congress publicly sent an inquiry to Apple.
Apple did not take long to fix the problem: in September 2012, it rolled out iOS 6, which lets the users block apps’ access to system-wide functions and storage. In 2013, Apple added microphone to the list of controllable elements. Voila!
Google Does Not Seem to Care
It’s always ‘take it, or leave it’ with Google. Even the latest Brightest Flashlight disgraceful scandal did not affect Google much. There are thousands of Android apps that exploit Google’s all-allowing policy to harvest user data. NSA leak on mass surveillance and Google co-operation make perfect sense as to why Google refuses to grant users control over apps permissions.
Dianne Hackborn defended her actions in a Google+ thread “The architecture is used for a growing number of things, but it is not intended to be exposed as a big low-level UI of a big bunch of undifferentiated knobs you can twiddle.” This did not seem to answer the numerous questions on the thread from concerned users and developers asking for knobs they could twiddle for a very good reason. For example, Jon Sykes writes:
The Facebook app is a perfect example of an app I want to have, but refused to install on my phone because of the excessive permissions it wants:
Directly call phone numbers
Read call log
Write call log
Download files without notification
Retrieve running apps
Draw over other apps
Prevent phone from sleeping
Turn sync on and off
Send sticky broadcast
Not one of those is justified for Facebook to show me updates from friends and family. Being able to go in and turn them all off is exactly what Android needs to let users do.
iOS users are notified the first time an app is trying to access private data; iOS users can revoke apps permissions. Android users, especially developers and the technically savvy ones, cannot count on such liberty.
On the contrary, Hackborn’s answers clearly reveal her disdain about the fact that common users even dare think about more user control over harvesting data in Android. Hackborn insists App Ops exploited the feature to find security holes, except for the fact that they were not security holes. By removing the permissions manager, Hackborn did not make Android more secure, quite the opposite. Security holes, in fact, are Android features that allow apps siphon user data without restrictions.
Hackborn insists that revoking apps permissions hurts apps performance. So, if an app requires your contacts access to function normally, will it crash if you don’t have any contacts? What happens if your call logs are blank, but the apps necessarily need those to function? The fact that Android 4.3 Jelly Bean users who installed App Ops did not raise storms of complaints about apps crashing when restricted in permissions suggests that Hackborn’s explanation does not stand up the slightest scrutiny.
Worse, Android 4.2.2 KitKat will not notify users if apps permissions have been changed. Google’s position is more than transparent, though. Google derives its profits from pulling user data from smartphones, besides browsers in laptops and workstations. Smartphones’ sector has become one of Google’s vital drainpipes for deriving user information to target ads better. Android is merely a source of income and your data converts to Google’s income, so face the facts – Google wants your data.
iOS devices running OS 6 which enables users to revoke apps permissions constitute 96% of iOS users. Compare that to Android 4.2.2 KitKat users, a remarkable 95.8% of users that do not have that privilege, and make your own conclusions about both platforms’ approach to respecting user privacy.