Slashdot Mirror
Google Cuts Android Privacy Feature, Says Release Was Unintentional
An anonymous reader writes "Peter Eckersley at the EFF reports that the 'App Ops' privacy feature added to Android in 4.3 has been removed as of 4.4.2. The feature allowed users to easily manage the permission settings for installed apps. Thus, users could enjoy the features of whatever app they liked, while preventing the app from, for example, reporting location data. Eckersley writes, 'When asked for comment, Google told us that the feature had only ever been released by accident — that it was experimental, and that it could break some of the apps policed by it. We are suspicious of this explanation, and do not think that it in any way justifies removing the feature rather than improving it.1 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.'"
One of Android's selling points has always been it's open nature, and the fact that it's not as locked down as iOS. This seems like it's taking a step in the direction of locking down the OS for the user, and unlocking it for everyone else...
I thought I read that they just pulled it out and into its own app, so that you'd have to seek out this feature. They wanted to keep folks who didn't know exactly what they were doing to stumble upon this and mess up their phones.
Gives granular control of app permissions. Requires Root, but it's worth it. I figured this change was never going to be permanent because it messes with Google's (and app developers') revenue stream.
> it could break some of the apps policed by it.
Is that not the entire point?
+----------------- | What is the question!
It always irked me when you install an Android app it often produces a big long list of the things the app can access, some of which you don't want it to, but you can't pick'n'choose the access permissions, it''s all or nothing.
That's just plain wrong.
And for Google to release an app which can allow you to set the access permissions of apps, and then withdraw it is even wronger (yes I know that's not a real word), even if changing some of the access permissions breaks the app there's the issue that many apps don't actually need to access everything on your Android device to run.
It was never a feature, people access it using a third party application that calls an Activity that is not normally accessible from the OS UI. It is like when people found initial semi-working code of multiple user profiles on Android 4.1, again not accessible to the users, and later releases added the feature when the code was completed and tested. I think we will see this feature enabled on later Android versions when they get to finish it and find ways to make old applications not crash when permissions are removed.
I wonder how many more overt measures that can be easily interpreted as pro-surveillance pro-advertising need google take, before the masses turn to alternatives like cyanogenmod etc.
I've been waiting for this for... forever. But not just [Enable]/[Disable], I also want [Produce random fake data] and [Produce data generated by external app hereby selected]. So that I can write or load an app that feeds intelligent but fake info to the others.
Non-Linux Penguins ?
Who is surprised?
That data is Google's entire business.
Especially the ones that slurp user data and send it back to the mothership, then whoever the mothership sells it to. I definitely see why they think it was not a good idea.
I grew fed up with android years ago. What kind of calculator app requires weekly updates? Dumbphones FTW
You'll be laughing on the other side of your face if we switch our number system to duodecimal or balanced ternary!
Better battery consumption? Optimization? There are lots of reason to update an application.
First of all, there was NO UI to activate this feature. The only access was through third-party apps that allow you to launch arbitrary activities (for those not familiar with Android, think application windows) in other apps.
So it was obviously unsupported by Google. The first thing I think of are Chrome's Labs at chrome://flags which carries this warning:
WARNING These experimental features may change, break, or disappear at any time. We make absolutely no guarantees about what may happen if you turn one of these experiments on, and your browser may even spontaneously combust. Jokes aside, your browser may delete all your data, or your security and privacy could be compromised in unexpected ways. Any experiments you enable will be enabled for all users of this browser. Please proceed with caution. Interested in cool new Chrome features? Try our beta channel at chrome.com/beta.
And THOSE are UI-exposed, unlike App Ops. The same warnings would apply to App Ops, if not worse.
Android permissions were built on the assumption that they were all-or-nothing: either the user would install the app and grant all permissions, or the user would deny the permissions and not install the app. It isn't like webpage permissions where the user may decline to allow a page to display desktop notifications or go fullscreen and the page can react to that.
Because apps expect permissions to always succeed, the common approach to making permission-limiting frameworks is to make the app think it still has permission by serving it dummy data, like an empty contacts list, or a blank image purportedly from the camera, so the app still operates.
Google is saying some apps were not compatible, which tells me App Ops still needs work, which explains why they have not formerly released it.
Some people have been using App Ops and now find the UI crashes when you load it, but the underlying feature is still applying the settings. Considering it was an unsupported and experimental feature this is not surprising, and it is not surprising Google removed access. Back when Google Chrome was brand new, occasionally Google would ship Dev builds that would crash on launch for a not insignificant portion of the user base. Such is the risk of alpha software (or in this case, an alpha feature).
Settings -> Cellular and then toggle off the apps you don't want using it. For apps you don't want using your location data, you simply deny them when the app runs the first time. If after the fact you want to deny them this permission you go to Settings -> Privacy -> Location Service and again toggle off the apps you don't want to have that permission. And guess what? None of the apps will crash due to these things being turned off.
The saddest part of your post is you probably thought you were going to completely baffle people with the question when these toggles have been part of iOS for years now (if not since the beginning).
There are reasons not to update as well: additional ads, removal of liked features. When I find an app and version I like I make a copy of the apk. Then if there is an update that I don't like I can always go back to the old version. I've had to do this with the local newspapers application as it has become bloated with ads, and crazy permissions.
The app is great in theory, but horrible in implementation. I checked out the App Ops functionality and if you don't know what you are doing you can cripple your phone. The problem is it allows you to change the functionality of system apps and core services by denying them access to the device *oops*.
I definitely think this is a needed feature, but it needs to be implemented at installation of apps from the play store. When an app says "We'll need the following permissions" the user should be able to toggle off each one they dont want the app having access to, then use the traditional permissions manager to modify it in the future.. From the App Ops, I learned that Angry Birds accesses your location when you run it. For what user-supporting function? None... There is no reason why it needs access to my location. My Grocery Store locator? That needs access to my location, but not my contacts.
The difference is that this is really critical functionality that should have been built in and tested from day one, but gets pushed way down the priority stack because of googles conflict of interest in the matter. So it's like that situation a little, but not really.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
I think we will see this feature enabled on later Android versions when they get to finish it and find ways to make old applications not crash when permissions are removed.
It is already known how to enable it without crashing the applications; return fake data. The cause of the app failure is not returning any data. There is a tool for returning fake data, which I think was briefly included in CyanogenMod. It causes apps that rely on the data for their revenue stream to continue operating without getting their payment (clean, marketable data). It was decided that tricking apps into operating was, in one way of thinking, using the software without the informed consent of the programmer -- something akin to misappropration -- and so it was removed.
You may not agree with that perspective, but it is the issue that Google is wrestling with: Should they facilitate the ability to prevent apps from knowing that they are not getting the clean data that they currently take as payment for producing the app?
In my opinion, our current standards for acquiring such data are extremely shady, relying heavily on a consumer base that is deeply misinformed of the extent of the surveillance and the risks the data stores pose. Where the balance of good lies between surveillance and countermeasures is hard to tell; it could be that subverting the datastream is pro-social in the long run -- but that is not the side on which Google's bread is buttered. They have a strong motive to see things from the app developers / watchers / revenue stream point of view. A great deal of money flows to Google from informed, uninformed, and misinformed consent to surveillance.
Stop-Prism.org: Opt Out of Surveillance
By far the most annoying permission is abused by developers on every OS I've tried: Launch at boot. Of Course, YOUR app is so very important that it HAS to use time and resources just so it can be ready at all times. Get over yourselves: I'll launch it when I want it. I'd be WAY happy to just be able to deny that one permission on Android.
On the one hand you take life too seriously, and on the other, you do not take playful existence seriously enough. Seth
https://news.ycombinator.com/item?id=6900762
This indicates that Google actually pulled code out. They could have just re-hidden it. Instead, it is now completely unavailable.
Why are you making excuses for them?
The old CyanogenMod that I use on my HTC G2 has permission controls. It works by faking the interface that the permission normally provides. Therefore apps do not crash because they still get permission but it's to fake data.
The only problem with it is that it is very out of date at this point and it does not fake the data for all permissions.
AFAIK, there is no iOS equivalent of CryogenicMod ;-)
That is why I always check the change logs before manually updating any app.
It never made it past testing in CM, but it's available for most Android versions, in some form, since 2.3.6.
Gingerbread had pDroid. Then there's pdroid2.0 and openpdroid, which are separate projects to do much the same thing, and openpdroid works for up to 4.2.2 now, AFAIK.
They're a little tricky to get going, You need to be using a deodexed rom (which pretty much means a non-stock custom) and you need to patch whichever $pdroid into it. Once that's done, it's just a matter of running the pdroid manager app and you're set.
NB: Not affiliated with any of the .*pdroid.* projects, just a (paranoid|spiteful) bastard who refuses to use android without them anymore.
Without launching at boot, how would an application designed to connect to an Internet service notify you of things relevant to your account on that service? For example, if an app store doesn't launch at boot, then you won't get notified about security updates to your existing apps until you happen to look for new apps, which might not be for weeks.
Even if you could do that, app developers have had half a decade in which they never had any reason to do so.
And that attitude is why Android is becoming the new Windows.
'But, but, we can't add security and privacy features, because they would break SuperWhizzoWriter 1993!'
It wasn't a feature. It wasn't "released". It didn't debut in 4.3.
It was in the code for testing only, and never meant to be used outside of Google.
There is almost nothing about this summary that is correct.
But hey; good fodder for the haters to start crying "Foul!" about an OS they don't use....
In this case, the people who are too stupid to use it are also too stupid to know or care why they'd even want to in the first place. It's not as if this is a game or something; it's a settings menu. Nobody's installing it for fun.
You answered yourself. They key words were "crap application."
Also, I wish IMEI access was a disable-able permission. Either it isn't, or it's a permission that absolutely nothing on my phone has tried to request.
The bottom line is scenarios like you described, where restricting an app's permission could ever cause a worse problem, tend not to be plausible.
I've never used either Cyanogenmod or Samsung's multi window feature, but I would have assumed it just reported the next-smaller screen size class (i.e., a 10-inch tablet in landscape mode would display two apps side-by-side by pretending to each app to be a 7-inch tablet in portrait mode). That sort of thing should be inherently compatible with all apps (at least, all apps that adhere to Google's UI standards).
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
You may not agree with that perspective, but it is the issue that Google is wrestling with: Should they facilitate the ability to prevent apps from knowing that they are not getting the clean data that they currently take as payment for producing the app?
In my opinion, our current standards for acquiring such data are extremely shady, relying heavily on a consumer base that is deeply misinformed of the extent of the surveillance and the risks the data stores pose. Where the balance of good lies between surveillance and countermeasures is hard to tell; it could be that subverting the datastream is pro-social in the long run -- but that is not the side on which Google's bread is buttered. They have a strong motive to see things from the app developers / watchers / revenue stream point of view. A great deal of money flows to Google from informed, uninformed, and misinformed consent to surveillance.
I completely agree. There is another, related problem that Google needs to address. Users have little recourse when app producers renege on the privacy that was initially sold to the user. For example, I paid for WeatherBug Elite simply because it did not require "phone state and identity" when I purchased it. Guess what? A year later they wanted that information for "Elite" too. I can either accept or not upgrade. I don't upgrade. I have a bunch of apps that are not getting updated because the new perms they ask for are ridiculous. If users cannot maintain the privacy that they paid for, what other options exist for them?
Either privacy has value and must be honored by app producers as part of the sale, or it doesn't and users have the right to block access to private information.
the growth in cynicism and rebellion has not been without cause
You can selectively reject any permission. In your example, the app would pop up a notification saying that it needed internet access to function. The user could then click "Allow" and the app would continue.
I'll give you another example, an app that can optionally store something in DropBox. Why should require that the permission to do so be granted at install time if it's an option the user might never use?