26 ms·

Google Removes Vital Privacy Feature From Android, Claims Release Was Accidental

406 points by tijs 13y ago

ChrisAntaki 13y ago
> 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. Oh, it would definitely break some apps. Considering it would introduce new uncertainty. It's still an amazing feature.
- raverbashing 13y ago
  Yeah, because checking return codes and error values is overrated Thanks Google, for making my phone less secure.
  - signalnow 13y ago
    It was never official, it was never announced nor documented.
  - josteink 13y ago
    Yeah, because checking return codes and error values is overrated Even Google's own non-AOSP camera is guilty of this too. The API docs says an app should check for camera capabilities before using them. Still the PhotoSphere feature in Google's non-AOSP camera attempts to set Flash-settings on devices with no flash-capability. To overcome the issue you have to rewrite the camera-interface code to ignore API calls to SetFlash, SetLightmode etc when not supported, instead of throwing as you should be doing according to the docs. So yeah. Even Google is guilty of this one.
    - The_Double 13y ago
      Google is one of the worse offenders when it comes to not following android guidelines. Their apps consistently break back button behavior, don't follow UI guidelines, etc.
  - hahainternet 13y ago
    By allowing you to install software they make your phone less secure. Better buy a feature phone ASAP!
- jevinskie 13y ago
  I can't believe they question Google's authenticity when they say it was accidentally released too soon and then go on to criticize the feature for being unpolished and incomplete!
davedx 13y ago
I think it's a great feature. There have definitely been some apps where I would have liked to use them but they've had permissions requirements that I did not believe the app's core functionality needed.
- rtpg 13y ago
  every time I open facebook messanger with gps enabled, I see it querying my location. I hate it so much. Would love to be able to turn that off
  - arsemouflon 13y ago
    Well ...
  - kiallmacinnes 13y ago
    Have you tried not opening it? Seriously, if you use any of facebooks stuff, you clearly value something they offer more than your privacy. Everybody, and I'm not just talking about the HN crowd, knows how bad Facebook is when it comes to privacy.
    - eropple 13y ago
      This is the sort of sad comment that continually amazes me. Facebook is am important part of the social life of millions (billions?) of people. It isn't feasible to go away from it. It's completely reasonable to have a requirement to use Facebook while not wanting it to be an ass about stuff like constant GPS fixes. Yeah, sure, don't use Facebook. You're the guy who butts into conversations to tell everyone how you don't own a TV, aren't'cha?
      - chetanahuja 13y ago
        "It isn't feasible to go away from it." Perhaps you could ask one of around 6 billion people in the world how they survive without this essential utility.
      - 13y ago
rtpg 13y ago
I'm surprised this feature wasn't in place from day 1. It probably involves almost no implementation overhead on the OS side of things. Apps, on the other hand, would have an extra error case to deal with, but they should be dealing with other error cases anyways.
- gorhill 13y ago
  > "they should be dealing with other error cases anyways" Especially when "Access to all your contacts" (or whatever) is really not needed for the application to work correctly.
kmfrk 13y ago
It's been a pretty shitty week for privacy, hasn't it? First the Disqus hack, then the changed Block feature on Twitter, and now this?
- djm_ 13y ago
  Twitter has gone back on that after listening to user feedback. I honestly think this 'App Ops' feature will also return, it was only found by sniffing about in the APKs and could only be activated (easily) by installing an app which surfaced the settings pane; that's not the same as it being a default menu option that was removed - it wasn't meant for public release yet. I appreciate the EFF and their stance on this but I'm giving Google the benefit of doubt on this one, hopefully we'll see it soon in its full glory.
- SamReidHughes 13y ago
  The changed block feature on Twitter didn't do anything negative for privacy.
  - kmfrk 13y ago
    It took away users' ability to block other users from viewing their tweets? How is that not privacy?
    - SamReidHughes 13y ago
      They never had that ability (besides making their tweets private, but that's not what blocking is). Blocked users can just log out or log in under an alternate account in order to view the person's tweets.
      - kmfrk 13y ago
        You just used the term "making their tweets private". If we can't agree this constitutes a privacy feature - however small in scope - I think we'll just have to agree to disagree. :)
salient 13y ago
I hope it wasn't just an "accident" and Google really was working on a way to make it work for both developers and users, and perhaps it was there much like the ART runtime is in there, even though it's not ready for primetime. I think Google can make it work, but they need to be committed to it. Surely there's a way for the apps to gracefully transition to not needing certain permissions. Google just needs to introduce the proper rules for developers to make this work.
- hrjet 13y ago
  I don't have hopes of Google restoring the AppOps functionality in the future. Most of the apps require these excessive permissions because of third-party ad libraries. Google's AdMob library is the most popular of these libraries, being used in 36% of Android apps [1]. [1] : http://www.appbrain.com/stats/libraries/ad http://www.appbrain.com/stats/libraries/ad
awjr 13y ago
I didn't use App Ops. Did it allow a general policy to be set? I can see you can set permission per app from the screen shot. I'm not sure I buy Google's excuse. Any app worth it's salt should be able to cope with not having the permission set. I'm guessing this was impacting their own core apps.
- eropple 13y ago
  > Any app worth it's salt should be able to cope with not having the permission set. That doesn't in any way follow. My Android application handles the expected failure cases enumerated in the API. It does not handle the "permissions granted when the user saw your manifest and agreed to grant those permissions disappear because reasons" case because they're is no reasonable expectation that case is necessary. The APIs don't allow for that case, if it throws a catchable exception at all it'll be an undocumented one, I can't differentiate between it any other exception that might roll out of Android. Why would be anything other than unhandled? Which isn't to say that data permissions should not be mockable; they should. But your "anything I don't understand is easy" post is straight-up bad.
616c 13y ago
Whatever, fuck Google. If you are interest in doing this with Android, the autopatcher[0] does this for you on a whole series of ROMs on all versions of Android from 2.x-4.x, and has been doing so successfully for a while. There is a pretty active user community on XDA for the PDroid patchset as well.[1] [0] https://github.com/mateor/auto-patcher https://github.com/mateor/auto-patcher [1] http://forum.xda-developers.com/showthread.php?t=1357056 http://forum.xda-developers.com/showthread.php?t=1357056
- Kequc 13y ago
  > Whatever, fuck Google. Well this is going to be productive. I'm pretty sure Google isn't out to put all of its users through a meat grinder. For one thing people have been way off the handle about Google touching anything. At all. This article only mentions an accident that lasted one day. So it's "fuck Google" after everything, still, again I guess.
  - FeloniousHam 13y ago
    Right on, right on. While I like the potential of this app, the millions of devices with billions of applications that would simply stopping working with its introduction mean it will need a carefully orchestrated rollout. HN readers might be comfortable with "ever beta" technologies, but the other 99% of users are not (and it's odd that smart people fail to appreciate this).
    - exodust 13y ago
      "billions of applications that would simply stopping working". So what? The user can just re-enable the app's access to whatever it was trying to fetch. I don't buy the "millions of apps simply stop working" line. If the apps stops working because it was blocked trying to access my address book, then the app developer should have done better to expect the unexpected when fetching anything from outside the application that isn't essential to its core function and purpose. Even the simplest of javascript functions will handle a null value or failed fetch. There's even an "onerror" handler for HTML img tags! And you're telling me that millions of apps will fail because they don't receive what they're trying to fetch? Sounds like an exaggeration, or bad programming, or a bad OS.
panzerboy 13y ago
There is a way of bringing it back, however the phone has to be rooted. See here: http://www.xda-developers.com/android/xposed-module-brings-back-app-ops-to-android-4-4-2-and-gives-your-control-of-your-application-permissions/ http://www.xda-developers.com/android/xposed-module-brings-b...
wting 13y ago
If you have root you can still enable it with market apps.[0][1] However something like this needs to be integrated tightly like iOS and apps need to be aware they may not receive requested permissions. I still use App Ops in Kit Kat and it silently breaks apps all the time. Apps expect to be able request information (e.g. contact details) and crash or stall when they can't. In that respect, LBE Privacy Guard[2] was a much better alternative up to ICS. It was a privacy firewall that would pop up notifications when protected permissions were being used for the first time. Instead of blocking apps when denied, Privacy Guard would feed it blank data instead. This lead to a better UX and stopped blocked apps crashing. There needs to be an open source version of LBE Privacy Guard since the current one hasn't been updated over a year and is closed source from a Chinese company. [0]: https://play.google.com/store/apps/details?id=com.colortiger.appopsinstaller&hl=en https://play.google.com/store/apps/details?id=com.colortiger... [1]: https://play.google.com/store/apps/details?id=biz.bokhorst.xprivacy.installer&hl=en https://play.google.com/store/apps/details?id=biz.bokhorst.x... [2]: DO NOT INSTALL, FORCES REBOOT LOOP https://play.google.com/store/apps/details?id=com.lbe.security.lite https://play.google.com/store/apps/details?id=com.lbe.securi...
- rjzzleep 13y ago
  here's a translated version that i've been using this up to 4.3.(haven't updated my nexus phone to kitkat and am not planning to either) http://forum.xda-developers.com/showthread.php?t=1422479 http://forum.xda-developers.com/showthread.php?t=1422479 although i think this might also be working in kitkat. what i can recommend to users though is to use pdroid if they wish to do so. so you could use lbe for all apps. and pdroid for lbe itself. a lot of jelly bean custom roms support openpdroid. i personally use cyankang http://forum.xda-developers.com/showthread.php?t=2212620 http://forum.xda-developers.com/showthread.php?t=2212620
- magic_haze 13y ago
  xprivacy does the same thing, and seems to be actively developed. The only problem is that it has an atrocious UX, but again, that seems to be on par for most android utils.
- mike-cardwell 13y ago
jackgavigan 13y ago
This is one area where iOS stands head and shoulders above Android. I used to run Cyanogenmod and I remember deciding to not upgrade the Facebook app because doing so would have required giving it a slew of permissions, including the ability to "directly call phone numbers". By contrast, in iOS, I can choose which apps have access to my location, contacts, etc. I know that Apple's track record when it comes to privacy isn't exactly spotless but Google would be well advised to follow their lead in allowing users granular control over 3rd-party apps' permissions.
- tomp 13y ago
  So far, I've been an Android fan (I love the customizability and all), but if anything will make me buy an iPhone, it's this feature.
- outworlder 13y ago
  Do not expect Google to implement it anytime soon, due to the massive app breakage potential. Android's permission system looks good on the surface. However, there are so many required permissons nowadays that many users do not even check them anymore. And you can revoke specific permissions on an app by app basis. On iOS, developers are told not to rely on certain permissions being available, such as location. Some apps truly can't function without those, but they are supposed to warn the user, not crash.
  - e40 13y ago
    Do not expect Google to implement it anytime soon, due to the massive app breakage potential. I run AppOps 4.3/4.4 rooted (so I use the "App Ops X" version internally), and I must say, I've restricted most of my non-system apps and I've never seen a single broken app. I think this potential is vastly overblown. EDIT: for example, in the official twitter app, I turn off these: * Location * Read contacts * Receieve SMS/MMS * Post notification * Wake lock Never had a single problem with the app.
  - jre 13y ago
    As long as the disallowed permissions simply return empty results (or random stuff) for the API calls, I don't see how this can break apps.
ansible 13y ago
The original intention (as explained by Dianne Hackborn among others) is that if the user sees the app requesting too many capabilities... the user should simply choose not to install the app. Having the user needing to understand all the different capabilities is too much. Having a bunch of pop-ups (cough Vista) is also bad UI design. The current set of capabilities is too technical for end users to really understand. This all need to be collapsed into a few broad areas like "tracks your location" that have clear, clickable explanations. For the privacy paranoid, having a configurable way to just inject false data would be great. Have a single fake IMEI number, for example. Then for apps, the API call doesn't fail, it just returns the fake number.
- DanBC 13y ago
  > Have a single fake IMEI number, for example. How would that work in countries where modifying the IMEI is illegal? UK law (note prison sentence) http://www.legislation.gov.uk/ukpga/2002/31/section/1 http://www.legislation.gov.uk/ukpga/2002/31/section/1 I don't know if this is current US law or not. Here's one example http://thomas.loc.gov/cgi-bin/query/z?c112:S.3186.IS http://thomas.loc.gov/cgi-bin/query/z?c112:S.3186.IS:
  - dTal 13y ago
    The suggestion was making a userspace call to retrieve the IMEI return a fake value, not modifying the IMEI itself. Perfectly legal, although I imagine a great legal battle could be fought over the interpretation of "interfere with the operation of". I am, however, surprised that MAC spoofing is enough to get you a prison sentence if done on a "mobile wireless communications device". EDIT: apparently as of a 2006 addendum in the "Violent Crime Reduction Act" even offering to do it for someone else will land you in the clink. Gotta keep those violent hackers off the streets I guess.
  - leoedin 13y ago
    That law seems particularly draconian. I assume it's an attempt to criminalise the changing of IMEIs on stolen phones? Reading that is slightly alarming, if only because I wouldn't have even considered that it could be illegal before today. I wonder how many other pieces of legislation I've naively violated?
throwwit 13y ago
This is a pretty disturbing trend. Just recently I ran into problems with a TV station's app on iOS that refused to play video without Location Services Enabled. I don't mind a general region being disclosed, but the house-level accuracy of the location data definitely creeps me out. I don't think the general public realizes location can be equivalent to a person's id.
- dictum 13y ago
  > I don't mind a general region being disclosed, but the house-level accuracy of the location data definitely creeps me out. This is exactly what I want most of the time. My ISP's servers are usually in neighboring cities, so geoip isn't precise enough, but GPS is too precise for my needs. I just want to disclose what city I'm in. This is enough info to give me useful results (e.g. I search Google for "italian restaurants", it gives me results for my city first) without violating my privacy by giving Google my location habits. Maybe OSes could give an option to reduce the granularity of the location reported, so you could disclose the town or state, but not the exact street, for instance.
  - hnha 13y ago
    There are apps to "fake" your location so maybe you can find a suitable one. I never used one but my external Bluetooth GNSS device feeds its accurate location into Android the same way. Please share if you do find a good one!
- mikecane 13y ago
  >>>Just recently I ran into problems with a TV station's app on iOS that refused to play video without Location Services Enabled. When it comes to things such as entertainment, regional rights restrictions probably have more to do with that than the app wanting to spy on you. I'm not saying this is right. Just saying how the lawyers have sliced things into pieces like that.
  - throwwit 13y ago
    They could get that region-level information already from ISP routing info. This ratcheting up of info means: The household owner's name, their affluence, postal code, phone number, a cross match with google street view and all info that shows (new car?). The last thing I want is to watch a home reno show on a tablet and then be deluged with phone calls soliciting for new windows. This is definitly not 'right'. (edit: on top of watching ads that glitch and repeat.)
polskibus 13y ago
I'm really disappointed, seems like my next phone won't carry Android! App opps worked great for me and help alleviate some worries about tracking. I could also see which apps actually used their claimed Android features. Many of them claim to use location yet never access it.
CalRobert 13y ago
I'm probably going to turn in to that old guy with tin foil who can't play any games because nobody supports his choice of platform, but I really miss when computers were devices you could buy and then put your choice of OS on. Phones are pretty much just little ARM computers, why the hell don't I just install Ubuntu, Firefox OS, Android, WinPhone, Symbian, whatever? I could format a microSD card to boot from and go from there. And while I'm complaining, phones (devices for communication, remember?) need proper keyboards. OK. I'll crawl back into my cave now.
- StavrosK 13y ago
  Why not? I installed Ubuntu the other day, it was trivial. Plus, there's a multitude of custom ROMs.
  - CalRobert 13y ago
    Yeah, but what you would call trivial might be insurmountable for lots of people. Cyanogenmod already has a lot of the privacy features missing in Android, but dicking around with clockworkmod recovery, etc. is pretty daunting.
    - StavrosK 13y ago
      Fair point.
    - nileshtrivedi 13y ago
      Cyanogenmod now provides a really easy installer that takes care of everything (including unlocking of the bootloader). I used it with my Nexus S last week without any hassles.
    - tomkarlo 13y ago
      Swapping the OS on a desktop computer has never been particularly accessible to most people, either. What percentage of desktops ever get a different OS from what they came with? I'd guess less than 3% if you don't include upgrades from one version of Windows to another.
deleted 13y ago
[deleted]
signalnow 13y ago
I don't understand this from the EFF first they post a piece lauding an unofficial, deeply buried unannounced functionality, then they condemn Google for removing something that they have never officially released or supported in the first place. It’s their mistake for jumping the gun and discussing something that wasn't officially, the followup is just to save face, but that is really an unfair attack.
- freehunter 13y ago
  How would anyone know it was not official until Google said it wasn't meant to be released?
  - ben1040 13y ago
    What sort of official feature is hidden and can't be accessed via any user interface provided by the vendor?
    - drdaeman 13y ago
      What sort of "we never meant to release this" feature would get merged into stable tree and even get into the production builds that get shipped on the actual retail hardware? I thought if feature's meant to be solely experimental it'd just sit in a separate feature branch.
trurl42 13y ago
I hope this feature will get added again in a future version. It was not an official feature in KitKat and somewhat breaks the current API, where developers didn't have to check for permissions at runtime. Android 5.0 maybe?
Nursie 13y ago
They still need to split the permissions more. READ_PHONE_STATE is nasty. Apps ask for the permission because they (for instance) need to pause playback on a video because you have an incoming call. But it covers all the phone details (numbers, IMEI etc) and who the call is coming from and a hell of a lot of other stuff. Who the hell thought that was a good idea?
- ben1040 13y ago
  Yep. I have gotten one-star reviews on an app of mine because they think I want to invade users' privacy, when I really just want to pause media when a call comes in. READ_PHONE_STATE means I have to decide whether I want a handful of one-star reviews for requesting that permission, or a truckload of one-star reviews for the app playing media over their calls.
  - chuinard 13y ago
    Have you considered listing the reasoning behind your permissions in your app description?
uniray 13y ago
I'm surprised at the EFF. this post seems intended to save face for them rather than anything else. They had a post recently lauding App Ops although it was never officially released, announced nor documented. And it certainly was not accessible to the average user. Also it was obviously not compatible with most apps, as they didn’t fail too gracefully. Again: App Ops Was Never Meant For End Users, Used For Internal Testing And Debugging Only http://www.androidpolice.com/2013/12/11/googler-app-ops-was-never-meant-for-end-users-used-for-internal-testing-and-debugging-only/ http://www.androidpolice.com/2013/12/11/googler-app-ops-was-... I do hope Google is working on something similar on an OS level for future releases, but this hack job by the EFF is disappointing and unnecessary.
- biehl 13y ago
  Because using "beta" features from Google is unthinkable? I think it makes perfect sense to laud even small steps in the right direction (beta-quality features etc.) and comment negatively on steps in the wrong direction (removing privacy options for users).
  - uniray 13y ago
    It was not even a beta feature, it was not exposed to end users at all.
pgsandstrom 13y ago
I would guess this is because cancelling the internet permission can be used to block ads. Ads that generate money for Google.
lifeisstillgood 13y ago
If they put it back with next release, it was accidental. If not, not.
- nimble 13y ago
  They're claiming the release was accidental. Not the removal.
Zigurd 13y ago
This is very disappointing. I had hoped the release of App Ops as a hidden feature indicated that permissions would be user-revocable in a future release. It isn't a burden to handle security exceptions.
Zigurd 13y ago
Jolla and/or Myriad could make some hay by adding a similar feature to the Android compatibility runtime used in Sailfish.
SmileyKeith 13y ago
This is a major issue Google needs to deal with in Android IMO. I'm surprised that this feature ever existed in Android because of how coupled permissions are with applications. Since applications request all permissions on install I imagine most developers don't have much conditional code for their failure, unlike iOS where you have to because there's a possibility a user may deny access to a single specific thing, like location data. I'd really prefer to see Android go more towards that. When you look at the permissions an application like Facebook requests on install it's just insane.
- jxf 13y ago
  That's partially because developers are somewhat incentivized to "front-load" their permissions. If you think there's even a chance you might use a permission, even if your app doesn't currently use it, ask for it on the first install. Then, later, when you actually do want to use it, your app update won't say that you need any new permissions.
  - exodust 13y ago
    This doesn't sound right to me. I don't think developers are doing this.
    - jxf 13y ago
      I don't think developers should do it, but there's no question that they're doing it. For example, Facebook requests almost every permission under the sun. But if you look at the average user's permission profile for their Facebook app, they'll only show a tiny fraction of the overall permissions that Facebook originally requested.
      - SmileyKeith 13y ago
        And that's the really scary part. Is that so many applications do this for just unreasonable permissions. Then you get one of the bad applications that's actually using that data for something nefarious and it destroys trust in the process. For me at least.
cognivore 13y ago
There is another point here, one I think even more important and more disconcerting. Google released an entire feature of their Android OS BY ACCIDENT. W...T...F?! How do you release a feature "by accident?" By having awful quality control? How does that make me feel about the rest of their Android OS now? Either this, or they're lying through their teeth in an effort to cover up. In either case, it's evil.
- chaz 13y ago
  Hanlon's Razor probably applies here. http://en.wikipedia.org/wiki/Hanlon's_razor http://en.wikipedia.org/wiki/Hanlon's_razor
  - mcguire 13y ago
    Stupidity and malice are frequently indistinguishable by an outside observer.
    - chaz 13y ago
      All the more reason to pause before ascribing malice as the motive.
      - mcguire 13y ago
        I don't know. Personally, I would rather be regarded as evil than stupid.
        saraid216 13y ago
        And now you've justified evil for every stupid person in the world. Check it out: "Don't call me stupid; I'll punch you for that!"
    - alan_cx 13y ago
      Hmmmmmmm, perhaps, but I'd suggest that: Stupidity is negligence. Negligence is selfish. That makes it malicious. Its willful which ever way one chose to spin it. IMHO, such phrases are not much different to ones like "what do you have to hide?". They are designed to look like one thing, confuse and win a point, while hiding the fact that something appalling is going on. Its the language of confusion to control. Its too easy to be allowed to hide behind a false concept of stupidity. Too convenient.
gorhill 13y ago
All these abusive permissions are an excellent opportunity for GNU-licensed software (free, no ads, only strict minimum of required permissions -- all honestly explained) to thrive on Android.
zmmmmm 13y ago
It seems really dumb of Google not to just go with the flow here and let the AppOps feature exist. Whack a giant disclaimer on it that it will break stuff, disable Play Store comments and ratings, let the users use it, and collect the giant PR dividend for looking like you care about privacy. They can do all that and lose virtually nothing because such a tiny percentage of people will ever use this feature that it will make no difference to them at all. On the other hand they can go the other way and take a giant PR hit for virtually no benefit. Out of some sense of stubbornness or beligerance Google often seems to desire to shoot itself in the foot like this.
- cpleppert 13y ago
  I don't if it will break a lot of applications; probably some. The real problem is the permissions system that doesn't allow users to selectively choose which permissions they want to give to applications thus application developers don't code their applications to not work if they fail to get permission. Users are just shown a screen with the permissions the application requested. For most users, this is worthless. Do any users decide not to install an application based on asking for too much? Users still don't have any control on stock systems over running services and applications in the background. It is all 100% anti-users and pro-monetization; which is probably google's intention all along.
- GrinningFool 13y ago
  I'd love it if enabling a feature like just caused the selected data points to be returned, but completely bogus (invalid phone number, empty address list, north pole location, etc). It would work for almost everything except network access, and would ensure that it didn't break apps in a bad way. The all-or-nothing data privacy model of android makes me a bit crazy now that I'm using it on a regular basis for my tablet. That's one thing BlackBerry got right - you can grant or deny individual permissions to applications, and generally could safely assume that application developers knew this and handled security access exceptions when trying to access protected data.
discardorama 13y ago
Users of Android should realize that they are the product. If Google gives too much privacy control, advertisers won't pay as much for ads, and Google's core business is ads. Given a fight between privacy and ad dollars for Google, privacy will lose almost every time (within reason; Google doesn't want to kill the golden goose (i.e., you)).
kiallmacinnes 13y ago
I have to admit, the EFF has just lost a chunk of support from me over this. Google never released this feature - you needed to install some 3rd party app to expose the settings, this alone is enough for anyone of any intelligence to know they are doing something not intended for the general public. Seriously EFF, get your act together please. I do want to support you, but not like this.

406 points by tijs 13y ago

> 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. Oh, it would definitely break some apps. Considering it would introduce new uncertainty. It's still an amazing feature.

raverbashing 13y ago
Yeah, because checking return codes and error values is overrated Thanks Google, for making my phone less secure.
- signalnow 13y ago
  It was never official, it was never announced nor documented.
- josteink 13y ago
  Yeah, because checking return codes and error values is overrated Even Google's own non-AOSP camera is guilty of this too. The API docs says an app should check for camera capabilities before using them. Still the PhotoSphere feature in Google's non-AOSP camera attempts to set Flash-settings on devices with no flash-capability. To overcome the issue you have to rewrite the camera-interface code to ignore API calls to SetFlash, SetLightmode etc when not supported, instead of throwing as you should be doing according to the docs. So yeah. Even Google is guilty of this one.
  - The_Double 13y ago
    Google is one of the worse offenders when it comes to not following android guidelines. Their apps consistently break back button behavior, don't follow UI guidelines, etc.
- hahainternet 13y ago
  By allowing you to install software they make your phone less secure. Better buy a feature phone ASAP!
jevinskie 13y ago
I can't believe they question Google's authenticity when they say it was accidentally released too soon and then go on to criticize the feature for being unpolished and incomplete!

davedx 13y ago

I think it's a great feature. There have definitely been some apps where I would have liked to use them but they've had permissions requirements that I did not believe the app's core functionality needed.

rtpg 13y ago
every time I open facebook messanger with gps enabled, I see it querying my location. I hate it so much. Would love to be able to turn that off
- arsemouflon 13y ago
  Well ...
- kiallmacinnes 13y ago
  Have you tried not opening it? Seriously, if you use any of facebooks stuff, you clearly value something they offer more than your privacy. Everybody, and I'm not just talking about the HN crowd, knows how bad Facebook is when it comes to privacy.
  - eropple 13y ago
    This is the sort of sad comment that continually amazes me. Facebook is am important part of the social life of millions (billions?) of people. It isn't feasible to go away from it. It's completely reasonable to have a requirement to use Facebook while not wanting it to be an ass about stuff like constant GPS fixes. Yeah, sure, don't use Facebook. You're the guy who butts into conversations to tell everyone how you don't own a TV, aren't'cha?
    - chetanahuja 13y ago
      "It isn't feasible to go away from it." Perhaps you could ask one of around 6 billion people in the world how they survive without this essential utility.
    - 13y ago

rtpg 13y ago

I'm surprised this feature wasn't in place from day 1. It probably involves almost no implementation overhead on the OS side of things. Apps, on the other hand, would have an extra error case to deal with, but they should be dealing with other error cases anyways.

gorhill 13y ago
> "they should be dealing with other error cases anyways" Especially when "Access to all your contacts" (or whatever) is really not needed for the application to work correctly.

kmfrk 13y ago

It's been a pretty shitty week for privacy, hasn't it? First the Disqus hack, then the changed Block feature on Twitter, and now this?

djm_ 13y ago
Twitter has gone back on that after listening to user feedback. I honestly think this 'App Ops' feature will also return, it was only found by sniffing about in the APKs and could only be activated (easily) by installing an app which surfaced the settings pane; that's not the same as it being a default menu option that was removed - it wasn't meant for public release yet. I appreciate the EFF and their stance on this but I'm giving Google the benefit of doubt on this one, hopefully we'll see it soon in its full glory.
SamReidHughes 13y ago
The changed block feature on Twitter didn't do anything negative for privacy.
- kmfrk 13y ago
  It took away users' ability to block other users from viewing their tweets? How is that not privacy?
  - SamReidHughes 13y ago
    They never had that ability (besides making their tweets private, but that's not what blocking is). Blocked users can just log out or log in under an alternate account in order to view the person's tweets.
    - kmfrk 13y ago
      You just used the term "making their tweets private". If we can't agree this constitutes a privacy feature - however small in scope - I think we'll just have to agree to disagree. :)

salient 13y ago

I hope it wasn't just an "accident" and Google really was working on a way to make it work for both developers and users, and perhaps it was there much like the ART runtime is in there, even though it's not ready for primetime. I think Google can make it work, but they need to be committed to it. Surely there's a way for the apps to gracefully transition to not needing certain permissions. Google just needs to introduce the proper rules for developers to make this work.

hrjet 13y ago
I don't have hopes of Google restoring the AppOps functionality in the future. Most of the apps require these excessive permissions because of third-party ad libraries. Google's AdMob library is the most popular of these libraries, being used in 36% of Android apps [1]. [1] : http://www.appbrain.com/stats/libraries/ad http://www.appbrain.com/stats/libraries/ad

awjr 13y ago

I didn't use App Ops. Did it allow a general policy to be set? I can see you can set permission per app from the screen shot. I'm not sure I buy Google's excuse. Any app worth it's salt should be able to cope with not having the permission set. I'm guessing this was impacting their own core apps.

eropple 13y ago
> Any app worth it's salt should be able to cope with not having the permission set. That doesn't in any way follow. My Android application handles the expected failure cases enumerated in the API. It does not handle the "permissions granted when the user saw your manifest and agreed to grant those permissions disappear because reasons" case because they're is no reasonable expectation that case is necessary. The APIs don't allow for that case, if it throws a catchable exception at all it'll be an undocumented one, I can't differentiate between it any other exception that might roll out of Android. Why would be anything other than unhandled? Which isn't to say that data permissions should not be mockable; they should. But your "anything I don't understand is easy" post is straight-up bad.

616c 13y ago

Whatever, fuck Google. If you are interest in doing this with Android, the autopatcher[0] does this for you on a whole series of ROMs on all versions of Android from 2.x-4.x, and has been doing so successfully for a while. There is a pretty active user community on XDA for the PDroid patchset as well.[1] [0] https://github.com/mateor/auto-patcher https://github.com/mateor/auto-patcher [1] http://forum.xda-developers.com/showthread.php?t=1357056 http://forum.xda-developers.com/showthread.php?t=1357056

Kequc 13y ago
> Whatever, fuck Google. Well this is going to be productive. I'm pretty sure Google isn't out to put all of its users through a meat grinder. For one thing people have been way off the handle about Google touching anything. At all. This article only mentions an accident that lasted one day. So it's "fuck Google" after everything, still, again I guess.
- FeloniousHam 13y ago
  Right on, right on. While I like the potential of this app, the millions of devices with billions of applications that would simply stopping working with its introduction mean it will need a carefully orchestrated rollout. HN readers might be comfortable with "ever beta" technologies, but the other 99% of users are not (and it's odd that smart people fail to appreciate this).
  - exodust 13y ago
    "billions of applications that would simply stopping working". So what? The user can just re-enable the app's access to whatever it was trying to fetch. I don't buy the "millions of apps simply stop working" line. If the apps stops working because it was blocked trying to access my address book, then the app developer should have done better to expect the unexpected when fetching anything from outside the application that isn't essential to its core function and purpose. Even the simplest of javascript functions will handle a null value or failed fetch. There's even an "onerror" handler for HTML img tags! And you're telling me that millions of apps will fail because they don't receive what they're trying to fetch? Sounds like an exaggeration, or bad programming, or a bad OS.

panzerboy 13y ago

There is a way of bringing it back, however the phone has to be rooted. See here: http://www.xda-developers.com/android/xposed-module-brings-back-app-ops-to-android-4-4-2-and-gives-your-control-of-your-application-permissions/ http://www.xda-developers.com/android/xposed-module-brings-b...

wting 13y ago

If you have root you can still enable it with market apps.[0][1] However something like this needs to be integrated tightly like iOS and apps need to be aware they may not receive requested permissions. I still use App Ops in Kit Kat and it silently breaks apps all the time. Apps expect to be able request information (e.g. contact details) and crash or stall when they can't. In that respect, LBE Privacy Guard[2] was a much better alternative up to ICS. It was a privacy firewall that would pop up notifications when protected permissions were being used for the first time. Instead of blocking apps when denied, Privacy Guard would feed it blank data instead. This lead to a better UX and stopped blocked apps crashing. There needs to be an open source version of LBE Privacy Guard since the current one hasn't been updated over a year and is closed source from a Chinese company. [0]: https://play.google.com/store/apps/details?id=com.colortiger.appopsinstaller&hl=en https://play.google.com/store/apps/details?id=com.colortiger... [1]: https://play.google.com/store/apps/details?id=biz.bokhorst.xprivacy.installer&hl=en https://play.google.com/store/apps/details?id=biz.bokhorst.x... [2]: DO NOT INSTALL, FORCES REBOOT LOOP https://play.google.com/store/apps/details?id=com.lbe.security.lite https://play.google.com/store/apps/details?id=com.lbe.securi...

rjzzleep 13y ago
here's a translated version that i've been using this up to 4.3.(haven't updated my nexus phone to kitkat and am not planning to either) http://forum.xda-developers.com/showthread.php?t=1422479 http://forum.xda-developers.com/showthread.php?t=1422479 although i think this might also be working in kitkat. what i can recommend to users though is to use pdroid if they wish to do so. so you could use lbe for all apps. and pdroid for lbe itself. a lot of jelly bean custom roms support openpdroid. i personally use cyankang http://forum.xda-developers.com/showthread.php?t=2212620 http://forum.xda-developers.com/showthread.php?t=2212620
magic_haze 13y ago
xprivacy does the same thing, and seems to be actively developed. The only problem is that it has an atrocious UX, but again, that seems to be on par for most android utils.
mike-cardwell 13y ago

jackgavigan 13y ago

This is one area where iOS stands head and shoulders above Android. I used to run Cyanogenmod and I remember deciding to not upgrade the Facebook app because doing so would have required giving it a slew of permissions, including the ability to "directly call phone numbers". By contrast, in iOS, I can choose which apps have access to my location, contacts, etc. I know that Apple's track record when it comes to privacy isn't exactly spotless but Google would be well advised to follow their lead in allowing users granular control over 3rd-party apps' permissions.

tomp 13y ago
So far, I've been an Android fan (I love the customizability and all), but if anything will make me buy an iPhone, it's this feature.
outworlder 13y ago
Do not expect Google to implement it anytime soon, due to the massive app breakage potential. Android's permission system looks good on the surface. However, there are so many required permissons nowadays that many users do not even check them anymore. And you can revoke specific permissions on an app by app basis. On iOS, developers are told not to rely on certain permissions being available, such as location. Some apps truly can't function without those, but they are supposed to warn the user, not crash.
- e40 13y ago
  Do not expect Google to implement it anytime soon, due to the massive app breakage potential. I run AppOps 4.3/4.4 rooted (so I use the "App Ops X" version internally), and I must say, I've restricted most of my non-system apps and I've never seen a single broken app. I think this potential is vastly overblown. EDIT: for example, in the official twitter app, I turn off these: * Location * Read contacts * Receieve SMS/MMS * Post notification * Wake lock Never had a single problem with the app.
- jre 13y ago
  As long as the disallowed permissions simply return empty results (or random stuff) for the API calls, I don't see how this can break apps.

ansible 13y ago

The original intention (as explained by Dianne Hackborn among others) is that if the user sees the app requesting too many capabilities... the user should simply choose not to install the app. Having the user needing to understand all the different capabilities is too much. Having a bunch of pop-ups (cough Vista) is also bad UI design. The current set of capabilities is too technical for end users to really understand. This all need to be collapsed into a few broad areas like "tracks your location" that have clear, clickable explanations. For the privacy paranoid, having a configurable way to just inject false data would be great. Have a single fake IMEI number, for example. Then for apps, the API call doesn't fail, it just returns the fake number.

DanBC 13y ago
> Have a single fake IMEI number, for example. How would that work in countries where modifying the IMEI is illegal? UK law (note prison sentence) http://www.legislation.gov.uk/ukpga/2002/31/section/1 http://www.legislation.gov.uk/ukpga/2002/31/section/1 I don't know if this is current US law or not. Here's one example http://thomas.loc.gov/cgi-bin/query/z?c112:S.3186.IS http://thomas.loc.gov/cgi-bin/query/z?c112:S.3186.IS:
- dTal 13y ago
  The suggestion was making a userspace call to retrieve the IMEI return a fake value, not modifying the IMEI itself. Perfectly legal, although I imagine a great legal battle could be fought over the interpretation of "interfere with the operation of". I am, however, surprised that MAC spoofing is enough to get you a prison sentence if done on a "mobile wireless communications device". EDIT: apparently as of a 2006 addendum in the "Violent Crime Reduction Act" even offering to do it for someone else will land you in the clink. Gotta keep those violent hackers off the streets I guess.
- leoedin 13y ago
  That law seems particularly draconian. I assume it's an attempt to criminalise the changing of IMEIs on stolen phones? Reading that is slightly alarming, if only because I wouldn't have even considered that it could be illegal before today. I wonder how many other pieces of legislation I've naively violated?

throwwit 13y ago

This is a pretty disturbing trend. Just recently I ran into problems with a TV station's app on iOS that refused to play video without Location Services Enabled. I don't mind a general region being disclosed, but the house-level accuracy of the location data definitely creeps me out. I don't think the general public realizes location can be equivalent to a person's id.

dictum 13y ago
> I don't mind a general region being disclosed, but the house-level accuracy of the location data definitely creeps me out. This is exactly what I want most of the time. My ISP's servers are usually in neighboring cities, so geoip isn't precise enough, but GPS is too precise for my needs. I just want to disclose what city I'm in. This is enough info to give me useful results (e.g. I search Google for "italian restaurants", it gives me results for my city first) without violating my privacy by giving Google my location habits. Maybe OSes could give an option to reduce the granularity of the location reported, so you could disclose the town or state, but not the exact street, for instance.
- hnha 13y ago
  There are apps to "fake" your location so maybe you can find a suitable one. I never used one but my external Bluetooth GNSS device feeds its accurate location into Android the same way. Please share if you do find a good one!
mikecane 13y ago
>>>Just recently I ran into problems with a TV station's app on iOS that refused to play video without Location Services Enabled. When it comes to things such as entertainment, regional rights restrictions probably have more to do with that than the app wanting to spy on you. I'm not saying this is right. Just saying how the lawyers have sliced things into pieces like that.
- throwwit 13y ago
  They could get that region-level information already from ISP routing info. This ratcheting up of info means: The household owner's name, their affluence, postal code, phone number, a cross match with google street view and all info that shows (new car?). The last thing I want is to watch a home reno show on a tablet and then be deluged with phone calls soliciting for new windows. This is definitly not 'right'. (edit: on top of watching ads that glitch and repeat.)

polskibus 13y ago

I'm really disappointed, seems like my next phone won't carry Android! App opps worked great for me and help alleviate some worries about tracking. I could also see which apps actually used their claimed Android features. Many of them claim to use location yet never access it.

CalRobert 13y ago

I'm probably going to turn in to that old guy with tin foil who can't play any games because nobody supports his choice of platform, but I really miss when computers were devices you could buy and then put your choice of OS on. Phones are pretty much just little ARM computers, why the hell don't I just install Ubuntu, Firefox OS, Android, WinPhone, Symbian, whatever? I could format a microSD card to boot from and go from there. And while I'm complaining, phones (devices for communication, remember?) need proper keyboards. OK. I'll crawl back into my cave now.

StavrosK 13y ago
Why not? I installed Ubuntu the other day, it was trivial. Plus, there's a multitude of custom ROMs.
- CalRobert 13y ago
  Yeah, but what you would call trivial might be insurmountable for lots of people. Cyanogenmod already has a lot of the privacy features missing in Android, but dicking around with clockworkmod recovery, etc. is pretty daunting.
  - StavrosK 13y ago
    Fair point.
  - nileshtrivedi 13y ago
    Cyanogenmod now provides a really easy installer that takes care of everything (including unlocking of the bootloader). I used it with my Nexus S last week without any hassles.
  - tomkarlo 13y ago
    Swapping the OS on a desktop computer has never been particularly accessible to most people, either. What percentage of desktops ever get a different OS from what they came with? I'd guess less than 3% if you don't include upgrades from one version of Windows to another.

deleted 13y ago

[deleted]

signalnow 13y ago

I don't understand this from the EFF first they post a piece lauding an unofficial, deeply buried unannounced functionality, then they condemn Google for removing something that they have never officially released or supported in the first place. It’s their mistake for jumping the gun and discussing something that wasn't officially, the followup is just to save face, but that is really an unfair attack.

freehunter 13y ago
How would anyone know it was not official until Google said it wasn't meant to be released?
- ben1040 13y ago
  What sort of official feature is hidden and can't be accessed via any user interface provided by the vendor?
  - drdaeman 13y ago
    What sort of "we never meant to release this" feature would get merged into stable tree and even get into the production builds that get shipped on the actual retail hardware? I thought if feature's meant to be solely experimental it'd just sit in a separate feature branch.

trurl42 13y ago

I hope this feature will get added again in a future version. It was not an official feature in KitKat and somewhat breaks the current API, where developers didn't have to check for permissions at runtime. Android 5.0 maybe?

Nursie 13y ago

They still need to split the permissions more. READ_PHONE_STATE is nasty. Apps ask for the permission because they (for instance) need to pause playback on a video because you have an incoming call. But it covers all the phone details (numbers, IMEI etc) and who the call is coming from and a hell of a lot of other stuff. Who the hell thought that was a good idea?

ben1040 13y ago
Yep. I have gotten one-star reviews on an app of mine because they think I want to invade users' privacy, when I really just want to pause media when a call comes in. READ_PHONE_STATE means I have to decide whether I want a handful of one-star reviews for requesting that permission, or a truckload of one-star reviews for the app playing media over their calls.
- chuinard 13y ago
  Have you considered listing the reasoning behind your permissions in your app description?

uniray 13y ago

I'm surprised at the EFF. this post seems intended to save face for them rather than anything else. They had a post recently lauding App Ops although it was never officially released, announced nor documented. And it certainly was not accessible to the average user. Also it was obviously not compatible with most apps, as they didn’t fail too gracefully. Again: App Ops Was Never Meant For End Users, Used For Internal Testing And Debugging Only http://www.androidpolice.com/2013/12/11/googler-app-ops-was-never-meant-for-end-users-used-for-internal-testing-and-debugging-only/ http://www.androidpolice.com/2013/12/11/googler-app-ops-was-... I do hope Google is working on something similar on an OS level for future releases, but this hack job by the EFF is disappointing and unnecessary.

biehl 13y ago
Because using "beta" features from Google is unthinkable? I think it makes perfect sense to laud even small steps in the right direction (beta-quality features etc.) and comment negatively on steps in the wrong direction (removing privacy options for users).
- uniray 13y ago
  It was not even a beta feature, it was not exposed to end users at all.

pgsandstrom 13y ago

I would guess this is because cancelling the internet permission can be used to block ads. Ads that generate money for Google.

lifeisstillgood 13y ago

If they put it back with next release, it was accidental. If not, not.

nimble 13y ago
They're claiming the release was accidental. Not the removal.

Zigurd 13y ago

This is very disappointing. I had hoped the release of App Ops as a hidden feature indicated that permissions would be user-revocable in a future release. It isn't a burden to handle security exceptions.

Zigurd 13y ago

Jolla and/or Myriad could make some hay by adding a similar feature to the Android compatibility runtime used in Sailfish.

SmileyKeith 13y ago

This is a major issue Google needs to deal with in Android IMO. I'm surprised that this feature ever existed in Android because of how coupled permissions are with applications. Since applications request all permissions on install I imagine most developers don't have much conditional code for their failure, unlike iOS where you have to because there's a possibility a user may deny access to a single specific thing, like location data. I'd really prefer to see Android go more towards that. When you look at the permissions an application like Facebook requests on install it's just insane.

jxf 13y ago
That's partially because developers are somewhat incentivized to "front-load" their permissions. If you think there's even a chance you might use a permission, even if your app doesn't currently use it, ask for it on the first install. Then, later, when you actually do want to use it, your app update won't say that you need any new permissions.
- exodust 13y ago
  This doesn't sound right to me. I don't think developers are doing this.
  - jxf 13y ago
    I don't think developers should do it, but there's no question that they're doing it. For example, Facebook requests almost every permission under the sun. But if you look at the average user's permission profile for their Facebook app, they'll only show a tiny fraction of the overall permissions that Facebook originally requested.
    - SmileyKeith 13y ago
      And that's the really scary part. Is that so many applications do this for just unreasonable permissions. Then you get one of the bad applications that's actually using that data for something nefarious and it destroys trust in the process. For me at least.

cognivore 13y ago

There is another point here, one I think even more important and more disconcerting. Google released an entire feature of their Android OS BY ACCIDENT. W...T...F?! How do you release a feature "by accident?" By having awful quality control? How does that make me feel about the rest of their Android OS now? Either this, or they're lying through their teeth in an effort to cover up. In either case, it's evil.

chaz 13y ago
Hanlon's Razor probably applies here. http://en.wikipedia.org/wiki/Hanlon's_razor http://en.wikipedia.org/wiki/Hanlon's_razor
- mcguire 13y ago
  Stupidity and malice are frequently indistinguishable by an outside observer.
  - chaz 13y ago
    All the more reason to pause before ascribing malice as the motive.
    - mcguire 13y ago
      I don't know. Personally, I would rather be regarded as evil than stupid.
      - saraid216 13y ago
        And now you've justified evil for every stupid person in the world. Check it out: "Don't call me stupid; I'll punch you for that!"
  - alan_cx 13y ago
    Hmmmmmmm, perhaps, but I'd suggest that: Stupidity is negligence. Negligence is selfish. That makes it malicious. Its willful which ever way one chose to spin it. IMHO, such phrases are not much different to ones like "what do you have to hide?". They are designed to look like one thing, confuse and win a point, while hiding the fact that something appalling is going on. Its the language of confusion to control. Its too easy to be allowed to hide behind a false concept of stupidity. Too convenient.

gorhill 13y ago

All these abusive permissions are an excellent opportunity for GNU-licensed software (free, no ads, only strict minimum of required permissions -- all honestly explained) to thrive on Android.

zmmmmm 13y ago

It seems really dumb of Google not to just go with the flow here and let the AppOps feature exist. Whack a giant disclaimer on it that it will break stuff, disable Play Store comments and ratings, let the users use it, and collect the giant PR dividend for looking like you care about privacy. They can do all that and lose virtually nothing because such a tiny percentage of people will ever use this feature that it will make no difference to them at all. On the other hand they can go the other way and take a giant PR hit for virtually no benefit. Out of some sense of stubbornness or beligerance Google often seems to desire to shoot itself in the foot like this.

cpleppert 13y ago
I don't if it will break a lot of applications; probably some. The real problem is the permissions system that doesn't allow users to selectively choose which permissions they want to give to applications thus application developers don't code their applications to not work if they fail to get permission. Users are just shown a screen with the permissions the application requested. For most users, this is worthless. Do any users decide not to install an application based on asking for too much? Users still don't have any control on stock systems over running services and applications in the background. It is all 100% anti-users and pro-monetization; which is probably google's intention all along.
GrinningFool 13y ago
I'd love it if enabling a feature like just caused the selected data points to be returned, but completely bogus (invalid phone number, empty address list, north pole location, etc). It would work for almost everything except network access, and would ensure that it didn't break apps in a bad way. The all-or-nothing data privacy model of android makes me a bit crazy now that I'm using it on a regular basis for my tablet. That's one thing BlackBerry got right - you can grant or deny individual permissions to applications, and generally could safely assume that application developers knew this and handled security access exceptions when trying to access protected data.

discardorama 13y ago

Users of Android should realize that they are the product. If Google gives too much privacy control, advertisers won't pay as much for ads, and Google's core business is ads. Given a fight between privacy and ad dollars for Google, privacy will lose almost every time (within reason; Google doesn't want to kill the golden goose (i.e., you)).

kiallmacinnes 13y ago

I have to admit, the EFF has just lost a chunk of support from me over this. Google never released this feature - you needed to install some 3rd party app to expose the settings, this alone is enough for anyone of any intelligence to know they are doing something not intended for the general public. Seriously EFF, get your act together please. I do want to support you, but not like this.