Much better is the iOS model where there are a select few extra-sensitive permissions that cause a popup when the app requests it and lets the user decide if they're going to grant it at runtime, not install time. That lets the user know what triggered the request and decide if it's legitimate. It also allows them to continue using an app even if they don't want to share their location or whatever.
No, the user is supposed to see the first 2, ignore the hidden "show more" button, and then just hit Accept.
This is one of Android's more obnoxious user-security flaws.
I do appreciate that Android points out even smaller details, however: "access to your contacts" is one that works without prompting on iOS, if I remember correctly.
It'd be nice if users could choose both the level of detail and choose piecemeal.
> "access to your contacts" is one that works without
> prompting on iOS, if I remember correctly.
This way users of any app in the Android ecosystem can rely on the wisdom of the crowds to quickly see which permissions people who know better commonly disable.
Should every user look over the entire list? Yes, in an ideal world. But since that isn't realistic, the best we can do is present them with those they will mostly likely want to disable right at the top.
1. Enable the user to select "a la carte" permissions on a per-app basis.
2. The user selectively turn off permissions, e.g. I WANT my flashlight app to throw an unhandled exception when it tries to get my location.
3. Require exception handling for missing permissions in new versions.
The burden for developers is low, especially in the cases of gratuitous permissions.
There are some cases, like address book apps that require access to the Contacts provider where a permission could make an app's functionality a nullity, but I think the everyday user is OK with seeing a crash dialog if a crappy app with obnoxious permissions craps out.
In the case of a high-value app like Facebook, Facebook would be motivated to explain permissions and provide exception handling that preserves as much functionality as possible.
If app compatibility becomes an issue, "nerfed" results instead of thrown exceptions could be used to trick apps into accepting fake data.
By combining options, notifications to the user, the use of SecurityException, and changes to exception handling requirements, Google could readily retrofit fine-grained user-controlled permissions to Android.
"Android malware up 614%. Android Home to 92% of Mobile Market's Malware"
http://www.theregister.co.uk/2013/06/26/android_malware_bloo...
What utter garbage. They're really going to claim it was an accident?
Oh, and my Xperia Play came with Facebook for Xperia that integrated a lot with it and I almost bricked the phone trying to remove it, needed to do some warranty-breaking stuff to re-install a firmware from scratch.
-Zuck
http://gawker.com/5636765/facebook-ceo-admits-to-calling-use...
He said it when he was 19 (!!) in regards to a web form he made where people submitted their emails, phone numbers, and social security numbers with nothing else besides that form. The users were indeed stupid as shit in that situation.
I'd also like to remind you that he's 29 now and running one of the most successful companies in the world. If you think he hasn't learned something in the span of 10 years, you're delusional and your comments as well as that article is sensationalist.
I started using LBE to selectively block security requests by apps last Summer after being required to install an e-mail app on my personal phone for work that harvests your contact lists and call history. I soon discovered lots of mischief going on with my phone from all kinds of apps and it was rather infuriating.
"The first time you launch the Facebook application, even before logging in, your phone number will be sent over the Internet to Facebook servers. You do not need to provide your phone number, log in, initiate a specific action, or even need a Facebook account for this to happen."
so an accidental launch is all you need.
http://threatpost.com/facebook-underplays-data-exposure-from...
https://play.google.com/store/apps/details?id=com.facebook.k...
* Directly call phone numbers: Allows the app to call phone numbers without your intervention. This may result in unexpected charges or calls. Note that this doesn't allow the app to call emergency numbers. Malicious apps may cost you money by making calls without your confirmation.
* Read phone status and identity: Allows the app to access the phone features of the device. This permission allows the app to determine the phone number and device IDs, whether a call is active, and the remote number connected by a call.
* Write call log: Allows the app to modify your device's call log, including data about incoming and outgoing calls. Malicious apps may use this to erase or modify your call log.
* Read call log: Allows the app to read your device's call log, including data about incoming and outgoing calls. This permission allows apps to save your call log data, and malicious apps may share call log data without your knowledge.
Account management I can understand. Location makes sense for checking-in and what not. Reading/modifying contacts also makes sense if you'd like it to manage your contacts automatically.
The call logs are the ones that really confuse me. The only thing I can think of that would make sense is charging for Facebook Credits via your carrier and trying not to confuse the user into thinking they're getting charged twice (once via the Facebook App and once more via the phone call).
I am not going to say to avoid FB, but if you really want it on the phone, please use a non-official version for privacy sake. Atleast on android, they are less sucky than the official version. One of those times I am happy a company doesn't make an official version for Windows Phone and the MS version doesn't suck.
We had issues where certain Android versions were unable to install our app. The workaround involved renaming some of our data files to use a .jpg extension so that they would be treated as image assets and not loaded entirely into memory on install, causing the device to run out of RAM. (I forget the exact details, as my coworker discovered the issue and workaround at the time.)
If you told the average web-using person that whenever they visit google.com Google gets to know which internet provider you use and from which country, possibly even city you come from and which language you speak, they'd probably freak out thinking it was some evil Google scheme to mine data when in fact, all that is simply a byproduct of any reasonable logging or analytics solution that is not special to Google at all.
If that's true -- that an objective reasonable observer would think those things -- perhaps that's indicative of analytics being of questionable ethical standing.
After all, they enable the massive centralization of extremely far reaching user data, voluntarily submitted by both applications and websites to centralized data brokers -- such as Google -- who are not only positioned to build enormous commercial profiles of users, but also to (be compelled to) give or sell those profiles to government(s).
http://hothardware.com/News/Android-Home-to-92-of-Mobile-Mar...
http://android-jellybean.com/2013/06/android-home-to-92-of-m...
He's learned to keep his little narcissistic mouth shut.
The fact that "phone state" is mixed up with Phone Unique ID is terrible.
Read phone status and identity: Allows the app to access the phone features of the device. This permission allows the app to determine the phone number and device IDs, whether a call is active, and the remote number connected by a call.
https://play.google.com/store/apps/details?id=com.facebook.k...
And don't worry if your friend has the Facebook app and calls you if you don't have a profile. They can just search through your friend's contacts to associate your number with a shadow profile of you anyway.
If the user puts some effort into parsing it, they will understand it and what it means for their privacy. But most people will not put that much effort into installing an app.
Despite being perfectly clear to you and I, it is wrong to ask for these permissions at install time.
Imagine if every time you visited a web site you were given a list of 5 - 10 permissions requested by the website before you could visit.