For VLC on Android, we need the READ_PHONE_STATE permission, in order to stop the music when a phone call is coming in. We just use it to make pause on incoming call. (VLC on Android is also an audio player, with a background audio service).
The catch is, this is not an Intent you can send or request easily. We tried so many other ways, but none work.
But on the play store it's written "read phone status and identity" and that's really really scary for the users.
And even if we're 100% open source, so people can check the application, and even people recompile VLC, this is a complaint we receive a lot...
> For VLC on Android, we need the READ_PHONE_STATE permission, in order to stop the music when a phone call is coming in. We just use it to make pause on incoming call.
It's seriously back-asswards that you'd have to have access to all phone state just to be able to start and stop audio on phone calls.
By comparison iOS has an audio interruption system which gets triggered on phone calls, alarms (calendar and clock) and other applications taking over the audio, the application getting interrupted neither not knows nor cares where the interruption comes from, only that it doesn't have the audio stream anymore.
It almost seems like they do it intentionally to improve tracking and desensitize users. Only a terrible engineer would think needing to know if the phone is ringing needs a permission, let alone one that provides unique IDs plus the phone numbers on phone calls.
It's one more reason I've gone from loving Google to actively avoiding them. (Also, they've very aggressive in getting people to turn on location info and history. They use dark UI patterns to trick people into activating stuff.)
I also have an audio app with a background audio service on Google Play, and I also have to request the READ_PHONE_STATE permission. I have an explanation in my store listing but I still get emails about it every week.
It's totally nuts. Knowing the phone is ringing or off the hook should not be privileged information.
I've been working on a streaming music player for Android lately. After doing some basic testing on one device, onAudioFocusChange seems to be all I need to duck and pause/resume for incoming calls, but I'd like to make sure I handle all the corner cases correctly.
> If your app is closed-source then they have no way of verifying you're not downloading all their contacts to their servers.
That's a common fallacy. Even if it is open source someone could still be doing that. In order to be secure you would have to:
A) Download the source yourself
B) Inspect the source
C) Compile the source
Just because you have the source doesn't mean what you get from the Play Store/Amazon App store is 1:1 identical or even similar.
There is secret option D, have someone you trust do A through C and then give you the hash of the resulting compiled file. But two programs compiled on two machines often give different results due to library versions, compiler versions, environmental settings, and so on.
I'm an F-Droid developer, and we do in fact do secret option D.
There is a small but passionate group of people who are very focused on deterministic builds in Android working with us as well [0]. The end goal is to be able to install fdroidserver, then run:
fdroid verify
And it will do all of this for you (download source, compile source, verify binary against another binary).
Of course, option B) is always a problem, but I guess the best solution short of paying to audit every single open source app is to fall back to the many eyes theory and hope it holds us in good stead.
EDIT: For those interested, one of the reasons we are interested in deterministic builds is so that we can verify that our build of the source corresponds to the upstream build. If that is the case, then we will be confident distributing the upstream binary (i.e. signed by the upstream developer). It is not possible to install a .apk from upstream, and then update it with a version signed by F-Droid - for very good and legitimate reasons. Distributing builds signed by upstream alleviates this problem.
Except that it is possible to have lots of someones reliably do A through C with a defined environment and get the exact same output every time they compile it. It's referred to as 'deterministic' builds. Bitcoin and Tor are doing it, for example.
Most of the people that dismiss the security advantages of open source either don't understand them or are trying to sell you some closed source code.
The chain of trust doesn't quite stop at compiling the source, in order to be really sure that nothing unintended is going on you have to compile the compiler yourself. At the end of the day you will have to trust some bootstrapping binary compiler unless you put it together yourself in machine language.
In practice you can disassemble Java apps to pseudo source code anyway. I've done it several times to APKs to see what is going on under the covers. Deliberate obfuscation would be immediately suspicious.
> Case in point: android.permission.CALL_PHONE. You need it to initiate phone calls from your app, right?
This kind of thing is why I can't see myself switching to Android as my primary mobile OS any time soon. If anything, I can see a bright future for Microsoft. In spite of the fact Windows Phone exists, Android is very much the Windows of the mobile ecosystem.
Permissions on Android are horrendous for developers. But they are even worse for users. If a developer can't tell the difference between ACTION_CALL and ACTION_DIAL, what chance does the average end-user have?
And when every app requests at least half a dozen permissions, how many users are going to carefully review each and every permission and how many are just going to give up and grant all requested permissions to every app the way that everyone reflexively clicks "agree" to every online ToS? Even if Android actually had a working method to deny individuals permissions, nobody ever has any idea which permissions are essential to which classes of app and which should be treated with suspicion.
Compare this to iOS, where you may occasionally get asked to grant an app access to contacts or location - this is a rare occurrence and you can choose deny every time with no negative consequences (except for restricting that functionality).
The comment by jbk illustrates just how big a mess permissions on Android are, beyond just being confusing. On top of that you've got custom intents, which while a great idea on paper, just pile more complexity on top of a broken foundation of complexity and obfuscation.
This IMO is the single biggest thing wrong with Android, which Google should prioritise fixing like Microsoft in 2002. Never mind signed-app stores like Play: the fundamentally broken security model is the reason why Android is the only mobile platform to have a problem with malware. It's also a brilliant case study in over-engineering with a complete failure to consider human psychology.
>And when every app requests at least half a dozen permissions
I think this is the core problem here. The "list of permissions" system doesn't make sense to anyone and just seems like some project manager following a list of checkboxes from a list of security practices.
I recently stopped using my Nexus 10 due to getting an iPad3 for a steal. I love being asked if an application can use my location, as opposed to having god knows how many apps on my N10 silently sampling my position. I love knowing that the entire OS isn't dedicated to better selling ads for app publishers. Apple, for all its faults, isn't in bed with the ad industry like Google is.
I really was hoping features like this would come to Lollipop, but apparantly this isn't a priority for Google. Instead we get a byzantine line of permissions no one understands and we all say "Yes" because we want the app. There's no alternative. If the Amazon Kindle app has a permission I must accept it to read my books. I can't just say "No" to location awareness or contact list reading.
I' an Android (Cyanogenmod) user and agree with your point, this could--and should--be done a lot better.
I am not familiar with iOS and iPhones at all. You state iOS apps only rarely need to be granted permissions, how do they make that work? I can see only three ways that could happen:
Either the app can do most things without asking permissions (bad for the user--there'd be malware). Or the app simply can't ask for permission to do a lot of things (bad for the developer, and ultimately the user--because less functionality). Or it's a combination of the first combined with the iOS App Store's walled-garden quality check approach (bad for everybody, and the biggest reason I got an Android instead of iOS device).
I could be wrong but I'm guessing it's the third option?
I'm going to try to be objective here, crazy how I can just feel that seed of fanboiism in my head, let me just leave it at me being idealistically opposed to the walled garden approach for reasons that have been rehashed on HN for ages now :)
That said, there's also a few practical things the iOS walled-garden App Store could improve upon. First one being the $99 developer fee. I teach kids computerstuff and one time a particularly clever 11-year old needed some help setting up Eclipse, I didn't have a smartphone myself back then, I wasn't sure what he was trying to do, so I just helped him navigate the English menus, install the proper Java things and let him at it. Sure enough, an hour later he proudly showed me his Android phone. "Hello World", it said.
Another thing, this iOS App Store review process, it's done by humans yes? Does it scale? From what I've heard, even though I mostly heard it in the form of complaints, you get rejected by actual humans, yes? That's obviously never going to happen to Google's Play Store. But then again, the Google Play Store isn't quite as deeply engrained into Android as the iOS App Store, you don't need to use it, you can even completely step out of Google's ecosystem and still use Android (though it's hard, a bit like using Linux 15 years ago). Does the iOS App Store also use scanners and automated tests for new applications? I bet they do, do we know what kinds? Like it could test for certain kinds of API calls so the human reviewers know what sort of thing to look for.
One funny thing is, I used to have to explain people what "repositories" are in Linux, what they do, what they're used for and why they're so much cooler than (Windows) having to download .exe installers from all sorts of websites to get your software. Nowadays I can just tell people "it's pretty much like an app store", and they know all they need to know. That Ubuntu Software Centre even looks like an app store, with all the stars and ratings (blegh).
However, the repositories in Linux, are not quite like either the Google Play Store or iOS App Store. They obviously do not have the walled-garden approach, it's entirely open. Linux software from the repositories doesn't need to ask for permission for anything (except sudo). Still, there is no malware in the repositories, at all. I admit I am a little bit vague on how this works too, perhaps I'm missing something obvious, but how do they do that?
There are two additions to the permissions API that I think would be very helpful:
1) Incremental Authorization - let Android apps ask for permissions only as they need them. So if you never use the phone dialing feature, they never ask for the permission.
2) One-time auth - allow an Android app to do something once. Say, scan your contacts one time. This gives you a little more control, so you know the dev isn't monitoring your phone at 3am.
Here is the problem though: most people don't actually care. The vocal minority cares, but most Android users don't know what a permission is if you ask them. So all that developers get for trying to work around permissions is less people using their app or less features in the app. Sadly there is no real incentive for a developer to be sparing with permissions for apps that target the mass market.
1) Incremental Authorization - let Android apps ask for permissions only as they need them. So if you never use the phone dialing feature, they never ask for the permission.
Not only incremental authorization, but the ability of denying specific permissions.
iOS has taken option 1 since the beginning and it works.
I can install Instagram and deny it access to the camera. It still works, it doesn't crap out on me. I don't need to install 3rd party rooted tools to provide fake camera for it.
This is the another reason I use CyanogenMod. It has Privacy Guard and I can disable the nasty permissions as I please. If you have Android 4.3+, you can also install it indivudally https://play.google.com/store/apps/details?id=com.findsdk.ap... (requires root I guess)
The most helpful one, even if you are not privacy/security concerned is to disable wake up/keep awake requests, which Facebook and FB Messenger used it apporximately 6800 times since I installed my clean rom 1 week ago.
This makes it all the more egregious that so many applications ask for permission to access contacts and similar.
Perhaps Android should rephrase these permissions as, for instance "direct access to contacts without your knowledge", as opposed to "access to user-selected contacts upon request" (which, as demonstrated, does not need permission).
I would be very happy if instead of preventing me from installing apps which require a given permission, Android would let me install them at my own risk in a sandbox which provides the app with dummy data and interactions (whether from a sensor, contacts db, camera etc).
It would be even better if the framework explicitly supported running apps without the necessary permissions and simply threw some sort of PermissionException. This would cripple some functionality while preserving the rest.
Developers could of course write the apps to not work under such reduced conditions, but Google Play could reject such apps.
Android had a hidden feature in certain iterations of Android 4, called "App Ops," that would let you do this but it never made it to prime time. Though Cyanogenmod does leverage it for their "Privacy Guard" feature.
This sounds like a great way for paranoid but uninformed users to break lots of apps, and then blame the developer/phone/carrier (in any random order).
We sometimes forget that really with smartphones the manufacturers are trying to produce something for the masses. This would also seem to include reducing the amount of security consciousness the user needs to have in order to have an "acceptable" experience with the device.
Why aren't we as users allowed to fine grain the data on our device that we want the app to have access to?
A benign example would be a camera app; it wants access to my camera and mic, perhaps the local storage. It may have further features to store images in it's cloud service, assign the image to a contact and so forth.
But as a user I only want the app for it's picture taking ability - the app requests at the point of installation the permissions it requires, and I only grant it access to the camera.
It's then down to the app / developer to handle the exceptions and offer a message saying "You have taken a picture, but the app doesn't have permission to save it to storage. Please allow access by clicking here, otherwise this feature will not work/be unavailable".
A bit more of effort on the developers part, no question - but a user than has complete control over what an app can access.
I'm not an app developer, but skimming over how intents work and chiming along with this article - I don't think it would be a significant change to the underlying structure of android to hand back specific permission controls to a user.
I guess the app would have to handle not being allowed permission to do these things gracefully.
That's possibly a tall order based on my experience with apps these days, although for a difference reason: a lot of them assume there's internet connectivity, which isn't always the case, and a lot of apps don't handle this gracefully at all, even for doing things like opening maps, finding location, turning data off, going to another app, then back to maps again, and it takes ages for it to display because it's expecting to have network access.
I think it is not done that way because it would overwhelm most users. Maybe it could be some kind of expert mode, though. Don't some Android mods (like Cyanogen) allow you to do that?
Best i can tell, quite a few requested permissions do not come from the developer. Instead it is the defaults of some framework or other the developer used to handle some of the nitty gritty details, like the ads.
This is one of those weaknesses about 3rd party dependencies on Android. Unless business and product teams value user privacy and permissions, they usually could care less than vendor X's library requires permissions to read phone state or contacts when your app itself doesn't need it. Esp. given that iOS treats permissions differently, the distinction is often ignored in favor of whatever iOS does. To those managers, the fact that Android doesn't ask the user about using a permission is a happy coincidence.
Another angle being missed is that Android won't auto-update apps if they have new permissions (modulo some minor details). The developers I worked with always added more permissions to their initial app versions for things they weren't using, but might in the future.
Another reminder of how eagerly I await Xposed / Xprivacy on ART for 5.0... that said, his examples are fairly benign, I agree that if your app needs to initiate a call, it should show me the dialer to see if I would like to do that now, or some other time (including never).
If you're just waiting for permission controls, App Ops [1] should work just fine on 5.0. There are other comparable apps that also don't require Xposed.
In the case of bluetooth, you can either (1) request BLUETOOTH_ADMIN permission and enable BT yourself, or (2) ask Android to show an "Enable Bluetooth Dialog" (BluetoothAdapter.ACTION_REQUEST_ENABLE) which doesn't require that permission.
Good article. As good as Google's permission system is, it lacks obvious features. Maybe I'm missing something, but I think that Android permission are overly general and not specific enough in a majority of apps.
This is interesting because it's essentially the same security model as the web.
Your app runs in a controlled environment, and it has the option to nest another app (on the web, in an iframe) which it can send messages to, but can't affect the code or UI of.
The fact that the UI cannot be manipulated by the nesting app, is crucial, since it allows the security model to tie certain user actions, like pressing dial, to certain actions, like making a phone call.
I think all apps should be given a choice to have ephimeral permission. For example I dont want someone to find an exploit in my app and steal my user's contacts.
I would only take contacts permission when I need and keep it for a short duration and then willingly give it up. User can be explicitly prompted.
Also, Camera and Microphones should have only this sort of permissions other than for those which are explictily whitelisted by Google.
In the example about the phone call, you could give the user the option to hit the call button, but once this is complete a dialog should popup saying, "Do you want this to happen automagically henceforth?" which would then take full use of the Phone permission. This would also allow permissions to be toggled on/off, which a feature I really want in Android.
Just curious though for these specific examples as it says "if you read the source", could these intent's change in future releases, or is it documented outside of the source and accepted that using these intents is not relying on Android internals that could change?
This is why I love xprivacy. It gives me a popup when an app tries to access something, and I can whitelist or blacklist it, either on a temporary or permanent basis. Unlike google's halfarsed attempt at a privacy layer, it also doesn't give an exception when an app tries to access restricted data as that can cause apps to crash; it just sends back fake data (device ID is DEFACE, contacts are empty, location is christmas island, etc.). It also covers just about every permission you can think of, unlike app ops/privacy guard that are just a few.
Although really, what needs to change isn't just in android itself; it's also developer behaviour. Stop trying to do intrusive things like prefilling forms, as it doesn't benefit the user in any real way.
> Stop trying to do intrusive things like prefilling forms, as it doesn't benefit the user in any real way.
Speak for yourself -- I find prefilled forms to be a time-saver.
However, I don't want apps trying to read through my contacts in order to do it. What I want (but haven't actually configured) is xprivacy configured to make contacts appear empty.
This is classic privilege elevation via a 3rd party privileged process. I thought Android's permission system carrying the security context from app to app through Intent. Guess the assumption is wrong.
In most OS, the security token/context of the initiating process is carried over to the target process when it's asked to do something on behalf of the initiating process via IPC so that the target process runs at the privilege level of the initiating process even if the target process has a higher privilege to start with.
[+] [-] jbk|11 years ago|reply
For VLC on Android, we need the READ_PHONE_STATE permission, in order to stop the music when a phone call is coming in. We just use it to make pause on incoming call. (VLC on Android is also an audio player, with a background audio service).
The catch is, this is not an Intent you can send or request easily. We tried so many other ways, but none work.
But on the play store it's written "read phone status and identity" and that's really really scary for the users.
And even if we're 100% open source, so people can check the application, and even people recompile VLC, this is a complaint we receive a lot...
[+] [-] masklinn|11 years ago|reply
It's seriously back-asswards that you'd have to have access to all phone state just to be able to start and stop audio on phone calls.
By comparison iOS has an audio interruption system which gets triggered on phone calls, alarms (calendar and clock) and other applications taking over the audio, the application getting interrupted neither not knows nor cares where the interruption comes from, only that it doesn't have the audio stream anymore.
[+] [-] MichaelGG|11 years ago|reply
It's one more reason I've gone from loving Google to actively avoiding them. (Also, they've very aggressive in getting people to turn on location info and history. They use dark UI patterns to trick people into activating stuff.)
[+] [-] gabemart|11 years ago|reply
It's totally nuts. Knowing the phone is ringing or off the hook should not be privileged information.
[+] [-] johnsoft|11 years ago|reply
I've been working on a streaming music player for Android lately. After doing some basic testing on one device, onAudioFocusChange seems to be all I need to duck and pause/resume for incoming calls, but I'd like to make sure I handle all the corner cases correctly.
[+] [-] Someone1234|11 years ago|reply
That's a common fallacy. Even if it is open source someone could still be doing that. In order to be secure you would have to:
A) Download the source yourself B) Inspect the source C) Compile the source
Just because you have the source doesn't mean what you get from the Play Store/Amazon App store is 1:1 identical or even similar.
There is secret option D, have someone you trust do A through C and then give you the hash of the resulting compiled file. But two programs compiled on two machines often give different results due to library versions, compiler versions, environmental settings, and so on.
[+] [-] pserwylo|11 years ago|reply
There is a small but passionate group of people who are very focused on deterministic builds in Android working with us as well [0]. The end goal is to be able to install fdroidserver, then run:
And it will do all of this for you (download source, compile source, verify binary against another binary).Of course, option B) is always a problem, but I guess the best solution short of paying to audit every single open source app is to fall back to the many eyes theory and hope it holds us in good stead.
EDIT: For those interested, one of the reasons we are interested in deterministic builds is so that we can verify that our build of the source corresponds to the upstream build. If that is the case, then we will be confident distributing the upstream binary (i.e. signed by the upstream developer). It is not possible to install a .apk from upstream, and then update it with a version signed by F-Droid - for very good and legitimate reasons. Distributing builds signed by upstream alleviates this problem.
[0] - https://f-droid.org/wiki/page/Deterministic,_Reproducible_Bu...
[+] [-] foo2312|11 years ago|reply
Even compiling from source, one also has to trust the compiler...
(see, e.g. the classic http://cm.bell-labs.com/who/ken/trust.html, pdf version at https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...)
[+] [-] JohnTHaller|11 years ago|reply
Most of the people that dismiss the security advantages of open source either don't understand them or are trying to sell you some closed source code.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] joshfraser|11 years ago|reply
[+] [-] zak_mc_kracken|11 years ago|reply
[+] [-] mrpdaemon|11 years ago|reply
[+] [-] nly|11 years ago|reply
[+] [-] mbesto|11 years ago|reply
[+] [-] robert_tweed|11 years ago|reply
This kind of thing is why I can't see myself switching to Android as my primary mobile OS any time soon. If anything, I can see a bright future for Microsoft. In spite of the fact Windows Phone exists, Android is very much the Windows of the mobile ecosystem.
Permissions on Android are horrendous for developers. But they are even worse for users. If a developer can't tell the difference between ACTION_CALL and ACTION_DIAL, what chance does the average end-user have?
And when every app requests at least half a dozen permissions, how many users are going to carefully review each and every permission and how many are just going to give up and grant all requested permissions to every app the way that everyone reflexively clicks "agree" to every online ToS? Even if Android actually had a working method to deny individuals permissions, nobody ever has any idea which permissions are essential to which classes of app and which should be treated with suspicion.
Compare this to iOS, where you may occasionally get asked to grant an app access to contacts or location - this is a rare occurrence and you can choose deny every time with no negative consequences (except for restricting that functionality).
The comment by jbk illustrates just how big a mess permissions on Android are, beyond just being confusing. On top of that you've got custom intents, which while a great idea on paper, just pile more complexity on top of a broken foundation of complexity and obfuscation.
This IMO is the single biggest thing wrong with Android, which Google should prioritise fixing like Microsoft in 2002. Never mind signed-app stores like Play: the fundamentally broken security model is the reason why Android is the only mobile platform to have a problem with malware. It's also a brilliant case study in over-engineering with a complete failure to consider human psychology.
[+] [-] pjmlp|11 years ago|reply
I have both Android and Windows Phones.
The Windows Phone is actually quite good and from developer point of view, a pleasure compared with Android tooling and APIs.
Just the way Microsoft behaved with the customers has made many look elsewhere.
[+] [-] drzaiusapelord|11 years ago|reply
I think this is the core problem here. The "list of permissions" system doesn't make sense to anyone and just seems like some project manager following a list of checkboxes from a list of security practices.
I recently stopped using my Nexus 10 due to getting an iPad3 for a steal. I love being asked if an application can use my location, as opposed to having god knows how many apps on my N10 silently sampling my position. I love knowing that the entire OS isn't dedicated to better selling ads for app publishers. Apple, for all its faults, isn't in bed with the ad industry like Google is.
I really was hoping features like this would come to Lollipop, but apparantly this isn't a priority for Google. Instead we get a byzantine line of permissions no one understands and we all say "Yes" because we want the app. There's no alternative. If the Amazon Kindle app has a permission I must accept it to read my books. I can't just say "No" to location awareness or contact list reading.
[+] [-] tripzilch|11 years ago|reply
I am not familiar with iOS and iPhones at all. You state iOS apps only rarely need to be granted permissions, how do they make that work? I can see only three ways that could happen:
Either the app can do most things without asking permissions (bad for the user--there'd be malware). Or the app simply can't ask for permission to do a lot of things (bad for the developer, and ultimately the user--because less functionality). Or it's a combination of the first combined with the iOS App Store's walled-garden quality check approach (bad for everybody, and the biggest reason I got an Android instead of iOS device).
I could be wrong but I'm guessing it's the third option?
I'm going to try to be objective here, crazy how I can just feel that seed of fanboiism in my head, let me just leave it at me being idealistically opposed to the walled garden approach for reasons that have been rehashed on HN for ages now :)
That said, there's also a few practical things the iOS walled-garden App Store could improve upon. First one being the $99 developer fee. I teach kids computerstuff and one time a particularly clever 11-year old needed some help setting up Eclipse, I didn't have a smartphone myself back then, I wasn't sure what he was trying to do, so I just helped him navigate the English menus, install the proper Java things and let him at it. Sure enough, an hour later he proudly showed me his Android phone. "Hello World", it said.
Another thing, this iOS App Store review process, it's done by humans yes? Does it scale? From what I've heard, even though I mostly heard it in the form of complaints, you get rejected by actual humans, yes? That's obviously never going to happen to Google's Play Store. But then again, the Google Play Store isn't quite as deeply engrained into Android as the iOS App Store, you don't need to use it, you can even completely step out of Google's ecosystem and still use Android (though it's hard, a bit like using Linux 15 years ago). Does the iOS App Store also use scanners and automated tests for new applications? I bet they do, do we know what kinds? Like it could test for certain kinds of API calls so the human reviewers know what sort of thing to look for.
One funny thing is, I used to have to explain people what "repositories" are in Linux, what they do, what they're used for and why they're so much cooler than (Windows) having to download .exe installers from all sorts of websites to get your software. Nowadays I can just tell people "it's pretty much like an app store", and they know all they need to know. That Ubuntu Software Centre even looks like an app store, with all the stars and ratings (blegh).
However, the repositories in Linux, are not quite like either the Google Play Store or iOS App Store. They obviously do not have the walled-garden approach, it's entirely open. Linux software from the repositories doesn't need to ask for permission for anything (except sudo). Still, there is no malware in the repositories, at all. I admit I am a little bit vague on how this works too, perhaps I'm missing something obvious, but how do they do that?
[+] [-] nodata|11 years ago|reply
Huh? If a developer had made the choice correctly, the user would never need to know about it.
[+] [-] habosa|11 years ago|reply
1) Incremental Authorization - let Android apps ask for permissions only as they need them. So if you never use the phone dialing feature, they never ask for the permission. 2) One-time auth - allow an Android app to do something once. Say, scan your contacts one time. This gives you a little more control, so you know the dev isn't monitoring your phone at 3am.
Here is the problem though: most people don't actually care. The vocal minority cares, but most Android users don't know what a permission is if you ask them. So all that developers get for trying to work around permissions is less people using their app or less features in the app. Sadly there is no real incentive for a developer to be sparing with permissions for apps that target the mass market.
[+] [-] Aldo_MX|11 years ago|reply
Not only incremental authorization, but the ability of denying specific permissions.
[+] [-] theshrike79|11 years ago|reply
I can install Instagram and deny it access to the camera. It still works, it doesn't crap out on me. I don't need to install 3rd party rooted tools to provide fake camera for it.
[+] [-] CSDude|11 years ago|reply
The most helpful one, even if you are not privacy/security concerned is to disable wake up/keep awake requests, which Facebook and FB Messenger used it apporximately 6800 times since I installed my clean rom 1 week ago.
[+] [-] JoshTriplett|11 years ago|reply
Perhaps Android should rephrase these permissions as, for instance "direct access to contacts without your knowledge", as opposed to "access to user-selected contacts upon request" (which, as demonstrated, does not need permission).
[+] [-] avz|11 years ago|reply
It would be even better if the framework explicitly supported running apps without the necessary permissions and simply threw some sort of PermissionException. This would cripple some functionality while preserving the rest.
Developers could of course write the apps to not work under such reduced conditions, but Google Play could reject such apps.
[+] [-] matkam|11 years ago|reply
[+] [-] brk|11 years ago|reply
We sometimes forget that really with smartphones the manufacturers are trying to produce something for the masses. This would also seem to include reducing the amount of security consciousness the user needs to have in order to have an "acceptable" experience with the device.
[+] [-] bndw|11 years ago|reply
[1] http://appethics.org
[+] [-] _s|11 years ago|reply
Why aren't we as users allowed to fine grain the data on our device that we want the app to have access to?
A benign example would be a camera app; it wants access to my camera and mic, perhaps the local storage. It may have further features to store images in it's cloud service, assign the image to a contact and so forth.
But as a user I only want the app for it's picture taking ability - the app requests at the point of installation the permissions it requires, and I only grant it access to the camera.
It's then down to the app / developer to handle the exceptions and offer a message saying "You have taken a picture, but the app doesn't have permission to save it to storage. Please allow access by clicking here, otherwise this feature will not work/be unavailable".
A bit more of effort on the developers part, no question - but a user than has complete control over what an app can access.
I'm not an app developer, but skimming over how intents work and chiming along with this article - I don't think it would be a significant change to the underlying structure of android to hand back specific permission controls to a user.
[+] [-] berkut|11 years ago|reply
That's possibly a tall order based on my experience with apps these days, although for a difference reason: a lot of them assume there's internet connectivity, which isn't always the case, and a lot of apps don't handle this gracefully at all, even for doing things like opening maps, finding location, turning data off, going to another app, then back to maps again, and it takes ages for it to display because it's expecting to have network access.
[+] [-] facepalm|11 years ago|reply
[+] [-] digi_owl|11 years ago|reply
[+] [-] king_jester|11 years ago|reply
[+] [-] rogerbinns|11 years ago|reply
[+] [-] bbcbasic|11 years ago|reply
[+] [-] blacksmith_tb|11 years ago|reply
[+] [-] delecti|11 years ago|reply
[1] https://play.google.com/store/apps/details?id=com.findsdk.ap...
[+] [-] clumsysmurf|11 years ago|reply
But #2 has been busted for a while https://code.google.com/p/android/issues/detail?id=60002
They didn't fix it, and marked it obsolete. So I guess we need BLUETOOTH_ADMIN after all.
[+] [-] Fando|11 years ago|reply
[+] [-] DeepDuh|11 years ago|reply
[+] [-] swatow|11 years ago|reply
Your app runs in a controlled environment, and it has the option to nest another app (on the web, in an iframe) which it can send messages to, but can't affect the code or UI of.
The fact that the UI cannot be manipulated by the nesting app, is crucial, since it allows the security model to tie certain user actions, like pressing dial, to certain actions, like making a phone call.
[+] [-] tn13|11 years ago|reply
I would only take contacts permission when I need and keep it for a short duration and then willingly give it up. User can be explicitly prompted.
Also, Camera and Microphones should have only this sort of permissions other than for those which are explictily whitelisted by Google.
[+] [-] jonalmeida|11 years ago|reply
[+] [-] stevebot|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] blueskin_|11 years ago|reply
Although really, what needs to change isn't just in android itself; it's also developer behaviour. Stop trying to do intrusive things like prefilling forms, as it doesn't benefit the user in any real way.
[+] [-] mcherm|11 years ago|reply
Speak for yourself -- I find prefilled forms to be a time-saver.
However, I don't want apps trying to read through my contacts in order to do it. What I want (but haven't actually configured) is xprivacy configured to make contacts appear empty.
[+] [-] ww520|11 years ago|reply
In most OS, the security token/context of the initiating process is carried over to the target process when it's asked to do something on behalf of the initiating process via IPC so that the target process runs at the privilege level of the initiating process even if the target process has a higher privilege to start with.