Android 4.4.2 Breaks AppOps

I’ve mentioned in a post just a few days earlier my annoyance at Google’s burial of the AppOps feature in 4.4 and 4.4.1. With the release yesterday of 4.4.2 to Nexus 4 users I have noted with dismay that AppOps itself has been removed in its entirety. That’s right – a security feature that enabled somewhat granular control over what functionality an app could utilize on your device has been removed deliberately by Google with one of their product development boffins citing the reason being that it was being used by end users when it was merely a debugging tool.

Others have expressed outrage at this dumbing down of Android functionality with the EFF commenting on the issue. ZDNet today ran an article about the changes.

I have said it before and I will repeat myself here again just in case anyone missed it. Google doesn’t want the end users to be able to granularly configure application privileges. Android makes its money through Google Play purchases and app developers in particular are very fond of using advertizing networks to monetize an ostensibly “free” app. Of course, the app isn’t truly free and the user is instead trading their privacy, bandwidth and screen real estate to the advertising network. By being able to easily toggle coarse location and internet access such a built in ad serving platform in, say a flashlight would be rendered inoperable and this makes the app developers angry. Never mind the fact that you own the cellphone.

A truly gutsy Google would go further than the AppOps we saw in Jellybean and provide a truly granular permissions management system both at install time and post installation within the “Apps” section of the Settings applet. On downloading an app from the Play Store a user could simply click Install or alternatively click Customize. This would provide a boilerplate warning that this could cause unintended consequences (or perhaps enable this feature only if the phone has developer mode enabled) and then allow the user to toggle all of the permissions listed. Simple. There is no technical reason why this cannot be done.

Until Google gets their act together and starts showing their users some respect (and this may never happen, given second to Facebook they are perhaps one of the most dangerous companies on the internet when you consider the quantity of data they have on each user. Telling us they won’t “be evil” doesn’t ease my suspicions one bit when they have been caught assisting the NSA, voluntarily or otherwise I believe any company with morals would alert the world of this disgrace even if it meant risking imprisonment of the board – Lavabit and Cryptoseal’s handling of this issue was flawless) I believe the only option privacy conscious users have is to use a custom ROM that allows more granular control or install the XPosed framework which will allow you to use the excellent XPrivacy.

I should note that privacy conscious users should avoid using a cellular phone if at all possible. Even if you eliminate all of the risks endemic to Android (which isn’t that difficult – you can remove the Play Store, all Google Services and sideload a few trusted apps and update them manually via adb strictly when necessary) you still have the baseband to worry about. The modern cellphone will betray your location via GPS if interrogated thanks to the E911 mandate (yes, of course radiolocation would be possible even if the phone wasn’t cooperating but actively sending GPS coordinates is a hell of a lot more accurate. If the service could only be enabled if a 911/112 call was recently initiated then perhaps it is excusable but unfortunately this is not the case) and can also be instructed to covertly auto answer, providing a level 3+ adversary with a listening device on your person even without physically planting a thing. The phone and the baseband communicate via a pseudoserial port using the antiquated Hayes AT command set. It has become a weekend project of mine to learn more about possibly the least researched part of the cellphone stack.