Forgot your password?
typodupeerror
Android Privacy Electronic Frontier Foundation Google

Google Cuts Android Privacy Feature, Says Release Was Unintentional 324

Posted by Soulskill
from the pay-no-attention-to-the-droid-behind-the-curtain dept.
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.'"
This discussion has been archived. No new comments can be posted.

Google Cuts Android Privacy Feature, Says Release Was Unintentional

Comments Filter:
  • Ups and Downs (Score:5, Insightful)

    by Akratist (1080775) on Friday December 13, 2013 @08:58AM (#45679451)
    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...
    • Re:Ups and Downs (Score:5, Insightful)

      by Rosco P. Coltrane (209368) on Friday December 13, 2013 @09:06AM (#45679523)

      Well it's Google, what do you expect...

      If you think Google works for the good of the user, think again.

      • by Chris Mattern (191822) on Friday December 13, 2013 @09:57AM (#45680031)

        If you think Google works for the good of the user, think again.

        Only Tron fights for the user.

    • Re:Ups and Downs (Score:5, Insightful)

      by erikkemperman (252014) on Friday December 13, 2013 @10:26AM (#45680325)

      The open nature is also being drastically eroded by moving more and more stuff into the Google Play Services. So while the platform is still technically open source, all the interesting things are moved into a separate, closed, layer.

      Slowly but surely, android is closing up.

      • Re:Ups and Downs (Score:5, Interesting)

        by Anonymous Coward on Friday December 13, 2013 @11:07AM (#45680731)
        That is very true; much of it is moving to closed source. Unfortunately we can't have nice things. We can't have nice things because of Tivoisation ( http://en.wikipedia.org/wiki/Tivoisation [wikipedia.org] ). We can't have nice things because of Samsung trying to "demote" the Google apps in favor of their crapware. We can't have nice things because of hardware vendors and carriers who won't update their devices (forcing Google to move stuff from core into apps that can be updated without intervention). There are a lot of things driving Google into close-sourcing more of the interesting bits of Android. None of those are "because they want to" or "because they are evil". They are, instead, being forced into it due to the evil of others.
      • Re:Ups and Downs (Score:4, Insightful)

        by ImprovOmega (744717) on Friday December 13, 2013 @02:09PM (#45682931)
        As long as you can side load apps and the APIs are free for developers it will still be light-years more open than Apple ever allows you to be. Heck, you can't even write an iPhone app unless you're doing it on a Mac with a sanctioned Apple developer license.
    • by Real1tyCzech (997498) on Friday December 13, 2013 @11:36AM (#45681069)

      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....

      • by bankman (136859) on Friday December 13, 2013 @02:10PM (#45682945) Homepage

        You may be right, but that doesn't diminish the fact that this should have been a feature from the very beginning and that its removal is not a step in the right direction from the user perspective.

        Oh, and yes, I don't use this OS (or any other smartphone for that matter) for precisely this reason, I can't properly contain and manage the installed software on a very privacy sensitive device.

  • Put in an app (Score:3, Interesting)

    by Anonymous Coward on Friday December 13, 2013 @09:02AM (#45679475)

    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.

    • by the_B0fh (208483)

      https://news.ycombinator.com/item?id=6900762 [ycombinator.com]

      If that is true, it means Google actually yanked the calls, instead of just hiding them.

    • Not even that really. You ALWAYS needed third party apps to bring up the screen.

      Here's the deal. This was never an end user feature. It was a screen that required additional software to actually bring up. It wasn't documented. I'm not even sure how anyone found out about it - my guess is someone trawling through the source code. Google's assertion that this wasn't meant to ever be released appears to be completely genuine and the apparent insinuation by the summary that Google isn't telling the truth is

      • Re:Put in an app (Score:4, Insightful)

        by triffid_98 (899609) on Friday December 13, 2013 @02:16PM (#45683003)

        as someone who used the equivalent functionality in CyanogenMod for a while, I can confirm that turning off permissions dynamically in this way requires quite a bit more care than it might appear at first - apps did crash when apparently denied features quite reasonably, even when you might think they'd have to cater for that situation anyway. I'd deny network privileges to an app, and see it crash, even though it would work without problems when the privilege was given but the network was unavailable for technical reasons.

        Speaking as a fellow Cyanogenmod user...

        CASE #1

        Some apps will crash if they can't read your phone contacts (or whatever absurd permission they asked for) and report them to their remote server...and I'm totally fine with that. They said right out they needed X permission and I said no you can't. CASE #2

        A lot of applications (I've no idea what percentage though) ask for permissions that they don't need, presumably on the basis that they might need them in the future and don't want automatic updates to stop (which they will if they suddenly want new permissions) CASE #3

        see CASE #1, except the developers used this super secret coding technique called try{}catch, and the application still works fine.

  • PDroid (Score:5, Informative)

    by JeffOwl (2858633) on Friday December 13, 2013 @09:03AM (#45679491)
    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.
    • by Kazymyr (190114)
      There are many apps that do that. I have been using "Permissions Free" for a couple of years now. I guess the news is that Google released similar functionality as a built-in, then removed it. Sounds nasty.
      • I guess the news is that Google released similar functionality as a built-in, then removed it. Sounds nasty.

        They didn't release it, per se. The code was there, but it was only accessible with third party tools. Not saying disabling access to it was the right choice, but it isn't as nasty as it sounds.

    • by gstoddart (321705)

      And just how easy is it to root the device? Every time I've looked at it, it seems like it's a lot of hoops to jump through, and with some concerns about still having a working device.

      Why Android can't just give me root by default, I don't understand. It's MY device, why can't I be the one who decides if I can have root?

      • Re:PDroid (Score:5, Insightful)

        by drinkypoo (153816) <martin.espinoza@gmail.com> on Friday December 13, 2013 @09:35AM (#45679787) Homepage Journal

        Why Android can't just give me root by default, I don't understand. It's MY device, why can't I be the one who decides if I can have root?

        There are security implications for both unlocking and rooting. It's best that they default off.

      • by JeffOwl (2858633)

        Ease of rooting depends on the device and can vary greatly from "download an app and press a button" to "download part of the Android dev environment to your PC, put the phone in dev mode and run a script." My current phone fell into the latter category, and even that wasn't bad with the detailed instructions.

        As to your second point, I agree that there should be an easier way, but I don't think it should be enabled by default. Not having Root provides a level of security from malicious apps. Even with ro

      • why can't I be the one who decides if I can have root?

        Because your carrier thinks you might use it to avoid intrusive advertising.

  • by korbulon (2792438)
    See also: "See No Evil", "Speak No Evil", and "Hear No Evil".
  • by Carrot007 (37198) <Carrot007@the[ ] ... k ['wib' in gap]> on Friday December 13, 2013 @09:04AM (#45679509) Homepage

    > it could break some of the apps policed by it.

    Is that not the entire point?

    • by barlevg (2111272)
      Why wouldn't you just uninstall those apps? Unless you're talking, like, Samsung bloatware, in which case, fair point.
      • by Kazymyr (190114)
        Doesn't work when you're talking built-in, as in manufacturer-made ones that are part of the ROM. Or, in some cases, Google apps. :)
        • by jonnythan (79727)

          You can easily disable those apps.

          • Re: (Score:3, Informative)

            by gstoddart (321705)

            You can easily disable those apps.

            Not all of them.

            For some of the Google apps, I've had to uninstall updates to get them rolled back to an older version that I could disable. On many apps, there's simply no option to disable them.

            In many cases, the update marks the app as something you can't disable.

            I would dearly LOVE something which allows me to set more granular permissions on apps. I just tried "Permission Manager", and it essentially just crashes. In the mean time, I mostly run my Android devices wi

            • by jonnythan (79727)

              In the app properties page for pre-installed apps, the "disable" button is replaced when the app is updated with an "uninstall updates" button. After you hit "uninstall updates" you can hit "disable."

              The only apps you can't disable are actual system apps. Things like Google Services Framework, Google Account Manager, Google partner Setup, etc, can all be disabled.

          • Yes, you can but then again, no you can't. They're such a convoluted mess of dependencies that you can never tell what disabling one of them might do to the rest of your phone. Others cannot be disabled through the application manager and even worse, some of them you cannot turn off notifications for. Not to mention that many calls are hardcoded to bring up those apps (holding the menu button on the latest Samsung phones is hard coded to bring up "S-Finder" for instance). I love Android, but you can't j

      • Why wouldn't you just uninstall those apps?

        Because the app is useful for feature A, but you don't care to allow it the permissions necessary for [mis]feature B.

        • by barlevg (2111272)
          You missed the context of my question.

          > it could break some of the apps policed by it.

          Is that not the entire point?

          If the entire point is to break the app, then why not just uninstall it and be done with it?

          • I did not miss the context. I was saying that the entire point is to break part of the app.

            • by barlevg (2111272)
              But then that's not breaking the app. That's doing what was intended. "Breaking the app" to me means losing core functionality.
        • by N1AK (864906)
          Wouldn't the logical thing here be for the Google to make the install menu advanced enough to allow devs to give users install options and permissions as required rather than letting users switch stuff off and see what breaks? If I was a dev I'd produce apps that check for all required permissions and explain and shutdown if some are restricted. Why? Because I don't want negative reviews because someone decided to turn off a permission and the app didn't work right.
          • Here's the fundamental issue: "allowing devs" to decide this sort of thing is user-hostile, because most devs will obviously decide to include every misfeature they think they can possibly get away with.

            As a user, I want the app to do what I want it to do and nothing else, and fuck you developer if you don't like it. It's my device and it will stay under my control, not yours, thankyouverymuch.

            If you develop software for Android -- or for any other platform, for that matter -- these are the terms you accept

    • by mlw4428 (1029576)
      Not necessarily. A poorly coded app that needs to use the GPS and crashes if you deny the permission is different than a well coded app that doesn't crash when you try to use the GPS and continues running. Google is most likely saying that they haven't figured out a GOOD way to prevent apps from just exploding when a permission that they expect to have is denied. Personally it doesn't make much sense for an end-user to retroactively deny permissions. You should review them up front and say up front...if my
      • by Artraze (600366)

        > Google is most likely saying that they haven't figured out a GOOD way to prevent apps from just exploding when a permission that they expect to have is denied.

        That is (or at least was) their excuse with regards to not allowing permission controls. However it was bullshit then and it's even more bullshit now. Not all phones/tablet have GPS and even if they do it can be off. SD cards be be ejected (time was when that was the only bulk storage), tablets don't have phone modules, etc. There are probabl

      • by Andy Dodd (701)

        FYI, this is EXACTLY why the first iteration of privacy controls in CyanogenMod (that which was present in CM7) was removed - too many apps crashed.

        The newer PG implementation in CM10.1 was such that permissions would not be denied, but an empty dataset would be returned.

        Now the claim made in TFS - "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 th

        • by tepples (727027)

          Don't like a permission? Don't install the app.

          That doesn't help when there aren't enough competing apps that don't need the permission.

      • by the_B0fh (208483)

        Does not apply when it is an ubiquitous app that you have to use in order to interact with your peers, friends and family.

        On iPhone, you can block all the permissions you want (contacts, photo albums, microphones, calendar, etc).

        On Android, you can either use it, or not use it. If you use it, it will have all the access it wants. No blocking for you, my dear user.

        I *STILL* cannot see how come Android users can justify this as "good" and "free" and "open. Please do not bring up ROMs or rooting. I'm talki

    • Imagine an app that does:

      try
      {
          fileSystem.read("/path/to/file");
      }
      catch(error)
      {
          launchMissiles()
      }

      What if you suddenly take the filesystem permissions away after allowing the app to be installed?!?

    • by Sockatume (732728)

      By "break" they mean the app would respond in an unpredictable way, more often than not in the form of a crash. (As opposed to the preferred behaviour that the disabled features would calmly be disabled.) You don't want a user-friendly settings panel to behave in a user-unfriendly way.

      • The real story-behind-the-story is developers threatened to test their abilities on launch and quit if the tests failed.

        Which they are well within their rights to do. But it wouldve meant many apps wouldnt have worked without connectivity for example, which would have been bad for the ecosystem.

        iOS is a different case, with a richer demographic and more paid apps. Free Android app developers need that usage data, not necessarily to sell it, but to be agile.

        Sure there's sometimes blatant abuse but that's bet

  • Just plain wrong. (Score:5, Insightful)

    by Anonymous Coward on Friday December 13, 2013 @09:08AM (#45679545)

    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.

    • by Andy Dodd (701)

      Google never released an app. They accidentally left code enabled deep in the frameworks for which user-facing control was never exposed except via third-party modifications.

    • by N1AK (864906)

      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.

      You can choose not to install it. If you don't trust the app dev to correctly disclose what permissions they need then walk away. People will turn permissions off, break the app and then slate the app for not working. Better to build the app to test for permissions on launch, explain

      • by LDAPMAN (930041) on Friday December 13, 2013 @11:17AM (#45680837)

        Not all permissions are essential to the operation of the app. Thats the point of being able to selectively choose. Many IOS apps just disable certain functions or niceties when you deny a permission. They can also pop up a nice dialog when you try to do something requiring that permission and ask if you want to turn it back on. An all-or-nothing approach is just stupid and leads to users just blindly accepting what the app asks for.

    • by Solandri (704621)

      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.

      There's nothing at all wrong about that. You are proposing one extreme where the user gets to control everything software can do on his phone. Apple does the other extreme where the developer controls everything and Apple provides oversight.

      Google is

  • by fche (36607) on Friday December 13, 2013 @09:15AM (#45679621)

    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 opted out of the whole smart-phone schtick a few months ago. I had an iPhone. I loved the feature that enabled me to disable certain apps from reporting certain things that I couldn't see why anyone in their right mind would want. If I was currently using an Android phone, this would make me toss it.
  • Eagerly awaited (Score:5, Insightful)

    by dargaud (518470) <slashdot2NO@SPAMgdargaud.net> on Friday December 13, 2013 @09:17AM (#45679637) Homepage
    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.
    • Re:Eagerly awaited (Score:4, Informative)

      by dido (9125) <didoNO@SPAMimperium.ph> on Friday December 13, 2013 @09:52AM (#45679965)

      If you're rooted, you can install the XPosed Framework [xda-developers.com] and the XPrivacy module for it [xda-developers.com], which will allow you to lie to an app about the permissions it requests. CyanogenMod 10.1 also has such a feature, although the UI is rather clumsy if you ask me.

    • Android has had a "set fake location for testing" feature for a long time. Even my mostly locked down Virgin Mobile phone has that allowed.

      "Settings -> developer options -> Allow Mock Locations"

      If you don't have developer options, you may be able to get them turned on from "Settings -> About Phone" by clicking the Build Number, at least 7 times.

      Then install one of several location setting tools from Google Play. Set location wherever you want.

      Other permissions are harder to fake, but location res

  • by bravecanadian (638315) on Friday December 13, 2013 @09:18AM (#45679653)

    Who is surprised?

    That data is Google's entire business.

  • by csumpi (2258986) on Friday December 13, 2013 @09:23AM (#45679687)
    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.
  • Enough said, really...

  • 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).

  • It seems to be working great, even with some of Google's own apps. Comes out the same way whether I don't install an app because I don't think a fucking flashlight app should get network and GPS permissions or because that app breaks when it attempts to request them and it doesn't get them. I'm just less likely to install the app if I think the developer was just being lazy and requesting all permissions. Arguably I shouldn't be installing apps from bad developers anyway. Also arguably Google shouldn't be a
  • You mean not everyone is using XPrivacy already?! Ok, live and learn. Like when I actually first saw an ad in an android phone, mine never shows one.
  • Great in Theory (Score:4, Interesting)

    by ironicsky (569792) on Friday December 13, 2013 @09:57AM (#45680029) Journal

    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.

  • There are a ton of apps I won't install, because they want to be able to make calls, see my call history, my contacts, get precise location, etc. Right now, it's an all-or-nothing approach. Either accept all of that, or don't install. More often than not, I don't install.

    Listen up Google:

    When you install or update an app, and it shows the permissions for the app, every single one, right there in the install/update popup for the app, should have the on/off slider, and let the user determine what permissio

  • developer ego (Score:5, Interesting)

    by spaceman375 (780812) on Friday December 13, 2013 @10:28AM (#45680347)
    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.
    • 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.

In order to get a loan you must first prove you don't need it.

Working...