AppOps could have broken a lot of Android apps

Had Google not rolled back the functionality that allowed AppOps to find and shut down app permissions, it could have had a big problem on its hands.

Was Google’s recent rollback of its experimental code that allowed independent developer Sylvian Galand to build AppOps and give Android users greater personal privacy a violation of social principal? The post, Google Removes Vital Privacy Feature From Android, Claiming Its Release Was Accidental, by the Electronic Frontier Foundation (EFF) retracting the accolades it lauded on Google would lead one to believe so.

Galand’s app was likely a good outcome for Google, except for its public release. After all, open source is open source. Google owes much of Android’s dominant market share to it. App developers can look at Android’s source and create better apps and contribute improvements to the Android OS to Google. Based on Galand’s public profile on Slideshare and Github, he is an accomplished developer and a person Google would want to experiment with the permissions code and share his insights.

AppOps is important because some developers aggressively require unnecessary permissions that can be used to misappropriate personal information. Galand cited in an email the Brightest Flashlight app as an aggressive use of unnecessary Android permissions. Brightest Flashlight lets a user use the camera’s flash LED as a flashlight. But this app requires the user to allow the developer, Golden Shores Technology, access to location, phone call logs and full network access that are obviously unnecessary for a flashlight app. Ironically, many users accept these permissions; Brightest Flashlight has been downloaded 50 million times and has a five-star rating from over 1 million users.

Brightest Flashlight’s use of permissions points to the attractiveness of AppOps; the permissions not essential to the app’s flashlight function can be disabled. But depending on the app, changing the permissions could break the app.

There is a good reason Google rolled back this capability. One million apps are available on Google Play. Identifying which apps would break after users change permissions is impossible because it is impossible to know how the developer built the app. If the app developer has not accommodated the exception of a user disabling permissions, the app might fail. This could occur innocently by a to-do-list app that checks location to see if a user is near the grocery store before it pushes a reminder notification to buy milk. The app breaks, and the app developer receives a flood of angry emails.

Open source developers are passionate people, mostly smart, articulate and committed.The consequence of this accidental release could be unpleasant if permission editing apps such as AppOps were downloaded at a large scale, causing apps to fail. Many users would be inconvenienced and undoubtedly a large group of angry app developers would contact Google Android to complain, “you broke my app!”

Google confirmed that this experimental code was inadvertently added in Android 4.3 and was removed in the latest 4.4.2 update. The experimental code was neither user-facing nor documented for developers, so how Galand found it speaks to his expertise as a developer.

If this permission editing feature were to move beyond its untested and experimental status to release, Google would have two choices. It could ask all app developers to rewrite part of their apps and in turn push updates to all the app users, which would be a burden to developers. Or Google could socialize this experimental code with internal and external developers and use their feedback to build a production release that would not break apps. The latter is the likely explanation for how this experimental code became public.

It is unclear what Google will do next. Google tends not to preannounce its plans. Over a year ago it implemented improvements to detect potentially harmful apps in both Android and Google Play without an announcement until it went public in October with supporting data from 1.5 billion app installs.

Google’s rollback was not a violation of a social principle. An oversight in either Google’s Android 4.4.2 build or its socialization of this experimental code allowed it to become available.

We should be grateful to the EFF for its fierce advocacy for our personal privacy. They advocate about much bigger issues against the likes of the NSA. The EFF has brought multiple law suits against the NSA to challenge its methods of surveillance.

Brightest Flashlight is a free app. The unnecessary permissions required by its developer appear to be used to enhance and measure this advertising and probably does not harm the user. So the user is paying for the flashlight app with personal information. Though users should know, apps like these are not free and are paid for with privacy.

In the meantime, a user can review app permissions after downloading the app and before installing to decide if he or she wants to go ahead with the installation.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:
Must read: Hidden Cause of Slow Internet and how to fix it
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.