New Permission System Could Make Android Much Less Secure

capedgirardeau writes: An update to the Google Play store now groups app permissions into collections of related permissions, making them much less fine grained and potentially misleading for users. For example, the SMS permissions group would allow an app access to both reading and sending SMS messages. The problem is that once an app has access to the group of permissions, it can make use of any of the allowed actions at any time without ever informing the user. As Google explains: "It's a good idea to review permissions groups before downloading an app. Once you've allowed an app to access a permissions group, the app may use any of the individual permissions that are part of that group. You won't need to manually approve individual permissions updates that belong to a permissions group you've already accepted."

Comments

How is this a good idea?

[matthewmok]

I don't think it has to be explained why this is a potential problem. So then, it should be explained why this is such a great idea that the problems it creates are insignificant.

Re:How is this a good idea?

[markkezner]

This permission grouping is the exact opposite direction that Android permissions should be heading. There are a number of permissions, such as "Read Phone State and Identity" that should be broken up because they aren't even strongly related to each other.

Re:How is this a good idea?

[Anonymous Coward]

Its a great idea because most people are idiots who click 'Accept' anyway and this will mean less apps break. As for the problems.. what problem.. you wanting privacy is a bigger problem for Google's business.

Re:How is this a good idea?

[BasilBrush]

You'd have thought Google would have copied the iOS approach to permissions by now.

(Denying a permission doesn't stop the whole app from working if there are things that the app can do without the permission. Permissions are requested from the user when the app first tries to do the restricted thing. They may be accepted or denied, and may be changed at any time in the future.)

Re:How is this a good idea?

[Russ1642]

They should be moving towards a model where you can individually allow or disallow a permission, even if the app says it requires it. But this would cause chaos for all those apps that require 'full internet access' so they can push ads, collect data, invade your privacy, and molest your children.

Re:How is this a good idea?

[Anonymous Coward]

An informed populace is one that is less likely to install data miner software. To better advertise to its userbase, Google needs more of those dataminers installed on more Androids. Therefore, it is a good idea (for Google) to reduce the clarity of the permissions information. If successful, this may lead to a future build that simply installs applications without mentioning the permissions required, or, eventually, without even waiting for user input in the first place.

Re:How is this a good idea?

[0123456]

Yes, but that would help users block tracking and advertising, so it's a no-no.

The absurd permission demands from simple, crappy applications is why I'd love to see a real alternative to Android that doesn't cost Apple prices.

Re:How is this a good idea?

[bluefoxlucid]

FEWER YOU MOTHERFUCKER!!!!augahutauthasugacoduausaotuhsnaotdsanodfcr

Re:How is this a good idea?

[Anonymous Coward]

So get cyanogenmod. There, you can install an app and revoke permissions later. A simple use is to install "angry birds" (or similiar games) and then revoke the internet permissions. No more ads, the game still works. (It has to, to the game it merely seems like you aren't online at the moment.)

Also, android has a linux kernel, which means iptables-based firewalling works. So go ahead and block ad-servers and such.

Re:How is this a good idea?

[Anonymous Coward]

I'm fine ads. You want free ($) games and apps, you deal with ads. Or pay 99c and support the developer. whatever...

Most apps ask for very invasive permissions, like reading AND WRITING you address book. For social networking apps, that's kinda okay but why would e.g. truck racing game need access to your address book? Or location? Or Camera/Mic?

Re:How is this a good idea?

[0123456]

Duh. So it can sell that information to advertisers to serve targetted ads.

Re:How is this a good idea?

[Grishnakh]

The absurd permission demands from simple, crappy applications is why I'd love to see a real alternative to Android that doesn't cost Apple prices.

It seems like Cyanogenmod is probably the best alternative available right now.

Re:How is this a good idea?

[daviee]

1) A user review a long list of permissions and what it means per app, then grants/denies them individually
2) Group things into familiar/simple terms so even a non-technical user can easily see "this doesn't look right"

Re:How is this a good idea?

[kaladorn]

I'd agree entirely with that.

I'm already not sanguine about the permissions apps ask for (and in fact, several security research firms have pointed out the risks). Often times, a well meaning dev will explain that he has to have X permission because google has buried one particular function (not always obviously related) into that permission and that function makes sense for the app. You almost get the feeling the dev is apologetic in many cases and would like to just have a single finer grained permission.

It's okay to HAVE permission groups, but you should also have very finely grained permissions. Good companies and devs would only use the fine grained ones that did the MINIMUM they needed to do. And one would then not install overly broad permission groups.

Why is Google putting the work of vetting permission groups and understanding the implications onto end users versus onto themselves and the devs for apps? This smacks of something for lazy devs versus something for consumers.

And one more thing: How about installation require the minimum number of permissions to make the basic app functions work and additional permissions queried and granted/denied if optional features are enabled?

I have a lot of apps that want permissions for social media integration and I'm not on that boat and will never use that part of their app. Why do I need to open that security door to install since the rest of their app functions fine without it?

Mobile development seems to be about as poorly thought out (API wise and design wise) as PC software was in the early days of GUIs.

Re:How is this a good idea?

[Anonymous Coward]

>They should be moving towards a model where you can individually allow or disallow a permission, even if the app says it requires it.

It's sad that the competition lets you do this, but Android doesn't. Whither BlackBerry.

Re:How is this a good idea?

[tepples]

No more ads, the game still works. (It has to, to the game it merely seems like you aren't online at the moment.)

Until it disables starting the game because the player hasn't connected to the Internet for weeks.

Re:How is this a good idea?

[Anonymuous Coward]

Also, android has a linux kernel, which means iptables-based firewalling works

Not necessarily.

On my phone the kernel was built without iptables support.

I had to beg for the modified kernel sources, wait 3 months to get them, and then waste a lot of time to learn about the stupid idiosyncrasies of 'android is not gnu', just to get that standard linux feature working.

Re:How is this a good idea?

[Paco103]

I don't get why. I have PrivacyGuard on CyanogenMod, and it allows me to individually approve or deny permissions. So far, no app has broken in any strange, unexpected way. Some apps ask for SMS permissions because they have the ability to text friends for shares. I deny that ability, because I don't use that feature. It may be legitimate, or they may have provided a legitimate excuse to mask more nefarious behavior. Likewise, I've blocked GPS access to all apps except maps. For anything else (weather, yelp, etc), broad tower based location is good enough. I deny internet access to any app that doesn't have a legit internet need. Google can still display ads if they want, the google services have access, let them proxy ads. Very few apps have access to my contact list. I have not seen a single application fail to do what would be expected based on the permissions I grant it. It also lets me see how many times an app requests certain permissions, and it's amazing (and a little comforting) to see how many apps never request unusual permissions that they ask for at install.

Re:How is this a good idea?

[Paco103]

Why not both? Show them to me in grouped lists that I can blanket accept, and that expand with allow/disallow options when I click the group.

Re:How is this a good idea?

[Chalnoth]

The problem with moving in that direction is that this moves Android in the direction of TOS agreements: nobody bothers to read TOS because they're too long and take too much time to read.

Sure, it's true that grouping permissions reduces how fine-grained the information is, but it also lowers the cognitive burden, making it more likely that people will actually pay attention to the permissions that an app has. Users should naturally assume that an app that has SMS permissions may, at some point, send SMS messages, and should therefore be wary about installing such apps.

Re:How is this a good idea?

[amjohns]

Especially if you value your privacy, and battery life

Re: How is this a good idea?

[BorgDrone]

No, you do it like apple, ask it when the app uses it first, that way the user can place the request in context. If you click on 'upload photo' in a social media app and it asks for permission to access your photo's, you know that makes sense and grant permission. If a calculator app asks the same when you start it, you know something's fishy. Asking upfront is the dumbest thing ever, the user hasn't even started the app once so has no way of knowing if the requested permissions make any sense.

Re:How is this a good idea?

[viperidaenz]

Maybe they meant smaller apps break and bigger ones don't?
Or they break when you take part of them away?

Re: How is this a good idea?

[gnoshi]

Actually, I think the best way is to do it like both. List the permissions (in groups, sure, that's fine) so that users can decide not to install the torch app which requests permission to their contact list and text messages at all (because you can bet if it is doing that then when an exploit appears one day that developer will pounce) and then on-demand so users can choose whether an app should have permission to XYZ in context. Using Facebook: at one point its app grabbed your phone number and sent it to Facebook before you'd even logged in for the first time.
(For updates, I think it is insane not to require approval for permission changes within groups. 'Why yes, twitter, I know you only wanted to read my contacts and SMS but sure you can delete all my message, contacts, and calendar entries').

Ideally, I think having a default set of options (e.g. Allow or Ask) for permissions, and then at install time when the groups are being shown having the ability to choose to change them (for the more unusual users who want to do it at that point), and finally doing the iOS ask-in-context so that you can see that XYZ app only wants to look at your contacts when you click 'find friends using the service', not 8 seconds after installation and before you even have an account.

There are other issues too: e.g. how do you force an app to only be allowed to record audio or take images from the camera when in the foreground. It would be good to at least get the broad brush strokes right first, though.

Re:How is this a good idea?

[Alain Williams]

For those apps that absolutely demand access to something, then you should be able to fake it. So: the app that demands access to your address book, you give it one with a couple of bogus entries. It is my machine so I should get to choose what is allowed.

I suspect that most users will not bother or just don't care and so will not check permissions - for them it is easier to complain & blame someone else when they get a problem.

Re:How is this a good idea?

[Anonymous Coward]

A simple use is to install "angry birds" (or similiar games) and then revoke the internet permissions. No more ads, the game still works.

Oh what a great idea, strip developers of revenue!

Re:How is this a good idea?

[exomondo]

This is why as mobile internet service gets better more things move to "the cloud", it's the logical solution for supporting an open platform where (some) users are too cheap to pay for the no-ads version and too cheap to pay for bandwidth for the ad-supported version.

Re:How is this a good idea?

[exomondo]

For those apps that absolutely demand access to something, then you should be able to fake it. So: the app that demands access to your address book, you give it one with a couple of bogus entries.

Android is open source, there's no reason you couldn't modify it to support that.

It is my machine so I should get to choose what is allowed.

You can, you get to say allow or disallow. Beyond that you may need to modify the OS yourself, which you also can do.

Re:How is this a good idea?

[exomondo]

The absurd permission demands from simple, crappy applications is why I'd love to see a real alternative to Android that doesn't cost Apple prices.

Why do you need an alternative to Android just for this one issue with Google Play? Why not just modify Android and use the 3rd party app stores, seems a lot simpler than an entire new operating system.

Re:How is this a good idea?

[Anonymous Coward]

It is my machine so I should get to choose what is allowed.

You can, you get to say allow or disallow. Beyond that you may need to modify the OS yourself, which you also can do.

I can allow or disallow an app installation. What I cannot do with a standard Android system is disallow part of an app. I either install it or don't. And the change they've made here opens the door so that when I trust an app to do one thing, it can turn around and do something else entirely because Google decided the two actions are related, even though one is acceptable to me and the other is not.

Seriously looking like time to reimage my phone with Cyanogenmod.

Re:How is this a good idea?

[Zontar The Mindless]

Some folks in Oxford would like to have a word with you, mate.

Re:How is this a good idea?

[Anonymous Coward]

if (dataconnect == false) {
      alert "This app requires internet connectivity"
      exit
}

Re:How is this a good idea?

[exomondo]

Yes that's what I said, you do get to choose what is allowed and disallowed, if you want finer grained control then add it to the operating system.

Re:How is this a good idea?

[IamTheRealMike]

I don't think it has to be explained why this is a potential problem. So then, it should be explained why this is such a great idea that the problems it creates are insignificant.

The Android permissions model is a mess and has been since day one, but not in the way most Slashdot geeks are up in arms about. When was the last time you actually looked at the full list of permissions? It's ridiculous. You have to be an Android developer to understand some of them. Many are pointless in the extreme: the result of simply associating every API with a permission whether it makes sense or not. Do I really need to know that an app might use the vibrator when I install it? A few permissions aren't even written in understandable English, so god knows what they become when translated into a language like Arabic or Chinese.

What's more, others (like the internet access permission) have never worked. People think it means "you can give this app personal data and it can't upload that data to the internet", but it never did that, because for example there are OS services that let you configure them to retrieve and process data from arbitrary URLs. The media player component does that. You can ask the OS to play music from a URL without having internet access permission, and it'll do it, so just put your personal data into the URL of your "music file" and the data gets uploaded. Heck even just invoking the web browser with a long mystery URL will let your internet-less app upload small amounts of data to the net. And there's no real way to fix any of this because any app that exposes services to other apps that involve downloading from a user-provided URL would end up breaking the "can't upload" model. So now they're hiding the internet access permission entirely, and good riddance.

Conclusion: the permissions framework was badly thought out. It was designed to let you know when apps might do something nasty to the OS, as a way to defend against aggressive apps that would otherwise do what they do on Windows and reconfigure the entire computer at install time. But there were no UI guidelines about how and when to use it, so it became a dumping ground for technical nonsense hardly any users understand. Worse, over time people's expectations have changed, and now some of them want it to be some all singing all dancing privacy framework that gives you a million knobs to tweak, even though it was never meant to be that.

Perhaps in future Android will actually get an all singing, all dancing privacy framework that does what people want, but it probably won't be a part of the app permissions system, which is meant to be for security. And it's not easy. A lot of the hacks people throw around in this thread could be easily detected and apps could just refuse to run entirely if you try and fool them.

Re:How is this a good idea?

[Hognoxious]

Don't have kids, do you? I'll do a quick survey when I go to pick the hoglet up and see how many shirts, bags, hats and so forth I see.

Re:How is this a good idea?

[Hognoxious]

Yeah, like a hierarchy you can drill down into. Similar to when you install (beurk!!!) MS Office.

The reason, of course, is that it's a perfectly sensible suggestion, but we're talking about Google here.

They rode to fame by getting one thing right[1] - the search engine. Since then, if they produce anything good they either drop it or fuck the UI up.

[1] or at least less wrong than everyone else at the time. Anyone remember when Altavista was good?

Re:How is this a good idea?

[dave420]

You can get this functionality on rooted phones already.

Re:How is this a good idea?

[jareth-0205]

I'm not sure this is a change in permissions so much as a change in how they are displayed. I'm a developer and there's been no change for *us*, the separate permissions are still necessary. They have grouped them presumably to make them easier to understand for the end-user.

Re:How is this a good idea?

[coinreturn]

Do I really need to know that an app might use the vibrator when I install it?

That really depends on where you plan to stuff your phone.

Re:How is this a good idea?

[phrostie]

does anyone know what CyangenMod will be doing?

Re:How is this a good idea?

[Anonymous Coward]

They rode to fame by getting one thing right[1] - the search engine. Since then, if they produce anything good they either drop it or fuck the UI up.

Or, more commonly, both.

Re:How is this a good idea?

[dgatwood]

For those apps that absolutely demand access to something, then you should be able to fake it. So: the app that demands access to your address book, you give it one with a couple of bogus entries. It is my machine so I should get to choose what is allowed.

IIRC, that's basically what iOS/OS X does. If the user denies permission, the OS provides the app with an empty address book that (AFAIK) is indistinguishable from a device on which the user hasn't added any contacts.

Re:How is this a good idea?

[dgatwood]

Sure, you could do that, but I'd expect any app that tried it to get low enough ratings that people would steer clear of it. After all, lots of tablet-like devices have an Internet connection only when you're at home or near another open Wi-Fi connection.

Re:How is this a good idea?

[wolja]

They should be moving towards a model where you can individually allow or disallow a permission, even if the app says it requires it. But this would cause chaos for all those apps that require 'full internet access' so they can push ads, collect data, invade your privacy, and molest your children.

Oh yeah this. Of course removing the permission from an App like say Kindle or a game that has no need to read SMS or phone calls would have course remove the ability to secretly and maliciously steal and sell metadata.

That would be an evil Google wouldn't allow.

Whew

[Anonymous Coward]

Makes me glad I run a Windows 8.1 phone.

Re:Whew

[GuyverDH]

Alert! Alert! Sarcasm overuse detected!! (at least I hope that's the case).

Re:Whew

[rogoshen1]

Hey! I also use a windows phone. And the truth is, without any apps available to install (period), my privacy is still intact.

Re:Whew

[Anonymous Coward]

You mean you run THE Windows 8.1 phone...

Re:Whew

[Agent0013]

Did you really think the OS itself, written by Microsoft, isn't invading your privacy?

Oh wait, I see you have been modded +5 Funny, now I see that this is a joke! Whew!

Re:Whew

[Anonymous Coward]

Well in fairness, Microsoft admitted they could make wp less secure than android if they could figure out how to put back a file manager. But i still laughed at the make android less secure line. Any attempt to make android less ecure will make it more secure. Thats how bad it is. Still, it's a perfect OS for shit you are going to throw away anyway.

Re:Whew

[findoutmoretoday]

Even Microsoft would have hesitated to do what Google does. You enabled GPS? This means you agree to use your data connection or do we shut the GPS off etc. And those apps will give me five days of battery or sometimes one day, so maybe Windows is not a bad idea.

AppOps

[Anonymous Coward]

Hey, Google. If you're going to jack with play store permissions, at least give us back AppOps.

Or, I'll just...you know....run it myself.

Re:AppOps

[buswolley]

Anyone use SnoopWall? It allows fine-grained permission setting after installation of an app
http://www.citeworld.com/artic...

I'm wanting a review :)

cyanogenmod?

[DoofusOfDeath]

So this is a bit off-topic, but probably the right time to ask...

I've been increasingly concerned with my lack of control over my Android (Verizon) phone. This current issue lies in the same area as my earlier worries.

Is this the kind of problem that cyanogenmod addresses? I didn't have the time, or ability to live with a broken phone, to try it out earlier. But I'm about to stop traveling so much, so I'm wondering if it's time to give cyanogenmod a try.

Re:cyanogenmod?

[wbr1]

No. Rooting will allow you to remove unwanted apps that are locked on by the manufacture or carrier, as well as give you access to the entire file system.
Using an alternate rom (ie cyanogenmod) will allow you to use different android versions, with different (or no add on) UI. These are things like touchwiz or HTC Sense. The permisions system for apps remains the same. Also, cyanogenmod and other ROMS may not support all your hardware or be stable (but then again some carrier builds are not that great either).

There are programs that when rooted will allow you to block access of apps to certain subsystems, giving finer grained control, but it is not automatic, you have to go in and do it yourself, and that is regardless of the ROM/android version.

Re:cyanogenmod?

[DoofusOfDeath]

Thanks. But is it safe to say that with Cyanogenmod, it's at least possible to install an app / tweak that will refuse to let apps use certain subsystems (such as GPS) if I so choose, whereas I have no such control with the carrier-supplied Android version?

Re:cyanogenmod?

[Anonymous Coward]

I've done a lot of custom ROM installations, and many of them to support AppOps to expose these granular permissions. Cyanogen has actually expanded upon this functionality.

Re:cyanogenmod?

[Anonymous Coward]

Yes. It absolutely IS possible. Cyanogen calls it Privacy Guard, and I have it enabled by default, such that anything I install from Play automatically gets blocked unless I go in and enable something specific.

Re:cyanogenmod?

[wbr1]

Good info. I haven't used cyanogenmod for some time, so I was not aware that was baked in. I used to use an app on my rooted devices (regardless of android build) for it, but now I am just picky about what apps I actually install.

Re:cyanogenmod?

[Anonymous Coward]

Like I said, CM is just the one I prefer. I know OMNI bakes it in, too (at least up to the AOSP4.4.2) and many others probably do as well.

Re:cyanogenmod?

[c]

Is this the kind of problem that cyanogenmod addresses?

With limits, yes.

CM's privacy guard allows you to block apps from getting at your address book or SMS and such. It also allows you to control things like camera/microphone access. And you can even disable background apps and notifications (for example, I have Facebook pretty much tuned so it can't do anything more than it can in a web browser).

One notable thing CM doesn't do is allow you to prevent Internet access for apps. I read that this is to prevent someone from downloading an add-supported app and then cutting it off from its ad networks. I order to do that sort of thing, you usually need to root and install a firewall or some other ad blocker.

Quite frankly, if you've got a phone that's out of warranty or no longer getting vendor updates, installing CM is worth looking into. It's a bit of a pain in the ass the first time (at least it was for my devices), but after that it's pretty smooth sailing.

Re:cyanogenmod?

[rwise2112]

No. Rooting will allow you to remove unwanted apps that are locked on by the manufacture or carrier, as well as give you access to the entire file system. Using an alternate rom (ie cyanogenmod) will allow you to use different android versions, with different (or no add on) UI. These are things like touchwiz or HTC Sense. The permisions system for apps remains the same. Also, cyanogenmod and other ROMS may not support all your hardware or be stable (but then again some carrier builds are not that great either).

There are programs that when rooted will allow you to block access of apps to certain subsystems, giving finer grained control, but it is not automatic, you have to go in and do it yourself, and that is regardless of the ROM/android version.

Once you are rooted, on any ROM, you can install XPrivacy or PDroid to completely control application access to your data.

Re:cyanogenmod?

[Anonymous Coward]

Is this the kind of problem that cyanogenmod addresses? I didn't have the time, or ability to live with a broken phone, to try it out earlier. But I'm about to stop traveling so much, so I'm wondering if it's time to give cyanogenmod a try.

Yes it sucks to go thru hoops to root and or crack boot loader yet once you do you have a device *you* actually own and control.. not the carrier, not google, not app vendors.

Cyanogen with AppOps and AFWall+ is awesome but not perfect.

AppOps does not currently allow you to deny an app ability to obtain device ID/phone number yet it does restrict access to most everything else: location, contacts, SMS.

With AFWall+ denying wifi and or cellular network access to an app is awesome for apps you distrust to behave themselves.

As is I don't use or have google play services. Use a downloader to download the few free apk's I care about and sideload the ones I want. Fortunately few paid apps I have was able to purchase a license directly from vendor yet this is by far the exception.

No constant battery drain of google sync shit running all the time, installing or updating software when it feels like or oh shit... this app was updated and now it sucks and I can't go back to the version that does not suck... Cyanogenmod includes tethering via USB, WiFi and Bluetooth out of the box and they all work flawlessly. Backup and restore from recovery (CWM,TWRP) are priceless. I would never have purchased an android phone without knowing these options were available.

Cyanogen for me has been almost perfect with no major problems, no crashes and is updated constantly v. original vendors who never update their bloat ware infested hardware.

Re:cyanogenmod?

[Anonymous Bullard]

I've done a lot of custom ROM installations, and many of them to support AppOps to expose these granular permissions. Cyanogen has actually expanded upon this functionality.

Google have chosen to remove user access to AppOps from recent Android releases and while CM's Privacy Guard is a slightly improved and much easier to use approach on those system calls it requires a custom ROM and even those are still limited to a minority of devices. (Hint: consider only buying devices that will be supported by custom ROMs!)

There is something that is more comprehensive and granular, although more complicated to use as a result. XPrivacy is built upon the well-known Xposed framework (requires root) and it lets the user to control essentially all permissions individually.

Here's a brief and useful recap by xda-developers about the main options.

Re:cyanogenmod?

[farble1670]

Rooting will allow you to remove unwanted apps that are locked on by the manufacture or carrier

on any semi-modern version of android you can already do that. you can "disable" any app to keep it from running, ever. the bits are however still there, but they aren't taking up RAM so it does not matter (they are included in the firmware).

Re:cyanogenmod?

[Rich0]

Glad to hear that they changed their tune. For a while Cyanogen was fairly opposed to letting people selectively restrict permissions. At one point he enabled it in a way that basically broke most apps, in the seeming home that the people asking for the feature would go away figuring that it just wasn't possible to do. The problem is that people had been doing this for a while even at that time by intercepting the API calls.

I would love for it to be like XPrivacy. I can feed random data to any app, change it at will, or even just type in the data that I want to feed it (I've always wanted to live in Fiji... :) ).

you should be able to...

[alrudd1287]

cripple apps by denying parts of their permission request. right now its all or nothing

Re:you should be able to...

[DoofusOfDeath]

cripple apps by denying parts of their permission request. right now its all or nothing

Funny, I was expecting this crowd to have fantasies of crippling those apps' developers.

I mean seriously, $(app vendor), your app does not need access to my location and/or phone calls in order for me to do $(menial computation X).

Re:you should be able to...

[Anonymous Coward]

iPhone has been doing this for years.

Don't want to allow location services to that movie times app you have? Fine, the app still runs perfectly but you just have to manually input a zip code to do local searching.
Don't want to allow Facebook access to your photo library? Great, everything else works, but you can't upload/download photos.

I've never understood this all-or-nothing approach on Android, it's really one of the few areas where Apple is absolutely better.

Re:you should be able to...

[PRMan]

But the marketing department put it in the Agile Tracker and the PM told me I'd be fired if I didn't move that box....

Re:you should be able to...

[RavenLrD20k]

In fairness, while Location is completely optional and generally unnecessary unless the app is designed for the user to make use of the location data, it is generally a good practice for apps to watch for phone calls just so if there's one that comes in while you're performing $(menial computation X), the app state can be saved to storage and the app suspended so if Dalvik decides it needs to free up the memory resources in the middle of your call there's still a way for the app to recover where it was in its calculations. The reason you want your app monitoring the phone system instead of trusting that OnPause() is going to get called when a phone call comes in is simply that you cannot trust that the Phone App will not cause Dalvik to simply destroy the app instance without allowing calls to OnPause() or even OnStop(). This is especially true on lower end phones that don't necessarily have the memory to spare to run apps in the background when the phone, a memory hog in itself, activates.

Re:you should be able to...

[lgw]

the app state can be saved to storage and the app suspended

What is this, the 90s? Your app should always be in a "saved" state, or at least a safe one. From consumer apps to backend transaction process, it should always be OK if you suddenly lose power. 20 years ago, I/O performance was so wretched that you just couldn't do this, but today there's no excuse.

Re:you should be able to...

[jeffmflanagan]

>Funny, I was expecting this crowd to have fantasies of crippling those apps' developers.

There is a lot of insanity and paranoia at /., But I haven't ever seen calls to cripple anyone.


>I mean seriously, $(app vendor), your app does not need access to my location and/or phone calls in order for me to do $(menial computation X)

No it doesn't have to, but a developer has the right to require whatever permissions they want in return for their (probably priced at $0) work. The user has the right to accept or reject those terms. This just got more complicated, but everyone still has their rights.

Re:you should be able to...

[kaladorn]

Want to backup your Notes? Oh wait, that's a hidden db and you need a @me.com email address...

It isn't a permission per se but Apple has a lot of their own lock-in in how they do things.

Re:you should be able to...

[tepples]

Are you aware of how slow the NAND flash is on some devices, especially the 8 GB Nexus 7 tablet? Or how it'd wear out the flash to be saving a megabyte of state in a game every second?

Re:you should be able to...

[amjohns]

Uh, No

Notes can be synced to any IMAP server

Re:you should be able to...

[exomondo]

Want to backup your Notes? Oh wait, that's a hidden db and you need a @me.com email address...<br><br>It isn't a permission per se but Apple has a lot of their own lock-in in how they do things.

Why are you trying to redirect the conversation to something else? Yes Apple has a lot of lock-in: Facetime, Airdrop, Airplay, Lightning, etc... but that's not relevant. The point is iOS's security model is better than Android's, iOS has copied so much from Android recently maybe Android could copy their security model.

Re:you should be able to...

[Anonymous Coward]

Apologists aren't ever welcomed. Not here. Not anywhere. You apologize a lot on this website ergo.....

Re:you should be able to...

[Bite The Pillow]

I turned off all updates per app. Every time it requires an update with new permissions it gets a one star review with explanations.

More people need to do this, but don't.

Re:you should be able to...

[Neil Boekend]

Not exactly always, but there should be a really good reason when not to recover to the previous state.

My bank app doesn't recover to the previous state and that is how it should be. Any clear interruption should require a new login for banking information.

Re:you should be able to...

[rastos1]

I mean seriously, $(app vendor), your app does not need access to my location and/or phone calls in order for me to do $(menial computation X).

You mistakenly assume that "for you to do $(menial computation X)" is a reason why $(app vendor) wrote the app. It's not. He wrote it to make money. From advertising. Which can be done better if he can "access your location and/or has access to your phone calls".

Re:you should be able to...

[sjames]

I REALLY wish the phone calls permission was split up. I don't mind apps being notified of ringing, off hook and on hook. In most cases, that is all that is needed (or justifiable) for the app to operate as desired. I do mind handing every other app the ability to make calls, or to know who is calling and who I call. The vast majority of all apps that require access to phone calls only need it to save off as you said or to pause/duck audio output when a call is incoming. They don't need to know who is calling.

Re:you should be able to...

[RavenLrD20k]

Do you seriously want to have apps that seem to hang for 2-5 seconds every time a button is pushed just because it needs to save its state before it enters a new one? Most phone apps do not do anything where they need to have their state saved from one moment to the next. The only times you want to have an app continuously saving a file is if it's editing a local document of some kind. If you do happen to have an app that needs to keep persistent data from instance to instance, that's what the OnPause() or OnStop() methods are for. Then this data can be loaded back in when the app regains foreground by using the onResume() method, or regains visibility by using the onRestart() method.

Seriously, read up on the Activity Life Cycle so you can begin to understand what you're talking about.

My post was about what happens when the Phone App takes over. In my development experience, when the phone App takes over, the apps don't always get to perform the OnPause() or even the OnStop() methods before they go straight to OnDestroy(). Having the app actively listening for the phone call event (which occurs about 2 seconds before the phone system activates the phone Application) will give your app an extra bit of time to get the app state saved and properly stopped before the memory manager starts performing an aggressive cleanup to make room for the phone App (this is especially true on low end phones that don't have a substantial amount of application memory to work with).

Re:you should be able to...

[RavenLrD20k]

In this, I completely agree with you.

Re:you should be able to...

[lgw]

Sure, plus for stuff like file editing you need to save undo history, so that it's always OK to save. It's not trivial, the right way may not be obvious, but development is a skilled profession and this is within our abilities.

Re:you should be able to...

[lgw]

Do you seriously want to have apps that seem to hang for 2-5 seconds every time a button is pushed just because it needs to save its state before it enters a new one?

Do you seriously believe that's how it has to work? Choose your RPO and RTO appropriately for what you're doing. If you're playing a game and the battery falls out of your phone, how many seconds of lost gameplay will be acceptable? More than 1, to be sure. Sure you might do things a little better if you had some fore-warning, but since I'm not going to allow any app that wants access to my "phone activity" (since that could mean anything with these stupid permissions) maybe you won't get that.

Ugh...

[Anonymous Coward]

Wish Google would go to the same "ask first" permissions model as everyone else. This is one possible reason why Android keeps getting a rep for malware.

The Xposed framework helps, but as of Android 4.4.3, it can't be used due to recent SELinux code changes.

Adding flaws to flaws

[wbr1]

The system was already flawed in that normal users could not lock out permissions from specific apps. In addition, not many pay attention to the permissions used by an app anyway.

If users aren't paying attention (I do, my flashligh widged and scientific calculator do not need SMS or contact access thank you), then no amount of tweaking by adding or removing complexity will help.

As much as I hate walled gardens, I guess the hope is that the play store is well curated enough to remove most significant threats.

Re: Adding flaws to flaws

[Anonymous Coward]

The PlayStore isn't curated at all.
The automatic malware detection system 'Bouncer' is useless and detects less than 30% of all the malware. There IS malware in the PlayStore.

I want silent denial

[Anonymous Coward]

One feature I really want on my cell is the ability to tell the app that I've given it all the permissions it is asking for, but behind the scenes remove that ability from the app. This is especially for apps like games that ask for all permissions, but only really need a few. I should be able to accept the game onto my system and then after adjusting the app's permissions, it would receive garbage contact details, garbage friend details, garbage location data, garbage file listings, messages go to /dev/null, etc.

I'm sure if I root my device I could do something like that, but I just wish something like that was built in. {I kinda feel safer in my walled garden, easier to recover from garbage apps.}

Re:I want silent denial

[gigne]

This. This is what I want too.

Anyone, does this exist without root?

Re:I want silent denial

[PRMan]

This will never exist without root, but it sounds really fun.

Re:I want silent denial

[PRMan]

Actually, somebody posted it below: http://repo.xposed.info/module...

Then load the XPrivacy module. The thread is here: http://forum.xda-developers.co...

Re:I want silent denial

[PRMan]

And here is how it works: https://github.com/M66B/XPriva...

Re:I want silent denial

[MobyDisk]

This is what Windows does with UAC virtualization. An app wants to write a file to C:\Program Files\MyApp\Data and Windows redirects the file elsewhere. (Although Windows does not have fine-grained permissions like Android)

Re:I want silent denial

[Kalriath]

He said without root.

Re:I want silent denial

[Anonymous Coward]

My jailbroken iPhone runs an app called "PrivaCY" that does just this. I would be surprised if something like this doesn't exist in the Android extended ecosystem as well.

Re:I want silent denial

[Anonymous Coward]

Errr...I meant "Protect My Privacy"

Re:I want silent denial

[canadiannomad]

I would love this... Now if only it didn't require rooting the device.

Re: I want silent denial

[Teranolist]

whats so bad about rooting your device? loosing warranty? Honest question here, for me living in germany its no problem since only handling the hardware wrong will break the warranty fot it, changed soft-/firmware is irrelevant for the hardware part. Of course I cant make them responsible to restore the software if I fuck up while flashing, though

Re:I want silent denial

[buswolley]

SnoopWall from what I hear.
http://www.citeworld.com/artic...

Re:I want silent denial

[buswolley]

I don't think it requires rooting. You do give it admin access however, which makes sense.

Re: I want silent denial

[neminem]

What's wrong with rooting your device is that it takes a ton of research to figure out how to do it, that research is different for every device, and if you do it wrong, you can totally screw up your device, and if you're *lucky*, it'll take a bunch more research to figure out how to un-screw it.

I did root my device (installing cyanogenmod), because I got tired of not being able to uninstall a bunch of crapware that was installed on it. I would have been much happier if I hadn't had to, though, given the time it took to figure out how to get it installed. Cyanogenmod is pretty neat, but I wish those features were just incorporated into native Android.

Re: I want silent denial

[Anonymous Coward]

So there's nothing wrong with rooting your device. You're just bitching that it is hard. Well didn't your daddy ever tell you that anything worth having means you have to work for it?

New Permissions

[vandon]

Just finished updating a few apps on my phone.
Adobe Air has a new permission group it requests. However, on the 'here's the permissions Air is requesting' pop-up after you hit the update button, they no longer mark the new permissions with "NEW". So now you have to cancel out of the update and go check each and every app you're going to update to see what the new permissions it's requesting.
Totally stupid move by Google to not even mark the new permissions with 'NEW'

Re:New Permissions

[Pow]

Hint: you can still see the onld screen with new permissions marked as NEW by scrolling all the way down in app description to PERMISSIONS and clicking on"View details".

But I completely agree with you. Totally lame move by Google. I want to see this screen when I press the update button. Config option for advanced users would be sufficient.

Do not want.

[khellendros1984]

I routinely deny apps their updates because I don't like their modified list of permissions. This sounds like it'll make it harder for me to use my phone the way that I want to (which is the reason that I decided against an iOS phone in the first place). Google, you're whittling down my reasons to stay with your devices (or at least with the stock OS).

Re:Do not want.

[sigmabody]

I will not willingly buy another Android device. Google has proven to me that their goals, with respect to my privacy and control of my data, are completely opposite of mine. Their philosophy is just not for me.

Xprivacy

[SuperBanana]

Install XposedFramework:
http://repo.xposed.info/module... ...then the Xprivacy module.

This isn't a great option for many, however, as you need root access. It does give you extremely fine-grained control over permissions, and includes options like randomizing (on each boot) the garbage data returned to apps to keep them happy.

Xposed is great; the GravityBox module, for example, has a ton of interesting and useful functions, like setting your cellular radio to 2G when connected to wifi, a mode to have an increasing ring, a network speed indicator, etc.

While I'm plugging Android software I use: the F-Droid open source repository is full of nice stuff (like AdAway.)

https://f-droid.org/

Dumb idea.

[gstoddart]

I want to have a settings page where I can go in whenever I want and selectively disable permissions.

This just sounds like more dumbed down version.

And, cynically, I believe that Google is doing this to ensure they can still collect data on you, and the people using their advertising services can continue to do to.

This is why when I download a new app, the first thing I do is try it in airplane mode. If it's not an application which should require access to the interwebs, but tries to access it, it gets deleted.

I must say, I'm disappointed in this. Because I want more control over app permissions, not less.

Re:Dumb idea.

[synapse7]

Why don't you review the permissions from app settings, gives you a break down on time and what was accessed. Google keyboard that I don't used accessed my contacts 50 minutes ago.

Re:Dumb idea.

[alen]

it's the app developers

free apps they collect and sell the data to you know, make some money

Re:Dumb idea.

[Scott64]

I have settings like that in the AOKP-based ROM that I use. It's in the settings, it's called "App Ops" (down near "About Phone" and "Accessibility Settings"). It tells me what permissions are currently granted to each app and when that permission was last used. If I don't know why an app needs a certain permission or I don't like that it has it, I just uncheck it.

Re:Dumb idea.

[jader3rd]

And, cynically, I believe that Google is doing this to ensure they can still collect data on you, and the people using their advertising services can continue to do to.

Given that's how Android is profitable for Google why shouldn't they be doing this?

Re:Dumb idea.

[Anonymous Coward]

Isn't this after the fact the information has long been sent to advertisers?

Re:Dumb idea.

[cant_get_a_good_nick]

I swear this is not flame-bait, but this is one reason why i like the iOS model. Selective perms. Even there, Google apps ask for too much. I disable a lot (e.g. location and microphone for Google Search).

Google seems to not like this. If you don't have location turned on for Google Search, all of Google Now gets turned off, even for explicit things i ask for that they don't need my location for. I specifically asked for Bulls news (yes, Im a masochist), you don't need to know where I am to show this. But Google doesn't show.

And even the old model wasn't all that good on Android. If I have an update, they'd ask for the new perms (not able to select any, it's all, or not update) or they give an option to delete the app. The implication is that you might as well push through the new perms, or delete the app as (nearly) useless.

In theory bad, but in reality not so bad

[Maxo-Texas]

The fact is, if an application is desired... and isn't abusing the privileges currently...

Then 99.9% of users simply click thru a list of 17 permissions the same as they do for a list with 5 permissions.

s/could/does/

[maliqua]

fixed that for ya

not straightforward

[Anonymous Coward]

A whitelist permission system makes sense in theory but has the following problems
- too many permissions confuse the user and have the OPPOSITE effect (they just ignore the permission request). Heck I'm a techie and I admit I don't read the entire SCROLLING list of permissions everytime I install an app!
- not granular enough - the risk of not being granular enough or being too granular.
- unclear what you are granting and borders often aren't solid.

add to this google has not come up with OPTIONAL permissions, where the user can choose to only grant some of them and the program must adjust/check for this.
add to this there's no nontedious way to CHANGE the permissions (AFAIK, happy to be wrong - and no uninstall and then reinstall IS tedious) post install.

It's a mess. I suspect they were hoping to address the confusion/ignoring part, but I agree it seems a bad approach

Re:not straightforward

[Anonymous Coward]

- too many permissions confuse the user and have the OPPOSITE effect

No problemo. The "common user" just click through - fine. But having a fine-grained permission system means that the specially interested can see what's going on. It only take one to expose an app that does something unwanted. And then everybody else either ditch the app, or download a countermeasure (such as a phone firewall.)

Only a few geeks will look at all details, but they will post reviews where the rest of us can read the summary.

Toxic hellstew

[swamp boy]

It might even turn the platform into a toxic hell stew.

Broken permissions

[ADRA]

Something like 90% of all apps require access to the IMEI of the phone which requires read_phone_state and that pretty much abandons all pretense of security compartmentalization since it can also see who you're calling, when you're talking, etc.. Most applications should only care and use it for a unique ID token. IF they want to fix permissions models:

1. Separate the 'phone unique number' from the phone's call state functions. Must have, end of line. This is just plain retarded form day 1
2. Write in permissions which are optional vs. required. Optional permissions are requested on demand like IOS and can be rejected or permantently accepted. Required permissions must be explicitly allowed when the application is installed
3. Re-introduce AppOps functionality or at the minimum an audit trail of when-last and how often the application attempts a specific permission operation/category
4. Consider second tier permissions model where if you want to include common and generally well understood permissions like read_gps there's no hoops to jump through, but if one wants to read and access the variety of accounts I have on my phone, I want to make damn sure that the company asking for this information has at least passed the stink test.
5. Lastly, I want third parties to be able to flag applications (based on APK signature or through store functionality) as a problem so that even if Google doesn't have the time or resources to police all applications in the sun, I should be allowed to trust a thrird party who can flag programs problems based on any reason they find.
This allows for uses like:
      - Flag applications for parental categories
      - Flag apps as 'ad-enabled'
      - Flag apps that are outright malicious in terms of stealing data/information
      - Flag apps that violate certain country laws
      - Flag apps that are banned based on administrative oversight (for work phones)
Having this barrier mandatory or optional is up for debate as well as the ability to unistall is using a 'master' control password, etc..

Re:Broken permissions

[lexman098]

Google doesn't actually recommend using the IMEI.

Re:Broken permissions

[gnoshi]

"I don't recommend taking any money" said the man as he walked away from the pile of cash he had left on the street.

Right way to go

[Tanuki64]

For Google. Android is for the masses. The masses are stupid. Therefore the software for the masses must be written for the stupid. The less functions the better. You don't like it? How often in IT related discussions come lines like this: "MeeMeeMeeMee... I just want to use and not study computer science. You are arrogant. Stupid nerds". In the right forum, 80% applaud this crap. So, this is the result. I am certainly not Google, but I write my software the same way.

Re:Right way to go

[Anonymous Coward]

Wrong.

Android is for the masses - so it must be easy. That does not preclude an "advanced settings" page. Entirely optional to use, but that is where the "nerd" will find the fine-grained permissions system. The "sheep" won't need to go there.

So, the nerds will block spyware and possibly ads. The sheep won't, so megacorps gets most of what they want. Win-win for everybody...

Re:Right way to go

[Tanuki64]

Does not work this way. 'Sheep' don't allow advanced settings. Embarrasses them. Make them feel stupid. But of course it is not them who are stupid, but the software developer. Calling something 'advanced settings' is like putting a sign on: 'Randomly click here. No knowledge or understanding necessary'.

Sorry, not enough nerds there to make a difference. I write my android software myself. If I can. Usually not perfect, usually not so fine eye candy, but sufficient for my needs. And I know that it is 'clean'.

Re:Right way to go

[WaffleMonster]

Wrong.

Android is for the masses - so it must be easy. That does not preclude an "advanced settings" page. Entirely optional to use, but that is where the "nerd" will find the fine-grained permissions system. The "sheep" won't need to go there.

So, the nerds will block spyware and possibly ads. The sheep won't, so megacorps gets most of what they want. Win-win for everybody...

I'm constantly encouraged by volume of comments left about apps in app store regarding permissions or demanding to know why x is needed or why y is now needed with a new version of the same app. I think if given tools to properly control access we could be surprised by how much they actually get used by "normal" peeps.

Re:Right way to go

[Tanuki64]

Really? An app is perhaps downloaded 5000 times. It has 100 comments... 20 complain about the permissions. You cannot know how many people did not install it because of the permissions. So, I think we don't have enough data to do a meaningful statistic and be surprised.

Re:Right way to go

[WaffleMonster]

Really? An app is perhaps downloaded 5000 times. It has 100 comments... 20 complain about the permissions. You cannot know how many people did not install it because of the permissions

How many people elected not to install because of permissions is a different question from those who would use tools to limit access if they had the opportunity.

Google - you are doing it wrong

[Anonymous Coward]

Well, finally time for Cyanogenmod for my fricking mobile.

Can't Identify "New" Permissions

[Anonymous Coward]

I had several apps that I refused to upgrade due to several "new" permissions they were asking for in versions newer than I had installed. Now when I look at their permission lists, I can't identify what permissions are "new", or even whether the app is asking for more than the current version has.

This is completely unacceptable, and until this changes, I won't be updating ANY apps. I need to at least be able to identify new permissions, if not specifically allow or disallow specific permissions for each app.

Re:Can't Identify "New" Permissions

[ravnous]

Isn't there a little "new" icon next to the new permissions when you go to upgrade?

Re:Can't Identify "New" Permissions

[Anonymous Coward]

There used to be, before the update to the Google Play store that included these "simplified" permissions. Now there doesn't appear to be any indication of "new" permissions, at least between the version I have installed and the version on the store.

Perhaps they add the "new" tag the first time a version includes them, but as it is now, there is no indication for these apps that I KNOW have different permissions than what is installed.

Re:Can't Identify "New" Permissions

[ewhac]

Inside Google Play, scroll to the bottom of the app's page. Under the heading, "Permissions," you will find a link named, "View details." Tap on that, and a more familiar list of permissions will appear, including flags on new permissions.

Re:Can't Identify "New" Permissions

[Anonymous Coward]

Thanks!

I knew that there was permissions listed at the bottom, I didn't expect it to be any different than when you press Update and get the "Simplified" version. I really appreciate the heads up that it is different and does in fact show the New tag in that set of permissions.

Well, no.

[Anonymous Coward]

Google wants companies to actually write apps for the Google Play store. If they give end-users too much power over the permissions, they drive companies out of the Google Play store and over to the Apple store.

On the other hand, Google also wants end-users to actually buy these products. By grouping permissions up, they seem innocuous, so users feel less threatened (even though they should feel more threatened) and will buy the stuff.

From a business perspective, this move makes perfect sense. From an educated geek end-user's perspective, it really sucks. But what are you going to do? The world you want to live in does not exist.

Re:Well, no.

[epine]

From a business perspective, this move makes perfect sense. From an educated geek end-user's perspective, it really sucks. But what are you going to do?

First of all, I'm not going to purchase any of those fancy apps. I'm going to use my smart phone as for phone calls, photographs, maps, and web browsing. While it's truly a waste of a beautiful technology, it's merely inconvenient not to bother with all those invasive programs.

I consider the new security model worse than not having the apps at all.

Re:Well, no.

[JeffOwl]

The world I live in includes fine grained permission controls and even spoofing information so that apps don't crash. Yes, it requires extra work to set up, but I don't mind and even enjoy the tinkering. Yes, that isn't everyone, but I need most of you to stick with the stock business model to keep the ecosystem healthy anyway.

Re:Well, no.

[Anonymous Coward]

Looks like we have no other choice than to buy a second phone to run invasive programs. Hmm, maybe that's what they're hoping will happen?

Re:Well, no.

[Rich0]

But what are you going to do? The world you want to live in does not exist.

Simple, install XPrivacy. Problem solved. App wants a IMEI? No problem - just give it a random one, or a different one on each boot.

Re:Well, no.

[buswolley]

Anyone use SnoopWall? It allows fine-grained permission setting after installation of an app
http://www.citeworld.com/artic...

Re:Well, no.

[amjohns]

So you're saying developers will flee Google Play for Apple - if Google implements the EXACT SAME privacy/permissions controls iOS already has??

Lack of control over app permissions, just having to blindly accept whatever an app requests all-or-none, is precisely why I avoid Android. Now they've just made it even worse!

Re:Well, no.

[Immerman]

Correction - the bulk of app developers will; follow the *profitable* users. What do they care if 10,000 people use their app and they make no money? And right now the money seems to comes from (in order of increasing total money flow)
* purchasing the app (if you're lucky. Most developers aren't. Free apps are where it's at unless it's something really good and/or you get lucky)
* in-app purchases (only relevant to a small cross-section of apps)
* spying on you and selling the information (not quite sure where this one ranks)
* selling advertising space in a free app

Re:Well, no.

[exomondo]

You know you aren't restricted to the Google Play store, in fact given that Android is open source you could modify it to support your own permissions system: for example you could wrap all the API calls and have your own permissions layer. Granted it would be pretty time consuming to build but given the size of the community it could fairly easily be done.

Re:Well, no.

[farble1670]

and this requires root, which is throwing out the baby with the bathwater. as soon as you root, the entire sandbox runtime model is out the window.

Re:Well, no.

[Anonymous Coward]

Really cause when an app wants root permission on my rooted Droid, it pops up a box where I can tell it to fuck off. SuperSU is the app keeping the gate secure. Nothing gets root access without asking me and I can perma-block it if it gets pissy with me.

Re:Well, no.

[WaffleMonster]

and this requires root, which is throwing out the baby with the bathwater. as soon as you root, the entire sandbox runtime model is out the window.

As soon as you root you have explicit control over what if anything gets to run as root.

Re:Well, no.

[Rich0]

and this requires root, which is throwing out the baby with the bathwater. as soon as you root, the entire sandbox runtime model is out the window.

Uh, you do realize that root exists on the phone whether it is rooted or not, right? The only thing rooting the phone does is allow you to have some say in how the security works. If the only thing you do is install XPrivacy after rooting the phone, how exactly is that making things LESS secure?

Re: Well, no.

[Anonymous Coward]

Hello? On iOS you can already change permission settings whenever you want. "Unlike iOS"? Are you a jealot?

Re:Well, no.

[Anonymous Coward]

Don't be a fool. What you just said is similar to saying "Well, we can't give Google root because it violates the sandboxing model" - except Google effectively has root because they wrote the damn operating system.

Root is there for responsible use, and fixing a permission problem is a responsible use. After this latest turn of events, it may be more responsible to install a better permission system than the one Google wants to use.

Another way of putting it: "If Google dummies down permissions, what sandbox runtime model even still remains to throw out the window?"

Re:Well, no.

[Miamicanes]

[quote]But what are you going to do?[/quote]

Civil disobedience. Root your phone, reflash it to an AOSP- or AOKP-derived ROM, and configure it with an app that feeds invasive apps spoofed or sanitized data.

Re:Well, no.

[c6gunner]

and this requires root, which is throwing out the baby with the bathwater. as soon as you root, the entire sandbox runtime model is out the window.

This particular baby is stillborn, so why do you want to hang on to it's corpse? It's much more rational (and much more fun) to make a new one.

Re:Well, no.

[L4t3r4lu5]

I use CyanogenMod; App permission management baked into the ROM. It's in others, but I like CM.

Flashing your own ROM onto an Android device is the new "nuke ane pave". It used to be wiping Windows pre-installed images, but nowadays PCs are replaced far less often than phones.

Re:Well, no.

[Anonymous Coward]

True, but only for the software that you trust with root permissions.

Re:Well, no.

[ilsaloving]

While not as super-fine grained as google's permission system, they do allow you to choose what permissions you want to grant to individual application. You can even change your mind later.

There does not appear to be a shortage of apps on the Apple app store.

The idea that Google needs devs to fill up their app store is bogus. They're the dominant phone OS, by far. Developers need them, not the other way around. All this does is re-enforce the idea that we are not Google's customers. The advertisers and data miners are.

Re:Well, no.

[Anonymous Coward]

Apple lets me disallow a permission to apps individually at the time the app is making an API call. So it's not Apple's store where these scared developers would run to.

Re:Well, no.

[dotancohen]

I'm considering rooting my Note 3. Could you expand upon this, or at least link to places that do?

Thanks!

Re:Well, no.

[AmiMoJo]

as soon as you root, the entire sandbox runtime model is out the window.

That's not how root works on Android. For an app to get root permissions there are only two ways. The method used by the 'su' app that grants permissions to other apps is to be installed via the boot time recovery console, similar to single user mode in Linux. It requires extensive user intervention. Other apps can then ask the 'su' app for various root level permissions, and the user has to grant them individually. Most 'su' apps offer features like a 15 minute time limit on permissions.

So it doesn't break the sandbox model at all. An app still can't break out of its sandbox, it can only request that the 'su' app grant it extra permissions if the user agrees.

Re: Well, no.

[Anonymous Coward]

Or you could just use Cyanogen Mod, which is exactly what you describe.

Re:Well, no.

[GTRacer]

What do you use to manage this?

Re:Well, no.

[farble1670]

that's great, as long as you trust that SuperSU has zero bugs.

it's the difference between having a brick wall, and having a brick wall with a locked door. if you absolutely don't want people to get in, don't build a door in the first place.

Re:Well, no.

[farble1670]

the thing that gatekeeps root is just software like anything else. it can have bugs. putting the security of your entire device into the hands of software that some guy wrote on nights and weekends doesn't seem like a great idea.

with a sandbox, malicious apps can phish and phone home, but they can't read other app's data. once you have root, you can do anything. inspect memory. sniff the network. whatever. the stakes are much higher.

yes, and of course android's OS can have bugs as well, but it's a large company with massive resources and a lot to lose if they fail. their financial success relies upon them not f'ing up security. that's a strong motivator.

Re:Well, no.

[farble1670]

it's not installing XPrivacy that's the problem, it's rooting it in the first place.

Uh, you do realize that root exists on the phone whether it is rooted or not, right?

please take a non-rooted phone and try to obtain root permissions. you can't. so no, apps absolutely cannot obtain root permissions on a non-rooted device.

Re:Well, no.

[farble1670]

if you don't trust google enough to at least try and protect your data, what the heck are you doing running an android device in the first place? do you really think your little "su" app is going to keep your device from sending your data back to google? now that's foolish.

it comes down to motivations. google makes money when users trust them. leaking your personal data is counter productive to that end. on the other hand, the guy you wrote your "su" app has very little motivation (or resources for that matter) to protect your personal security. your "su" app is just software and it's as fallible as any other software.

the way google decided to execute permissions is flawed, but rooting your device just makes it worse.

Re:Well, no.

[farble1670]

no. it's the difference between a brick wall and a brick wall with a locked door in it. if you really don't want anyone to get in, you don't put a door in the first place, because a door has a locked that can be picked.

your "su" app is just software and is subject to bugs like any other. i love it how people don't trust google, but they trust the guy who wrote an "su" app in his mom's basement.

Re:Well, no.

[farble1670]

the issue is that you are opening a hole where there was none. it's the same reason that IT depts lock down all sorts of ports on a firewall. sure, leaving port 21 open isn't a problem, as long as you trust ssh. the problem however is that ssh is software that is subject to having bugs and being hacked. the answer is that you don't even open port 21 in the first place.

Re:Well, no.

[JesseMcDonald]

You should only need root to install the Xposed framework for XPrivacy as a system app, not to use it. So if this is really a concern for you, just uninstall your root app after installing XPrivacy, and then you won't have to worry about it granting root access to some random app without your consent.

Re:Well, no.

[JeffOwl]

1st, you need to root the phone. 2nd, the easy way is to install a 3rd party permissions manager, there are a number of them in the Play Store. Once you root there are other things you can do like edit your hosts file so you can block some communication without blocking an app from the internet entirely.

Re: Well, no.

[exomondo]

Or you could just use Cyanogen Mod, which is exactly what you describe.

Oh ok cool, sorry I'm not overly familiar with the features of Cyanogen Mod, I didn't realize it already did that but it's cool that the solution is already out there.

Re:Well, no.

[Rich0]

Uh, you do realize that root exists on the phone whether it is rooted or not, right?

please take a non-rooted phone and try to obtain root permissions. you can't. so no, apps absolutely cannot obtain root permissions on a non-rooted device.

Sure they can - there just has to be a local priv exploit. That's also the only way an app can get root permissions on a rooted device, unless you grant it to the app.

There isn't anything inherently insecure about a rooted device. Now, if you just grant access to su to any application that asks for it, then that is insecure.

However, the whole point of this article is that the Android OS will happily give away your IMEI, serial number, phone number, contact info, all the files on your sdcard, and whatever else an app asks for. So, unless you don't want to use the Facebook app, you're far better off rooting it to install XPrivacy than to leave it alone.

Re:Well, no.

[Rich0]

that's great, as long as you trust that SuperSU has zero bugs.

it's the difference between having a brick wall, and having a brick wall with a locked door. if you absolutely don't want people to get in, don't build a door in the first place.

How is trusting that SuperSU doesn't have bugs any different from trusting that the Linux kernel has zero bugs? I'm not aware of any privilege escalation bugs for SuperSU. I'm certainly aware that there have been many of them over the years for the Linux kernel.

Sure, having SuperSU installed is another place an attack can be made, but it is just one of MANY that already exist. The doors are already all over the place. Just about every android device out there can be rooted, despite the fact that very few of them are designed to be - those are all privilege escalation bugs of one sort or another, and none of those phones start out with SuperSU on them.

Re:Well, no.

[Rich0]

no. it's the difference between a brick wall and a brick wall with a locked door in it. if you really don't want anyone to get in, you don't put a door in the first place, because a door has a locked that can be picked.

Well, more like a brick wall with 30,000 locked doors, and a brick wall with 30,012 locked doors. A modern OS has TONS of places that need to be secure to prevent a privilege escalation.

your "su" app is just software and is subject to bugs like any other. i love it how people don't trust google, but they trust the guy who wrote an "su" app in his mom's basement.

Uh, you do realize that the thing that keeps the su app from being exploited is the very same sandboxing written by Google that keeps apps from exploiting each other in general, right?

Re:Well, no.

[Blaskowicz]

I remember the days of replacing pre-installed Windows with warez Windows (even of the same version). ROFL!

Re:Well, no.

[farble1670]

Uh, you do realize that the thing that keeps the su app from being exploited is the very same sandboxing written by Google that keeps apps from exploiting each other in general, right?

UH, sandbox is only one of many possible attack vectors to compromise an app. what if it simply had a back door? have you inspected the source?

Re:Well, no.

[farble1670]

How is trusting that SuperSU doesn't have bugs any different from trusting that the Linux kernel has zero bugs?

it's a matter of attack vectors. using SuperSU adds one more.

also, i'm willing to bet that the linux kernel gets a little more scrutiny and testing than your SU app. then again, it's much more code.

I'm not aware of any privilege escalation bugs for SuperSU.

well, i guess they cannot exist then. i stand corrected.

Re:Well, no.

[Anonymous Coward]

Actually i think that making the permission-list shorter could in many cases improve security... This since most users don't actually read the permission-list but just accepts it, and i can understand that.. Lots of people have no clue what most permissions are about..

http://stackoverflow.com/quest...

What i would like is a better way of displaying the permissions that would, in a easier way, tell non-tech people what they all do instead of just having a really low list of permissions in text-format.

Maybe a compact list of the main features with a few symbols indicating Read/Modify/Use or something like that and then allow us to expand the list for a more fine-grained view.

Re:Well, no.

[Anonymous Coward]

You foed me for a non-flame response to someone ELSE'S post?

What a fuckwit.

Re:Well, no.

[Rich0]

How is trusting that SuperSU doesn't have bugs any different from trusting that the Linux kernel has zero bugs?

it's a matter of attack vectors. using SuperSU adds one more.

also, i'm willing to bet that the linux kernel gets a little more scrutiny and testing than your SU app. then again, it's much more code.

Sure, but we're talking about a very simple implementation. I guess having it is more risky than not having it, but on the other hand the alternative seems to be basically giving every app on your phone access to all your personal info, in which case I'm not sure what you're avoiding by not just giving them all root as well.

The actual su application is sandboxed by the OS like every other app. Again, if that doesn't work then you're already up the creek.

I do understand your point, but I honestly my concern with having SuperSU on my phone is just a bit lower than my concern with the fact that I've yet to see a browser that gives you a warning anytime you make an unauthenticated connection.

Re:Well, no.

[Rich0]

Uh, you do realize that the thing that keeps the su app from being exploited is the very same sandboxing written by Google that keeps apps from exploiting each other in general, right?

UH, sandbox is only one of many possible attack vectors to compromise an app. what if it simply had a back door? have you inspected the source?

Thanks for pointing that out - I actually didn't realize SuperSU wasn't open source. Fortunately there are open source alternatives, like superuser.

And no, I don't plan to look at the source before I install it. Ditto for the linux kernel running on the phone, and the openssl library on my webserver. :)

Clarification

[ravnous]

Someone tell me if I'm wrong here, but I just read the Google support page discussing the changes, and here's what I came away with.

Permission groups are new. If you grant permission for an app to have access to the features controlled by that permission group, then the app has access to all of them. Using the SMS example, if a developer requested the SMS group permission, the developer is asking you to allow the app to do all the things listed under that group. That would include reading SMS and sending SMS messages, among other things. If an app requested the SMS group, and you installed the app, even if the app previously only read SMS messages, it still had permission to send them. A future update may also send SMS messages, but you've already approved that action by installing and manually approving the previous version of the app. Where it gets dicey is if a new permission were added to a group. For example, if a delete SMS feature were added to the group, I don't think the Google page discusses whether that new permission would need to be approved.

An app developer can still ask for individual permissions, like reading SMS messages. If a future update wanted the ability to send SMS messages, they would still have to ask and the app would not be auto-updated. Or, if the app developer later decided he/she wants to add the SMS group permission request, that download would require manual approval.

I don't think there's anything nefarious going on here. You just need to be aware of what permissions you're granting an app. If you grant an app permission to send SMS messages (whether it's via an explicit request for that ability, or whether that ability is granted via a permissions group), don't get upset when it does send an SMS, even if that feature isn't baked in until a later update. As far as I can tell, no app is being granted permission to do something you haven't already given it permission to do. Except for internet access.

The internet access permission being demoted to a secondary permission, on the other hand, might be cause for worry.

Re:Clarification

[Nethemas the Great]

Nefarious or otherwise, the security permissions were too course grained to begin with. This just makes the problem worse. They might as well flip everything over to 777 and be done with it for as secure as they've now made things. This isn't going to boost user adoption of apps (at least among people with a brain), it's going to make everyone more paranoid and gun shy about pulling the trigger on the "install" button. Call me old fashioned by I'm not terribly thrilled with the idea of conducting my day to day life publicly exposed, naked and vulnerable. While I'm willing to accept dropping my pants for my doctor in the context of a medical exam, I am certainly not inclined to do so for the convenience store clerk on the corner just because I want a bag of Cheetos.

Re:Clarification

[Anonymous Coward]

You forgot that if you grant the SMS group the app can auto-update (say, when it's sold or the dev's computer is compromised) with malware and immediately start sending messages. Before if you only granted it the ability to read, you were freed from that attack vector.

The permissions grouping demonstrably decreases security (see above) and encourages app devs to just broadly grab the right permissions rather than select the ones they actually need.

Re:Clarification

[ravnous]

But if the app had the SMS group permission when you installed it, it had the ability to do that already. You haven't granted it any additional permission. If the developer only really wanted the ability to read SMS messages, it should have only asked for that in the first place.

I can definitely buy that app developers may get lazy and ask for more permissions than they need because it's more convenient. Let's say a group had 5 permissions, and an app needed 3 of those. The app developer may get lazy and just ask for the whole group instead of the 3 permissions the app really needed.

If a developer gets lazy and asks for more permission than the app needs, that developer should get raked over the coals in the app reviews, and maybe they'll fix their app.

The human component of asking for permissions (both on the developer's end and on the user's end) may be weakened, but the security model itself is no different with permission groups. As far as I can tell, they're not removing the ability to ask for individual permissions, they're just making it easier to ask for collections of permissions.

Re:Clarification

[Tanuki64]

This isn't going to boost user adoption of apps (at least among people with a brain),

You can get much money from smart people, if you offer a great product.

You can get little money from totally brainless people, even if your product is total crap.

Too bad that there are so many brainless people compared to the few smart ones, that the latter approach is by far more profitable.

If you want to be successful... target the imbeciles.

Re:Clarification

[gnoshi]

My understanding is that there is no separate 'group' permissions. If an app is granted a permission which falls within a group (e.g. read SMS) then an auto-update can add any other permission within that group without user notification (e.g. change all your text messages to read 'if you ever want to see your text messages again, sent 0.2BTC to xyz).

Re:Clarification

[bentcd]

The main problem with your cynicism in this case is that if the product were to be mainly marketed to imbeciles then why does it have any pretense at privacy protection at all? Such people don't care one whit and so in the previous system they would just always click "accept" and "install" and there wouldn't be a problem (for Google).

The problem instead seems to be that there is in fact a sizable portion of users out there who do care at least a little about their privacy and who do get nervous about it every time an app asks for more permissions on an update. This is why they are (apparently) now changing the permissions system, to give an appearance of privacy protection while not really offering it: they want to sell to people who actually care about their privacy and who are prepared to take reasonable steps to safeguard it, such as click "Hell No" in an installer/updater.

Re:Clarification

[Tanuki64]

The main problem with your cynicism in this case is that if the product were to be mainly marketed to imbeciles then why does it have any pretense at privacy protection at all?

For people like you. Having no protection at all gives bad press. Having at least some protection or pretense of protection? "Uh... those nerds again. Should come out of their mother's basement... I just want to use a device, not learn computer science...yada yada". It is easy to distinguish between no protection at all and protection. But the average joe sixpack cannot distinguish between good and bad protection.

But the most important reason: Blame shifting. If something happens, and it will happen, Google can always say: The user opted in. He chose to allow this app to use SMS. If there is no protection at all, Google might get sued.

The problem instead seems to be that there is in fact a sizable portion of users out there who do care at least a little about their privacy...

You are aware, that Android is NOT the main focus of Google's business interests? It is big data. So, if someone has quantifiable information about 'the sizable portion', I'd guess it is Google. As much as it might hurt, geeks or nerds don't matter. Perhaps in the beginning as early adopters and multiplicators, but later on? When there is a userbase which goes into millions? Forget it.

Would be happier if

[TheCarp]

I would be a lot happier....even with this change.... if they made one other change: allow me to override.

Very simple "App X requires A, B, C" Why does that mean I HAVE to grant A,B,C too it? Why can't I say "Give it A,B and run it anyway, yes I, the owner of the device, approve this" I don't see why its all or nothing like some sort of stupid contract

"Well to run our app you must give us access to your SMS messages"
"I don't plan to use those features"
"Then you can't run our app on your hardware"

I mean don't get me wrong, I understand nobody can stop an app developer from making his app break if it doesn't get every permission it wants....but, as the owner of the device....isn't it well.... my problem if I break an app?

Rollup Already?

[Luthair]

I thought the Google Play store always showed the top level permission in the list as opposed to the more fine grained ones? Is the only difference that applications will now be able to use anything in the category displayed?

In either case Google does need to ressurect AppInfo, the argument that applications can't handle not being provided a given permission is bogus - I don't believe there are any permissions which do not have an empty value which the application should already be capable of happily consuming.

Most people don't care

[hsmith]

So what does it matter? How many people read the finely grained permission pages when installing apps as is? Perhaps this approach will be better because it will condense it into something people will be less likely to "ok" without reading.

Doubtful.

Re:Most people don't care

[timrod]

It matters because many apps ask for blanket permissions they really don't need. Take Poweramp, a music player app, as an example.

When you install Poweramp, it asks for blanket permission to "read and modify files on this device". To me, that doesn't mean anything. Where's it going to be reading from? What's it going to be modifying? What folders is it allowed to modify? I understand why it needs that kind of access (read to read the music/video files, and write because it has to write config files and album art/metadata if you choose to let it download that), but what if I don't want it accessing anything other than the base Android system files it needs to operate, its own app folder, and my music folder?

Sure, it's got thousands of downloads, but since it's closed source, how do I know it's not secretly stealing all of my files and sending them somewhere, or selling my location data (Poweramp doesn't ask for location data AFAIK but it very well could).

This stuff is important and I wish I had better control over it.

Re:Most people don't care

[hsmith]

No, I get it why it is good to have detailed information. But, I bet you can ask 99 other people at random and you are the only one that cares. It is simply where the market is - people don't give a shit. Which, I agree - is bad.

Well, no.

[kaladorn]

And they'll stop geeks, some of the potentially most heavy users of their technology, from leveraging them, recommending them, or wanting to develop for them.

I don't see that the current permission system was preventing anyone developing anything. Have you noticed how many apps are on Google Play? This seems like trying to pursue business that is already being done....

Coming soon... even *simpler* permissions

[QilessQi]

You're about to install "Angry Birds 7.0". This app wants to...

    1. Do whatever the hell it wants to with your tablet setup, your phone connections, and the Internet
    2. Not tell you about it

[ ] Yes: I'm bending over right now!
[ ] No: uninstall Android, brick my tablet, and post all my downloaded porn to Facebook

Well, no.

[Anonymous Coward]

hey drive companies out of the Google Play store and over to the Apple store.

That's not 100% true. App developers will follow the users and users will follow the app developers. It's a herd mentality on both sides and as such is much harder to predict than "companies will just go to apple."

While Apple doubles down on privacy...

[rsborg]

Looks like Google is doubling down on making it harder for you to stay private. Classy move, Google. You make it easier for me to avoid recommending the Play store and Android altogether.

Please remind me

[Anonymous Coward]

Why do people like and use Android again? And who are these people?

Re:Please remind me

[tepples]

Because Android is cheaper for their use case than iOS.

Re: Please remind me

[Anonymous Coward]

You get what you pay for. Always remember that. And cheap stuff is often too expensive. Contradiction? Nope. Cheap stuff isn't worth it and you buy twice. Buy good, quality stuff, even if it's expensive, once and enjoy it more and longer. Applies to everything. No exception. Including toilet paper.

Exactly the opposite of where it should go..

[epyT-R]

Applications shouldn't be 'asking' for permission. They should just attempt access. The security configuration for each service or resource should have three settings: reject (with api notification), deny (return success but with bogus/user entered data), or allow (work as intended), for each application. The default should be reject, with a first time startup prompt (from the OS, not the app) when the app starts. This way a user retains his dominion over the device and what it does with network IO. For example, he can use an app that demands access to location information when it doesn't really need to. The user should own the android device and applications, not the other way around.

Of course this would break the market and surveillance imperatives of google, app developers, and the state. Fuck them.

Re:Exactly the opposite of where it should go..

[laddiebuck]

That would be terrible from a usability perspective. UAC prompts all over the place for every single thing an app might do. This way at least it's all managed up front in one place at app install time (or by third-party tools separately).

Re:Exactly the opposite of where it should go..

[epyT-R]

It would ask about them all up front on first run. If the user changes his mind, he can go back into the would-be 'app security control panel' and change as needed.

Revoke?

[Anonymous Coward]

Android apps do not "request" permissions, they "demand" permissions.

Your choise is: "Yes, and install", or "No, and don't install".

I should be able to deny certain permissions and install the app anyway.

There is no reason for a flashlight app to demand access to my phonebook, or to read/send SMS - wtf.

Helper apps

[tepples]

Often times, a well meaning dev will explain that he has to have X permission because google has buried one particular function (not always obviously related) into that permission and that function makes sense for the app. You almost get the feeling the dev is apologetic in many cases and would like to just have a single finer grained permission.

Where I come from, such an explanation has a name: a "privacy policy".

And one more thing: How about installation require the minimum number of permissions to make the basic app functions work and additional permissions queried and granted/denied if optional features are enabled?

If you're talking about a checkbox to turn permissions on and off, the party line is that that would cause apps to crash. Too many existing apps are not designed to catch the SecurityException that the system would throw if the user were to disable a permission.

Otherwise, in Android's current security model, the developer could separate each optional feature into a separate helper app that gets its own set of permissions, and the helper app would perform an action on the main app's behalf. (In Android, different apps from the same publisher can communicate with few restrictions.) For example, a keyboard app like Swype could offer a separate app for each dictionary: one for each language (such as "Swype en español"), one for the names of your contacts ("Swype Knows Your Name"), and one for the names of nearby landmarks ("Swype Local") that needs GPS and Internet. When the user turns on an optional feature that needs a helper app, the app directs to the helper app's Google Play Store page.

Re:Helper apps

[Anonymous Coward]

The app crashing would be easy to avoid, for example instead of throwing an exception when the IMEI is read one could simply provide a random but valid IMEI.

A little surprised.

[m.dillon]

Google must know by now how bad a light its broken permission system is putting on Android. I can't run half the android apps I want to run on any of my Android devices any more because of the permissions they want. And a lot of the ones that I intentionally do not upgrade no longer work. It's making my three android devices useless and almost worthless.

I'm flabbergasted that there are full-on idiots in the Google command chain who are unwilling to address such a severe and obvious problem. Truly flabbergasted. Has Google gone insane?

I've already stated but I will again... when the iPhone-6 comes out, I'll be moving over to it from my perfectly working but horribly insecure Motorola Razr. At least then I can browse my facebook account from my phone without it sucking up all the stuff I've tried so hard to keep partitioned off of it. As it stands now, I can't even run customized UIs on my Android because the g*d* program insists on advertising on my notifications screen, even though I bought the paid-for version.

At least with iOS I don't have to worry about all this in-the-face crap ruining the experience.

-Matt

Re:A little surprised.

[Anonymous Coward]

As it stands now, I can't even run customized UIs on my Android because the g*d* program insists on advertising on my notifications screen, even though I bought the paid-for version.

What specifically are you referring to here? It sounds like a shitty app if it doesn't give you an option to disable notifications on the paid version.

In any case you can disable notifications for pretty much any app if you go into the app info screen, you can get to the app info screen through the settings menu, but you can also long press the offending notification and select "app info" to get to it for that app, there you can uncheck the "show notifications" checkbox. I think this feature was introduced with Jelly Bean.

Apple's having a good month

[maccodemonkey]

First, and impressive showing at WWDC, and now Google is nerfing their security model to be weaker than iOS's (iOS will notify when a new permission is required as part of an update when the application tries to make use of that permission.)

I think Windows Phone and iOS are both in a good position to start taking some market share from Google. If Google doesn't have a good Google/IO with Android, they may have officially dropped the ball on Android.

Well, no.

[Anonymous Coward]

The educated geek accepts this, shrugs and mutters, "such is life," and then goes and installs the Xposed framework and Xprivacy, which restores fine grained permissions (to a granularity that Google never provided) and opens up all kinds of other interesting possibilities. Ultimately, Android is still open enough that this is possible, unlike iOS.

11 months to go on warranty

[ppanon]

and as soon as it's over, on goes Cyanogenmod.

Xprivacy fixes that (Xposed Framework)

[krelvin]

I use Xpivacy which is a module add on to Xposed Framework to control permissions now. Have been using it for sometime. Allows using something like the Facebook app without allowing it all of the permissions it thinks it neededs.

Not really sure what Google is thinking though. There needs to be more fine control of permissions not less.

Less-knowledgeable users misplace the blame

[tepples]

as the owner of the device....isn't it well.... my problem if I break an app?

The problem is that too many end users are not knowledgeable enough in how computers work to know whose problem it really is. They think it's Google's or the phone manufacturer's because the app broke.

Straw on the camel's back

[losttoy]

Being a Linux geek since '95 (and somewhat of annoyed-by-all-things-apple person), I bought an Android phone ever since they became available commercially. Did that for five years, ran custom roms and put in an Android patch to maintain a permissions firewall. It was one big PITA from a usability point of view. One day, I saw my banking app looking at my call log and that broke the camel's back, for me. I realized Google simply isn't interested in protecting my privacy. The whole you-can-see-what-perms-app-is-asking-for-before-install is a smokescreen. It doesn't scale. Pushing security problems to the user won't work for 99% of the userbase. Hell, it didn't even work reliably for a Linux nerd like me. By contrast, Apple only exposes a handful of data/attributes to ANY app. An iOS app can't look at or even ask look at my SMS, call log and practically most of the stuff - now, that is a sandbox. Also, from a business point of view, Apple makes money by selling me a phone so yes, they have some incentive above that to milk me for analytics but they aren't Google, who don't make much money when I buy an Android phone. For Google, I am the product. So, I switched to iOS (phones and tablets) and actually since then have switched from Gmail to Fastmail, Picasa to SmugMug. With these switches, my privacy is better protected and even usability is better (Picasa, for me, died when Google started shoving G+ Photos down everyone's throats).

Re:Straw on the camel's back

[Tanuki64]

Google simply isn't interested in protecting my privacy.

Or they are simply not able to do it. Google is seen by many as the software olymp. When I started developing for Android I was appalled by what a crap system Android really is. Buggy as hell and needlessly difficult to use. Maybe the Android developers are simply overstrained by their own system and needed to simplify it.

Re:Straw on the camel's back

[laddiebuck]

The tradeoff is flexibility. Android apps can replace the SMS app, camera, launcher, etc. On a desktop system, the ultimate in flexibility, any "app" can look at all the files in your homedir. Privacy and flexibility are opposite design goals unfortunately. Maybe that'll change in the future but right now that's how it is.

I noticed this a few days ago...

[Anonymous Coward]

I noticed the change a few days ago. I always scan for "new permissions" during updates. The new UI makes this much more difficult. It's clear that the Google Play app uses WebView so Google can change the layout without an update. I had hoped Google would fix this in a day or two. No fix so far. I feel Google has jumped the shark.

I also noticed that the latest version of Google Maps will find me something in France with the same name as the thing I am looking for in my country (Israel). Was I really planning to drive to France today or drive 20 minutes? C'mon Google. Maps used to return saner results.

google is terrible

[Anonymous Coward]

Google never cared about permissions to begin with. If they did they'd have a way to revoke permissions to apps. Want to download Facebook App but don't want it having control over your entire phone... can't do that with stock google... so fuck google

Comment removed

[account_deleted]

Comment removed based on user account deletion

Buy an additional computer and certificate

[tepples]

I don't imagine that it's worth it to a lot of people to buy a Mac and several years of iOS Developer Program membership just to make an iPhone do what an Android phone does.

Re: Buy an additional computer and certificate

[Anonymous Coward]

Bogus claim. FUD. Nothing else. What exactly is missing so crucial from iOS? And please don't say 'changing icons' or 'switching to comic sans'. I would laugh myself to death.

A very bad move

[melting_clock]

Google doesn't care about the security and privacy of Android users. Their own products mine their users data, as many people have pointed out. Apple is not interested in protecting users either. Luckily, Android users can protect themselves by rooting and installing real security software that limits what applications are able to do. XPrivacy is one of the best ways of protecting your privacy and device security. Add a firewall and the job is largely done. Sadly, you simply can't be protected without rooting and Google is always trying to prevent root level access...

Once there is a jump in malicious software due to this change to permissions, the resulting negative publicity might get Google to actually do something to protect users. The consequences will increase with the increasing amount of highly confidential information on Android devices and the increase in high value activities to be targeted. Internet banking and financial services tied directly to devices must be very attractive to criminals. Forget about stealing contact information, browsing history, location tracking, etc. Your right to privacy was lost long ago.

I really miss the days when Adware and Spyware were identified as malicious software by antivirus programs and we still had some rights.

Erroneous and Misleading Article Title ..

[lippydude]

Simplified permissions on Google Play

"To help make it easier to understand what an app will have access to, the Play Store has recently made improvements to how permissions are displayed. Permissions are organized into permissions groups, easily identified by icons (example: Location Location) to help clarify the most important information and capabilities an app can access on your device. This information can help you make an informed decision more easily on whether you would like to install the app." ..

Permissions groups

"Permissions groups are designed to show what an app will be able to access on your device. With permissions groups, you can quickly see what capabilities or information an app may use before downloading it. Also, you can review individual permissions at any time using the Google Play Store Play Store app."

"It's a good idea to review permissions groups before downloading an app. Once you've allowed an app to access a permissions group, the app may use any of the individual permissions that are part of that group. You won't need to manually approve individual permissions updates that belong to a permissions group you've already accepted."

FTFY

[Anonymous Coward]

This is why as mobile internet service gets better more things move to "the cloud", it's the logical solution for exploiting an open platform where (most) companies are too greedy to just sell me the app and too greedy to not pay for my bandwidth for spamming ads at me.

Re:FTFY

[exomondo]

But they do just sell you the app, or the alternative is ad-supported yet you cheapskates think they should pay for the bandwidth to serve ads. The only greedy one is you! Either pay for it or cop the ads, otherwise the move to the cloud where you lose even more control is the logical choice for developers.

So don't sign up with Google.

[Animats]

I have an purchased Android phone, a B15 from Caterpillar, not from a carrier. I bought a T-Mobile SIM card for it. When, at first startup, it asked me to sign up for GMail, I exited that dialog. I don't have a Google account. Turned off Google App Store, Google+, Google Market Feedback Agent, Google Play Music, Google Play Store, Google Play Magazines, Google One Time Init, Google Contacts Sync, Google Bookmarks Sync, Google Account Manager, GMail, Google Chrome, and Picasa Uploader. (Kept the phone preloaded apps: CAT Equipment Rental, CAT Parts, etc. Yes, this thing really is from Caterpillar Tractor. Waterproof, shockproof, dustproof, of course.) Works fine. Phone network data consumption is low, about 250MB/month.

There are a few glitches running in this mode. Google Maps will crash if you access Settings, which is a clear bug.. But that's about it. Google Now works, but doesn't know my location. Nothing ever gets updated, since the carrier knows nothing about the phone. Apps have to be side-loaded. I may load up the Amazon app store to see what that's like.

I was thinking of loading Cyanogenmod, but don't see the need now.

If you just have to play Angry Birds, run the Flash version.

after the fact permission mods

[fyngyrz]

Have you thought about how an app might act if a permission it expects to have been granted isn't actually available?

Doesn't seem like a viable solution to me.

But I also agree with the poster above who plans to use the smartphone for maps, web browsing, photos, texting and phone calls. It's a good plan.

Re:after the fact permission mods

[L4t3r4lu5]

There are security apps which block requests to your personal data and provide fake data when requested.

Then again, the app you're using isn't free; It's provided to you for no charge in exchange for access to your personal data, which may be used to profile you in order to show you relevant advertising. A lot of folk don't get that.

Re:after the fact permission mods

[Hognoxious]

the app you're using isn't free; It's provided to you for no charge in exchange for access to your personal data, which may be used to profile you in order to show you relevant advertising.

That's all well and good, but in order to make the decision about whether it's worth it I should be told precisely what data and precisely what it's going to do with it.

A lot of folk don't get that.

A lot of developers don't, it would seem.

I'll all end with lawyers, just you wait and see.

Re:after the fact permission mods

[L4t3r4lu5]

You're already told precisely how it will be used. It's in the sixteen page "Privacy Policy" you were told to read by the fourteen page "End User License Agreement" which you accepted, but didn't read.

:)

Re:after the fact permission mods

[GTRacer]

Xposed Framework + XPrivacy. It breaks out ALL permissions under the main groups and each is selectable per app. In most cases, denying permission will provide fake / empty data so that app functionality is maintained. It lists ALL permissions and marks the app's requested ones so you know what it wants to use.

Best yet, it has a sort of permissions tripwire - a usage log shows you when an app has tried to use a blocked permission. In very rare cases, I've seen apps call permissions they didn't explicitly request up front.

Pretty much every app on my phone (and I don't install many) is denied accounts, contacts, location, sensors, phone ident, and web access. If an app force-closes under this template, I check the usage log and decide if I want to allow the failed permissions until the app works. I can either groan and take it or uninstall and look for a better behaved alternative.

Re:after the fact permission mods

[david_thornley]

Bingo. I also hope you're planning to reread the sixteen-page Privacy Policy every week to see what's changed.

Re:after the fact permission mods

[buswolley]

I believe SnoopWall provides fake data to the app.

Phone security frameworks are fundamentally flawed

[rlh100]

What is the point of asking a security policy question when the only answer is yes? Why do apps want access to so many different services? The android/apple security permissions frameworks are fundamentally flawed. A polite term might be naive.

At DeveloperWeek 2014 I went to a talk by a Mozilla developer on the Android security policy framework. He put forward two ideas:
Fine grain access control.
Prompt for permission the first time an app accesses a service, not at install time.

His first observation was that the granularity of the permissions was far to coarse. Access the Internet. Use the phone. Access memory. Why are you forced to allow near complete access to the Internet when a service might only want to write to a specific site? Why read/write entire user memory when it only needs to store a state file or a small collection of cache files. Fine grained access controls are all standard features of the operating systems that underlie Android and Apple smart phones.

The argument might be made that it would confuse users to be asking for complex permissions. I would say, what's the diff? The user is going to say yes either way. The only other option is to not use the app.

Fine grained permissions enforced by the OS would limit damage that a rouge app could do by limiting what it could do without popping up an access request.

The speaker's second idea was that the permissions policy questions should be asked the first time you use a service in an app, not at install time. The first time an app might build a current list of requirements/sites/etc and ask in one question. If an app needs to access something new like a new tracking URL or call a new phone number, a new permission request pops up enforced by the OS. A user who is annoyed by the pop-ups can always click "Don not show this message again".

The benefits of these two changes is that you do not have blanket permissions granting for apps even for services the user may never use. This would prohibit a virus from starting to use a service that had not been previously accessed. Even a naive users might think twice when his GPS app suddenly wants to reformat the memory card.

The two prongs of making permissions more granular and not granting them until they are actually accessed by the user would fundamentally improve the smart phone security policy. Both of these should be implemented by the OS so they are automatic, uniform and enforced.

The argument of its too complex for the user is null because the users it might confuse are going to say yes in any case. They always do. The argument that it is too complex for the developers, my answer is "tough, you're a developer, deal with it".

I wish I could find a reference to the talk. It was the afternoon of the last day of DeveloperWeek 2014 in San Francisco. The guy was from Mozilla. I recall it being a last minute change because someone canceled.

Standard arguments about how nothing is perfect and everything can be bypassed apply. The standard reply of something is better than nothing apply as well.

Brought to you by Captain Obvious

Could be a good thing

[sigmabody]

This could turn out to be a good thing, imho.

Consider that there are basically two types of users, where privacy is concerned: people who are oblivious and/or don't care about their privacy, and people who try to preserve some of their privacy. For the former group, this change will not affect their app usage, and will make it easier for them to get app updates automatically, which will make their experience better. For the latter group, the Android developers are actively hostile toward your privacy desires, have no desire to help you, and in fact probably _want_ to drive you away from the platform. In both cases, it's a win for Android, the "all your data belongs to us and everyone else, and there isn't anything you can do about it" platform.

I personally think there's a market for platforms which allow some privacy (Apple does a much better, but still imperfect, job of this), but I acknowledge that there's also a market (and probably a larger one) for platforms which cater to people who share all their personal data with everyone, and are totally oblivious to what any/all of their apps are doing behind their backs. Google is making it crystal clear which type of platform Android, and their other services (see also: Nearby), will be.

Don't RTFM

[Anonymous Coward]

No one reads the permissions or even understands what they're actually agreeing to when the do bother to read them. People just want their apps without any hassle. Adding MORE granularity and MORE permissions would make it even less likely that anyone would read them. I'd rather not see any permission shit at all when I install something. When an app's trying to access sensitive stuff (like my location or access to my contacts), ask me in the context of trying to do something with the app that requires those permissions so I can understand why the permission matters.

More to the point, apps on the Play Store should just be trustworthy by default. Weed out developers and apps doing shady shit so I don't have to worry what I install blindly on my phone. Being on the Play Store should be equivalent to Google saying "We can vouch for this app. It won't harm you or your phone. Install and prosper."

permissions app?

[didjitaal]

Is there an app that can let the user set permissions of other android apps?

About Google Policies

[arvindattri]

I think now a days google is more strong in comparision of others. Google works on his privacy policies. I think if it genrate new thing then he also work on his negative site. So we want to wait and lets see.

Well, no.

[Anonymous Coward]

Google wants companies to actually write apps for the Google Play store. If they give end-users too much power over the permissions, they drive companies out

Nope. As long as android phones sell, corps will sell apps for them. If users can trivially block any ad server, then you won't see those ad-financed apps. But you will still get the payware.

Corps want to make money. They can do that selliing games, content, and all sorts of useful apps. They don't really need my contact list or any snooping powers.

Things for which there is no app

[tepples]

What exactly is missing so crucial from iOS?

I've compiled a list based on Apple's guidelines. For example, Apple provides no public API to create anything like MozStumbler or WiFi-Where. Nor does Apple allow for development of a web browser that supports WebGL.

Re:Phone security frameworks are fundamentally fla

[Cytotoxic]

This sounds very much like the way Microsoft tried to do security in Windows Vista. People did not react well to so many dialog boxes popping up.

Maybe that is why google decided that most people would rather just not have to deal with permissions in any real and meaningful way.

Well, no.

[Anonymous Coward]

"From a business perspective, this move makes perfect sense. From an educated geek end-user's perspective, it really sucks. But what are you going to do? The world you want to live in does not exist."

I'm gonna download F-Droid and only use software from there. Google can suck it.

No problem - Deny access to the SD Card

[coofercat]

I just found out last night that my Galaxy Note 8 can't write to it's SD card any more (after a KitKat update). This also is some brain-dead move by Google to make my tablet "more secure".

What it's actually done is pissed me off so much that I'm now going to spend the time rooting the thing. I can understand limiting apps to certain areas of the system, but giving them 100% unfettered access to the internal storage, and deny just about anything from the SD card isn't it.

I'd like to be able to see the list of permissions an app needs (in groups, if you like), and then deselect any I don't think it should have - if an app I don't like the look of wants to use my SD card, then I should be able to turn it off. I know this is possible with a rooted system, so it seems that's the only way to go for me (particularly as I quite like being able to use my SD card that Samsung took the time to bundle with my tablet).

If my phone asks me to upgrade to kitkat, I'm gonna say no. I'm sure that doesn't make me more secure. I'm sure rooting my tablet isn't really Google's idea of "more secure" either. Assuming I'm right about that, then they should find a way to let me override their brain-dead missteps.

if you're interested in security.. or privacy

[Anonymous Coward]

dont buy a smartphone. problem solved.

Undo history takes space

[tepples]

Undo history is nice, but it can be overdone. Consider what the user might think when he finds that he can't install an application because the device's storage has become clogged with another application's undo history. What would you recommend that developers do to avoid a case like that?

Re:Undo history takes space

[Neil Boekend]

Theoretically I would hazard a guess that it is possible to make the undo history configurable (undo history max X steps) like it used to be or even automatically depend on the free space on the device if we really want to continue the current folly of "If you don't like our settings then %*&* you" and "EVERYTHING FIXED!!!1!!ONE!!1!!!1!" instead of decent options.

I love "About:config" and other advanced options panels. They separate the ordinary users from the advanced options but leave them available for advanced users.

Re:Undo history takes space

[lgw]

To both questions in the thread: it's the dev team's job to pick reasonable defaults. Obviously, budget will influence your ability to base that on real user data, but then budget affects almost everything. Sometimes the right choices can be obvious (e.g., a game with checkpoints - you already defined where you go back to if something goes wrong, might as well make that true out-of-character as well), sometimes you just have to use your best judgment, and let the expert user change the defaults. Undo on a phone? How much content is the user likely to create in the first place? Undo in an IDE? Go wild.

Not to say you shouldn't take advantage of the opportunity for a graceful shutdown, but I've met too many devs who just don't stop to think what would happen if power were lost at any random point - at least don't corrupt the user's files if you crash!

Helper app to reduce another app's RPO

[tepples]

I had to look up RPO and RTO first.

Do you seriously believe that's how it has to work? Choose your RPO and RTO appropriately for what you're doing.

Recovery point objective expectations differ among users. One user (lgw) prefers a longer RPO and is willing to lose several seconds of work so long as an application doesn't require the phone state permission. Another user (not lgw) prefers a shorter RPO and is willing to use the phone state permission to achieve this objective. How should a developer serve both classes of users? Would it be practical to put one app on the store ("SurfWriter") and a second helper app whose only purpose is to reduce the first app's RPO but which requires the phone state permission ("Autosave for SurfWriter")?