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, 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).
Then the thought - how do you image 360 - all street image data every 6 feet to make maps -
and not use everyone's wifi along the way to upload it all?
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, 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).
Then the thought - how do you image 360 - all street image data every 6 feet to make maps -
and not use everyone's wifi along the way to upload it all?