×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Google Cuts Android Privacy Feature, Says Release Was Unintentional

Soulskill posted about 4 months ago | from the pay-no-attention-to-the-droid-behind-the-curtain dept.

Android 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.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

324 comments

Ups and Downs (5, Insightful)

Akratist (1080775) | about 4 months ago | (#45679451)

One of Android's selling points has always been it's open nature, and the fact that it's not as locked down as iOS. This seems like it's taking a step in the direction of locking down the OS for the user, and unlocking it for everyone else...

Re:Ups and Downs (5, Insightful)

Rosco P. Coltrane (209368) | about 4 months ago | (#45679523)

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 (-1)

Anonymous Coward | about 4 months ago | (#45680311)

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

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

Google's new motto "Do as much evil as possible!"

Re:Ups and Downs (5, Insightful)

erikkemperman (252014) | about 4 months ago | (#45680325)

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

Slowly but surely, android is closing up.

Meh (-1)

Anonymous Coward | about 4 months ago | (#45679455)

I grew fed up with android years ago. What kind of calculator app requires weekly updates? Dumbphones FTW

Re:Meh (1)

Rosco P. Coltrane (209368) | about 4 months ago | (#45679537)

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 (2)

David Barreda (3462737) | about 4 months ago | (#45679701)

Better battery consumption? Optimization? There are lots of reason to update an application.

Re: Meh (4, Informative)

Wookact (2804191) | about 4 months ago | (#45679955)

There are reasons not to update as well: additional ads, removal of liked features. When I find an app and version I like I make a copy of the apk. Then if there is an update that I don't like I can always go back to the old version. I've had to do this with the local newspapers application as it has become bloated with ads, and crazy permissions.

Who'll be laughing then .... (2)

Chrisq (894406) | about 4 months ago | (#45679689)

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!

Put in an app (3, Interesting)

Anonymous Coward | about 4 months ago | (#45679475)

I thought I read that they just pulled it out and into its own app, so that you'd have to seek out this feature. They wanted to keep folks who didn't know exactly what they were doing to stumble upon this and mess up their phones.

really ? (1)

Fluffy the Destroyer (3459643) | about 4 months ago | (#45679477)

It's possible that this feature got through Q&A without noticing or telling which got through the cracks. They bigger you are, they more complex "papers and bureaucrary becomes thus more mistakes are bound to happen...like this. I won't judge them for this mistake but people will judge them by how they fix this mistake and how fast can it be fixed. Everyone can make mistakes but it takes skills to learn from it. Let's hope Google can learn from it.

Re:really ? (4, Interesting)

robmv (855035) | about 4 months ago | (#45679609)

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 ? (5, Insightful)

Arker (91948) | about 4 months ago | (#45680209)

The difference is that this is really critical functionality that should have been built in and tested from day one, but gets pushed way down the priority stack because of googles conflict of interest in the matter. So it's like that situation a little, but not really.

Re:really ? (1)

rvw (755107) | about 4 months ago | (#45680219)

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:really ? (5, Insightful)

Bob9113 (14996) | about 4 months ago | (#45680243)

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.

PDroid (5, Informative)

JeffOwl (2858633) | about 4 months ago | (#45679491)

Gives granular control of app permissions. Requires Root, but it's worth it. I figured this change was never going to be permanent because it messes with Google's (and app developers') revenue stream.

Re:PDroid (2)

Kazymyr (190114) | about 4 months ago | (#45679591)

There are many apps that do that. I have been using "Permissions Free" for a couple of years now. I guess the news is that Google released similar functionality as a built-in, then removed it. Sounds nasty.

Re:PDroid (2)

Razalhague (1497249) | about 4 months ago | (#45680131)

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: PDroid (1)

Anonymous Coward | about 4 months ago | (#45679675)

XPrivacy is even better

Re:PDroid (2)

gstoddart (321705) | about 4 months ago | (#45679749)

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 (0)

Anonymous Coward | about 4 months ago | (#45679779)

Because it's not your device. Not fully at least since you're merely licensed to use the software.

Re:PDroid (5, Insightful)

drinkypoo (153816) | about 4 months ago | (#45679787)

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:PDroid (0)

Anonymous Coward | about 4 months ago | (#45679819)

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.

On my Nexus 4? Install android sdk tools. Download custom recovery and supersu. Plug the phone in and type three or four commands.

Re:PDroid (1)

JeffOwl (2858633) | about 4 months ago | (#45679913)

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 root, the phone will prompt you every time an app wants super user access.

Re:PDroid (1)

Anne Thwacks (531696) | about 4 months ago | (#45680083)

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

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

Re:PDroid (0)

Anonymous Coward | about 4 months ago | (#45680199)

You can be the one who decides. Buy a nexus, unlock the bootloader and root it. Done.

Re:PDroid (0)

Anonymous Coward | about 4 months ago | (#45679949)

Eh, the bigger problem is that app developers have this whole time been assuming that all the permissions that they ask for in the manifest have been already approved, so they aren't handling exceptions properly when something like this or Cyanogen's similar feature decide that they can't access something. Google doesn't like it because the Play Store has enough crashy apps as it is.

I figure when this feature finally does become official it will only work on apps written for some later API version and won't be usable on older apps.

Re:PDroid (2)

DrXym (126579) | about 4 months ago | (#45680157)

I doubt Google cares that some app is too buggy to function without a particular permission. Their general approach is to let the cream float to the top.

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 to disable that functionality.

That said, the current situation is completely unacceptable. The upfront permissions are getting worse and worse for some apps and often for completely esoteric reasons. Twitter recently updated their app to ask my location. Fortunately there is a switch in their app to turn this off, but really I shouldn't have to count on their charity - I should be able to turn that setting off whether they want me to or not.

"Do No Evil" (1, Funny)

korbulon (2792438) | about 4 months ago | (#45679505)

See also: "See No Evil", "Speak No Evil", and "Hear No Evil".

Re:"Do No Evil" (0)

Anonymous Coward | about 4 months ago | (#45680327)

See also: "See No Evil", "Speak No Evil", and "Hear No Evil".

But "Do as much Evil as possible"

Sounds like it worked (5, Insightful)

Carrot007 (37198) | about 4 months ago | (#45679509)

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

Is that not the entire point?

Re:Sounds like it worked (1)

barlevg (2111272) | about 4 months ago | (#45679549)

Why wouldn't you just uninstall those apps? Unless you're talking, like, Samsung bloatware, in which case, fair point.

Re:Sounds like it worked (2)

Kazymyr (190114) | about 4 months ago | (#45679603)

Doesn't work when you're talking built-in, as in manufacturer-made ones that are part of the ROM. Or, in some cases, Google apps. :)

Re:Sounds like it worked (1)

jonnythan (79727) | about 4 months ago | (#45679615)

You can easily disable those apps.

Re:Sounds like it worked (2, Informative)

gstoddart (321705) | about 4 months ago | (#45679723)

You can easily disable those apps.

Not all of them.

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

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

I would dearly LOVE something which allows me to set more granular permissions on apps. I just tried "Permission Manager", and it essentially just crashes. In the mean time, I mostly run my Android devices with wifi off, and with no data plan so there's no way for them to reach the network.

Re:Sounds like it worked (2)

jonnythan (79727) | about 4 months ago | (#45679759)

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:Sounds like it worked (2)

MozeeToby (1163751) | about 4 months ago | (#45679797)

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 just wave away valid criticism with a poor work around.

Re:Sounds like it worked (1)

mrchaotica (681592) | about 4 months ago | (#45679713)

Why wouldn't you just uninstall those apps?

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

Re:Sounds like it worked (1)

barlevg (2111272) | about 4 months ago | (#45679991)

You missed the context of my question.

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

Is that not the entire point?

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

Re:Sounds like it worked (1)

N1AK (864906) | about 4 months ago | (#45680115)

Wouldn't the logical thing here be for the Google to make the install menu advanced enough to allow devs to give users install options and permissions as required rather than letting users switch stuff off and see what breaks? If I was a dev I'd produce apps that check for all required permissions and explain and shutdown if some are restricted. Why? Because I don't want negative reviews because someone decided to turn off a permission and the app didn't work right.

Re:Sounds like it worked (1)

Anonymous Coward | about 4 months ago | (#45679569)

Current Android API's do not allow an app to query to see if a requested permission was not granted very easily, so by "break the app" means the app could not work at all (since it can assume it can do something, but can't).

If an app has a permission you don't like, the general idea with the current state of affairs is just uninstall it.

catch (SecurityException e) (1)

tepples (727027) | about 4 months ago | (#45679681)

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:catch (SecurityException e) (1)

Sockatume (732728) | about 4 months ago | (#45679717)

Even if you could do that, app developers have had half a decade in which they never had any reason to do so.

Re:Sounds like it worked (2)

mlw4428 (1029576) | about 4 months ago | (#45679581)

Not necessarily. A poorly coded app that needs to use the GPS and crashes if you deny the permission is different than a well coded app that doesn't crash when you try to use the GPS and continues running. Google is most likely saying that they haven't figured out a GOOD way to prevent apps from just exploding when a permission that they expect to have is denied. Personally it doesn't make much sense for an end-user to retroactively deny permissions. You should review them up front and say up front...if my app requires specific GPS coordinates to work and you randomly decide to stop giving me permissions then there's a chance you'll get all pissy because the app stops working as intended. If I tell you my app needs X permissions then I should get X permissions or you shouldn't install my app. There's a reason I asked for them (regardless of legitimate or illegitimate reasons -- install apps from those you trust).

Re:Sounds like it worked (2)

Artraze (600366) | about 4 months ago | (#45680039)

> 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 probably a very small number of things guaranteed to be available, your contacts being maybe the only one. I'd hazard that the danger for the model as they had it was that an app might write something to the fake dataset and expect it to be there on the next read. Solvable as this all is, but they aren't trying.

Anyways, it was poorly conceived and poorly implemented and I don't mind it being gone. It ignored app permissions so that it would be active even for apps that requested nothing and made it difficult to identify apps that were actually problematic. More frustrating, it was targeted only at privacy and not security, which I'd think was just as much a concern.

> Personally it doesn't make much sense for an end-user to retroactively deny permissions.

You're assuming a perfect free market where there are infinite apps and you can find one that does exactly what you need and doesn't require any excess permissions. In reality, however, there aren't that many options. Sometimes there's only one: social games, bank, etc and that app requires more permissions than you want to give. Certainly you can go without, but why am I forced to let your app do whatever it wants on my device? Yeah, it's your copyrighted app, but it's not like I'm agreeing to install a GPS in my tablet, turn it on and ensure I have signal. So why can't I simply deny access to the GPS?

Honestly, the ability to revoke permissions would be great for developers too. There is (was?) a unit conversion app out there with two versions. One had currency conversion and needed an internet connection to determine the current rate. The other lacked the currency conversion and the internet permission. If users could revoke permissions or developers could set them as optional it would have made the second version unnecessary. A great deal of apps suffer the same issue. Most permissions are intended to be little niceties: a store wants GPS to find the nearest but could use zip code, an app wants contacts to auto complete but could just fire up the builtin contacts app. So on and so forth. Forcing permissions to be all or nothing forces develops to choose between adding features and appearing like a front for the NSA.

Re:Sounds like it worked (1)

mlw4428 (1029576) | about 4 months ago | (#45680313)

> Certainly you can go without, but why am I forced to let your app do whatever it wants on my device? Yeah, it's your copyrighted app, but it's not like I'm agreeing to install a GPS in my tablet, turn it on and ensure I have signal. So why can't I simply deny access to the GPS? Because that's like expecting Windows to work on a device that you, post-installation, ripped out the keyboard, graphics card, network card, HDD, 1/2 the RAM, and set the registry to only allow access to only one of the Hives, but you left the mouse. As a programmer, I design my application to do SOMETHING bearing in mind that I should have certain hardware and permissions to the OS. If you feel you can't trust my application then don't install it. It becomes a support nightmare and a functionality nightmare and a programming nightmare to try and code around every single user's specific desires as to what hardware/permissions I should access. It's a bad thing through and through -- the better approach is to have a special review process wherein you submit your source code/materials to Google, they review it, you pay a fee, and if everything is deemed safe, you get a "Google Trust Developer" type certification.

Re:Sounds like it worked (1)

Andy Dodd (701) | about 4 months ago | (#45680053)

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

Every single permission granted to an app is listed in that app's summary, and ALSO is explicitly listed in such a way that the user must accept the list when installing.

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

Re:Sounds like it worked (2)

StripedCow (776465) | about 4 months ago | (#45679661)

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 (1)

tepples (727027) | about 4 months ago | (#45679733)

All that'd mean is that the cut scene of an enemy force launching the missiles, which the game shows if there are no saved games (that is, on first run), would play again. No file system permissions means your game wouldn't be able to save the player's progress anyway.

Re:Sounds like it worked (1)

Sockatume (732728) | about 4 months ago | (#45679699)

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:Sounds like it worked (1)

beaverdownunder (1822050) | about 4 months ago | (#45679793)

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 better solved with refinements in the Google Play agreement (particularly regarding fine location data.)

Privacy, riiight (0, Troll)

Anonymous Coward | about 4 months ago | (#45679511)

A mobile tracking device OS maintained by a data mining company has privacy?

Crapware equals Google (0)

Anonymous Coward | about 4 months ago | (#45679515)

What other stuff has been an accident that they haven't mentioned yet?

Just plain wrong. (5, Insightful)

Anonymous Coward | about 4 months ago | (#45679545)

It always irked me when you install an Android app it often produces a big long list of the things the app can access, some of which you don't want it to, but you can't pick'n'choose the access permissions, it''s all or nothing.

That's just plain wrong.

And for Google to release an app which can allow you to set the access permissions of apps, and then withdraw it is even wronger (yes I know that's not a real word), even if changing some of the access permissions breaks the app there's the issue that many apps don't actually need to access everything on your Android device to run.

Re:Just plain wrong. (0)

koan (80826) | about 4 months ago | (#45679601)

It is also very odd considering how many more security issues and malware Android has compared to iOS.

Re:Just plain wrong. (2)

Andy Dodd (701) | about 4 months ago | (#45680069)

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:Just plain wrong. (1)

N1AK (864906) | about 4 months ago | (#45680179)

It always irked me when you install an Android app it often produces a big long list of the things the app can access, some of which you don't want it to, but you can't pick'n'choose the access permissions, it''s all or nothing.

You can choose not to install it. If you don't trust the app dev to correctly disclose what permissions they need then walk away. People will turn permissions off, break the app and then slate the app for not working. Better to build the app to test for permissions on launch, explain to users that haven't given all permissions that it can't run till they re-enable and close.

IOS? (0)

Anonymous Coward | about 4 months ago | (#45679599)

Then tell me how I can enable/disable apps from accessing cellular data on IOS on a per app basis? Article sounds trollish.

Re: IOS? (1)

Anonymous Coward | about 4 months ago | (#45679635)

Settings -> Cellular Data -> Use Cellular Data for

Re:IOS? (5, Informative)

Desler (1608317) | about 4 months ago | (#45679837)

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

a straw (2)

fche (36607) | about 4 months ago | (#45679621)

I wonder how many more overt measures that can be easily interpreted as pro-surveillance pro-advertising need google take, before the masses turn to alternatives like cyanogenmod etc.

Re:a straw (0)

Anonymous Coward | about 4 months ago | (#45680051)

327.

327 more overt measures.

Re:a straw (1)

SixGunMojo (177687) | about 4 months ago | (#45680175)

Masses? Never. I also came across a post, cant remember if it was on XDA or CM's g+ page, that App Ops was a big reason that CM wouldn't bake the Pdroid framework into the rom. Between that and CM trying to become Google certified I don't think they will ever be an option for privacy minded people. Which is a shame because I used to love CM. That and a few other issues, that I may concede have to do with them having to much focus elsewhere right now, is why CM isn't on my phone right now and I probably wont look at it again until after kitkat. Still appreciate everything they have done for the community though.

Deal breaker for sure (1)

BringsApples (3418089) | about 4 months ago | (#45679629)

I opted out of the whole smart-phone schtick a few months ago. I had an iPhone. I loved the feature that enabled me to disable certain apps from reporting certain things that I couldn't see why anyone in their right mind would want. If I was currently using an Android phone, this would make me toss it.

Re:Deal breaker for sure (0)

Anonymous Coward | about 4 months ago | (#45679841)

why? there are other roms that retain this functionality.. that's the beauty of open source if you don't like something they did, change it and compile it your self..

cyanogenmod is a great alternative, and i think ver 11 can encrypt text and mms messages

Re: Deal breaker for sure (1)

Anonymous Coward | about 4 months ago | (#45679861)

Wouldn't Android be reason enough to toss an Android phone?

Re:Deal breaker for sure (0)

Anonymous Coward | about 4 months ago | (#45680181)

So, you stopped using a smart phone for reasons unrelated to the topic at hand. Good story.

Eagerly awaited (4, Insightful)

dargaud (518470) | about 4 months ago | (#45679637)

I've been waiting for this for... forever. But not just [Enable]/[Disable], I also want [Produce random fake data] and [Produce data generated by external app hereby selected]. So that I can write or load an app that feeds intelligent but fake info to the others.

Re:Eagerly awaited (3, Informative)

dido (9125) | about 4 months ago | (#45679965)

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

Re:Eagerly awaited (2)

guardian-ct (105061) | about 4 months ago | (#45680037)

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 results are pretty easy to change.

"it could break some of the apps" (2)

csumpi (2258986) | about 4 months ago | (#45679687)

Especially the ones that slurp user data and send it back to the mothership, then whoever the mothership sells it to. I definitely see why they think it was not a good idea.

App Ops X (0)

Anonymous Coward | about 4 months ago | (#45679771)

Works with app ops x - https://play.google.com/store/apps/details?id=com.colortiger.appopsinstaller ...needs root...

Time to root! (0)

Anonymous Coward | about 4 months ago | (#45679795)

The AOSP has the code for this, and many distros integrated that feature, for example CyanogenMOD.

Am I the only one who sees this? (2)

The MAZZTer (911996) | about 4 months ago | (#45679805)

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

Look at it from a dev's perspective. (1)

BurfCurse (937117) | about 4 months ago | (#45679823)

It would be great for an App maker to be able to selectively ask for permissions from a user. But letting the user pick and choose what permissions they want ANY app to have creates a giant headache for app makers. Think about all of the permutations you have to test for if a user selectively grants permissions. Think about the intelligence of half the people who use smart phones. A user disables a critical permission, app fails to function, and user rates the app 1 star. And don't tell me its the dumb user's fault, cause you know the app maker is going to have to deal with it regardless.

That's Funny (1)

Greyfox (87712) | about 4 months ago | (#45679857)

It seems to be working great, even with some of Google's own apps. Comes out the same way whether I don't install an app because I don't think a fucking flashlight app should get network and GPS permissions or because that app breaks when it attempts to request them and it doesn't get them. I'm just less likely to install the app if I think the developer was just being lazy and requesting all permissions. Arguably I shouldn't be installing apps from bad developers anyway. Also arguably Google shouldn't be allowing them on their store in the first place (Including some of their own apps which apparently don't actually need all those permissions either.)

Makes sense (1)

gnomff (2740801) | about 4 months ago | (#45679863)

Why would you bake in the ability to disable things like network access when ad serving is the main source of revenue for app developers? Sounds like shooting the meal ticket to me. Ads are how you pay for content. If you don't like it you can build your own app and release it for free. The rest of us have to eat.

duh.... they are working with the nsa (0)

Anonymous Coward | about 4 months ago | (#45679879)

N S A

google spys (0)

FudRucker (866063) | about 4 months ago | (#45679929)

i dont trust google or their products, same with any other spyphones by Samsung or iphone, i do have a cheap tracfone but i dont trust it either, it stays at home a lot more often now that i know what i know, dont trust the internet or cellphones, DONT TRUST ANYTHING ANYMORE EVER AGAIN!

XPrivacy (1)

rimugu (701444) | about 4 months ago | (#45679981)

You mean not everyone is using XPrivacy already?! Ok, live and learn. Like when I actually first saw an ad in an android phone, mine never shows one.

Great in Theory (3, Interesting)

ironicsky (569792) | about 4 months ago | (#45680029)

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.

Xposed Framework (1)

mizkitty (786078) | about 4 months ago | (#45680139)

There's already an Xposed Framework Module that brings back App Ops on Android 4.4.2. The xPrivacy module is also an alternative.

Wrong direction (1)

coldmist (154493) | about 4 months ago | (#45680143)

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 permissions to give the app.

If this inconveniences the developer, too bad. Because as it is, I don't install those apps in the first place.

I have been quite disappointed that this isn't available. If CM has something like this, then I might just go to CM for all my devices.

Breaking Apps (0)

Anonymous Coward | about 4 months ago | (#45680187)

On a related note, I love how a BlackBerry flashlight app would require Internet connection in order to work. If I reject the permission to go online, it will not work at all. I love it. Tried three apps and all three fail to work properly when denied Internet access. /rant

For all my Android devices, I use LBE to assign permissions. Yes, it does require root, but that is easy to do on my devices.

The only app that "breaks" because I denied it access to certain information is the Minion Rush game. It would keep giving me coins for no reason when I am connected to the Internet and have the app running (normally you need to pay for them with real currency). I ended up getting 1000+ of coins before they fixed the issue.

Freedom (0)

Anonymous Coward | about 4 months ago | (#45680261)

But I thought Android was better.. because.. because freedom...

developer ego (4, Interesting)

spaceman375 (780812) | about 4 months ago | (#45680347)

By far the most annoying permission is abused by developers on every OS I've tried: Launch at boot. Of Course, YOUR app is so very important that it HAS to use time and resources just so it can be ready at all times. Get over yourselves: I'll launch it when I want it. I'd be WAY happy to just be able to deny that one permission on Android.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...