Slashdot Mirror
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."
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.
Makes me glad I run a Windows 8.1 phone.
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.
cripple apps by denying parts of their permission request. right now its all or nothing
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.}
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).
It is pitch black. You are likely to be eaten by a grue.
Install XposedFramework: ...then the Xprivacy module.
http://repo.xposed.info/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/
Please help metamoderate.
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.
Lost at C:>. Found at C.
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..
Bye!
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.
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.
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.
Two of my imaginary friends reproduced once
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
Koans and fables for the software engineer
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.
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).
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.
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.
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
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.