Google Cuts Android Privacy Feature, Says Release Was Unintentional 324
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.'"
Ups and Downs (Score:5, Insightful)
Re:Ups and Downs (Score:5, Insightful)
Well it's Google, what do you expect...
If you think Google works for the good of the user, think again.
Re:Ups and Downs (Score:5, Funny)
Only Tron fights for the user.
Re: (Score:2)
Re:Ups and Downs (Score:5, Funny)
Re:Ups and Downs (Score:5, Insightful)
Oh jeez, you really need to stop looking at Google through your Android-colored glasses!
Google was a cool tech company a decade ago when they came up with products that benefited the users, namely an email product that offered 1GB of space free when others gave you 20MB, and of course search. Since then they've morphed from a tech to an advertising and data-mining company, and all of their products reflect this.
Google:"Do you want to sign up for G+" or "Do you want to use your real name on Youtube?"
User:clicks NO
Google:"OK, we'll ask you later"
Do No Evil hasn't existed at Google for a decade, if it ever did.
Re:Ups and Downs (Score:4, Insightful)
Oh jeez, you really need to stop looking at Google through your Android-colored glasses!
Wonderful ad hominem, but I dont actually have an android.
I also like how you completely didnt address any of my points. Yes, a lot of the stuff Google does with youtube is incredibly obnoxious, as is their insistence on making Google+ work despite the fact that noone really cares. None of that really has anything to do with their corporate stewardship or ethics.
Calling them "evil" for their youtube commenting policies just shows that you really dont understand what "evil" is referring to. For some people, Google's privacy policy is a lot more vital to their well-being than whether you are forced to use Google+ for youtube comments, and those people are probably really glad that Google actually honors its policies and resists overreach by law enforcement of various countries.
Re: (Score:3)
It bugs me to see the crap google gets when they are the least abusive of all big companies by just about any measure, and actually HAVE fought for the user on several occasions (China, warrantless data requests, posting takedowns to Chilling Effects / working with the EFF).
I mean I guess you can cross your fingers and hope that companies like Yahoo and MS dont do things like spill the beans on Chinese dissident bloggers [wikipedia.org] or work with the Chinese gov't to create a bugged version of Skype for China [wikipedia.org], but I wouldnt hold your breath.
I guess why it irritates me so much is that Google really does seem to try to be the good guy, and they get crap for it because people seem to want to forget what their business model is and give them a hard time for being for-profit. Maybe we should boycott them, THAT will teach them to fight extrajudicial data requests!
I imagine the baitfish has a similar mental state at any point in time prior to being eaten by an anglerfish.
Any perceived benevolence, animosity or innocuousness in a completely amoral organism like a corporation is an illusion. For your own safety you should learn to pierce that illusion. There is no reason to "feel bad" for a steamroller when its operator is being reprimanded for running over a dog. The fact that the steamroller was, up until that moment, being used to help create a road system that you
Re:Ups and Downs (Score:5, Insightful)
It bugs me to see the crap google gets when they are the least abusive of all big companies by just about any measure ....
They deserve to get crap for *this* and any other positive actions aren't a get-out-of-jail-free card. Until a few years ago the slashdot faq contained this:
I thought everyone on Slashdot hated the RIAA, the MPAA, and Microsoft. Why do you keep hyping CDs, movies, and Windows games?
Big corporations are what they are. They sell us cool stuff with one hand and tighten the screws on our freedoms with the other. We hate them every morning and love them every afternoon, and vice versa. This is part of living in the modern world: you take your yin with your yang and try to figure out how to do what's right the best you can. If you think it has to be all one way or the other, that's cool, share your opinions, but don't expect everyone else to think the same.
Re: (Score:3)
They voluntarily shared user data in China and Russia.
Wrong, try again. They were threatening to leave China for a while about 7 years ago because China was pressing hard for them to spill the beans on what kinds of searches folks were doing, and Google didnt want to play that game. Of course as I linked Yahoo and MS were all too happy to comply, Im not really clear how that makes them better in your book.
More recently (less than a year ago?) Google started alerting users when Chinas GFW was tampering with their connections in response to "forbidden" queries
Re:Ups and Downs (Score:5, Insightful)
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)
Re:Ups and Downs (Score:4, Insightful)
The summary is utter crap. (Score:5, Informative)
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....
Re:The summary is utter crap. (Score:4, Insightful)
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)
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.
Re: (Score:3)
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.
Re: (Score:3)
Re:Put in an app (Score:4, Insightful)
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)
Re: (Score:3)
Re: (Score:3)
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.
Re: (Score:3)
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)
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.
Re: (Score:2)
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
Re: (Score:2)
Because your carrier thinks you might use it to avoid intrusive advertising.
Re: (Score:2)
Re: (Score:3)
Most apps already have to cope with features that are missing. e.g. an app might want to read SMS or make calls, but neither facility is available on most tablets. Or they might ask for GPS coords and again they simply can't have it. If they can't cope with the variety out there already then I don't see much difference if the user has an explicit switch t
"Do No Evil" (Score:2, Funny)
Sounds like it worked (Score:5, Insightful)
> it could break some of the apps policed by it.
Is that not the entire point?
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
You can easily disable those apps.
Re: (Score:3, Informative)
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
Re: (Score:3)
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.
Re: (Score:3)
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
Re: (Score:2)
Because the app is useful for feature A, but you don't care to allow it the permissions necessary for [mis]feature B.
Re: (Score:2)
> 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?
Re: (Score:2)
I did not miss the context. I was saying that the entire point is to break part of the app.
Re: (Score:2)
Re: (Score:3)
Have you ever used the feature being discussed? It not only provides a list of what permissions the apps want (and switches to turn them on and off), it also tells you how long ago the app actually tried to use the permission. For example, on my Nexus 5, Chrome last used my location December 6, read the clipboard 5 days ago, and has never tried to use the camera or record audio. What this means is that these features are optional, and it's perfectly reasonable to disallow them and continue using the app wit
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:3)
> 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
Re: (Score:3)
Funny you mention Windows, because that is kind of what it's like. If you're developing a Windows application you have to accept the possibility that -- for example -- the user might firewall your program (so making it add-supported won't necessarily work) and that there's not a damn thing you can do about it.
You're one of those dumbass programm
Re: (Score:3)
You're talking about the situation where an app legitimately requires a permission (e.g. a text messaging app requiring text messaging permission). I'm talking about the situation where an app illegitimately "requires" a permission (e.g. a live wallpaper app requiring text messaging permission). "If you don't want to grant the privileges that the app says it needs, then don't install the app" does not work because Stupid End User thinks "ZOMG PRETTY PICTURES! ...PERMISSIONS? LOL WUT?" and installs the damn
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:3)
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?!?
If launched without permission to save games (Score:2)
Re:Sounds like it worked (Score:4, Funny)
Did you used to work i the software security division of Adobe?
Re: (Score:2)
Nothing. Of course, I would have also taken away its Launch Missiles permissions as well.
Re: (Score:2)
But what if the sole purpose of the app was to launch missiles (under certain conditions)?
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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
catch (SecurityException e) (Score:2)
Current Android API's do not allow an app to query to see if a requested permission was not granted very easily
Why isn't it just a case of trying something and catching a SecurityException?
Re: (Score:2)
Even if you could do that, app developers have had half a decade in which they never had any reason to do so.
Re: (Score:3)
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!'
Just plain wrong. (Score:5, Insightful)
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.
Re: (Score:3)
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.
Re: (Score:2)
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
Re:Just plain wrong. (Score:5, Insightful)
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.
Re: (Score:3)
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
a straw (Score:3)
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.
Deal breaker for sure (Score:2)
Eagerly awaited (Score:5, Insightful)
Re:Eagerly awaited (Score:4, Informative)
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.
Re: (Score:2)
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
Is there anyone here (Score:5, Insightful)
Who is surprised?
That data is Google's entire business.
"it could break some of the apps" (Score:3)
Don't like it, don't use it. (Score:2)
Enough said, really...
Am I the only one who sees this? (Score:3)
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).
That's Funny (Score:2)
XPrivacy (Score:2)
Great in Theory (Score:4, Interesting)
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.
Wrong direction (Score:2)
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)
Notifications (Score:3)
Re: (Score:2)
I grew fed up with android years ago. What kind of calculator app requires weekly updates? Dumbphones FTW
You don't *have* to update. Once I find a fully working app, I never update it. What would be the point, since it already works?
Re: Meh (Score:2)
Re: Meh (Score:5, Informative)
Re: (Score:3)
Who'll be laughing then .... (Score:3)
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!
No updates (Score:2)
I don't update the OS or apps on both my phone and tablet.
Re:really ? (Score:5, Interesting)
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.
Re:really ? (Score:5, Insightful)
Re: (Score:2)
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.
Let it crash! Put this feature somewhere hidden with a warning that it only should be used by experienced users. I don't care if an app crashes because it cannot get to my contacts. Although it would be nice if you would get a notice about this.
Re: (Score:2)
You can do that, and be an OS with bad reputation or you can be a good OS vendor, and start documenting those changes for future versions, give developers time to update, etc. Quoting Linus Torvalds, "don't break userspace", if you are going to break it, give people time to update
Re: (Score:3)
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 f
Re:really ? (Score:5, Insightful)
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.
Re: (Score:3)
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 ap
Re:really ? (Score:5, Interesting)
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.
Re: (Score:3)
https://news.ycombinator.com/item?id=6900762 [ycombinator.com]
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?
4.3 has its own problem (Score:2)
Re:IOS? (Score:5, Informative)
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).
Re: (Score:3)
Re: (Score:3)
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?