Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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

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.

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.

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.

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.

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.

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

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

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.

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.

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 (weathe

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

I'd agree entirely with that.<br><br>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

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 helpe

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 m

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.

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

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 o

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.

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.

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?

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.

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.

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.

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.

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.

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 i

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.

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.

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 thre

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

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 ti

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)

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'

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

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

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.

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 12. 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 installed3. Re-introduce AppOps functionality or at the minimum an audit trail of when-last and how often the application attempts a specific permission operation/category4. 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..

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.

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

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.

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"

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.

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 consu

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.

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.

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 flabb

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.

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.

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

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.

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.

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

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.