Android: I don't need your permission

I wish it was that easy in all cases.<p>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).<p>The catch is, this is not an Intent you can send or request easily. We tried so many other ways, but none work.<p>But on the play store it&#x27;s written &quot;read phone status and identity&quot; and that&#x27;s really really scary for the users.<p>And even if we&#x27;re 100% open source, so people can check the application, and even people recompile VLC, this is a complaint we receive a lot...

&gt; If your app is closed-source then they have no way of verifying you&#x27;re not downloading all their contacts to their servers.<p>That&#x27;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:<p>A) Download the source yourself B) Inspect the source C) Compile the source<p>Just because you have the source doesn&#x27;t mean what you get from the Play Store&#x2F;Amazon App store is 1:1 identical or even similar.<p>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.

&gt; Case in point: android.permission.CALL_PHONE. You need it to initiate phone calls from your app, right?<p>This kind of thing is why I can&#x27;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.<p>Permissions on Android are horrendous for developers. But they are even worse for users. If a developer can&#x27;t tell the difference between ACTION_CALL and ACTION_DIAL, what chance does the average end-user have?<p>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 &quot;agree&quot; 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.<p>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).<p>The comment by jbk illustrates just how big a mess permissions on Android are, beyond just being confusing. On top of that you&#x27;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.<p>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&#x27;s also a brilliant case study in over-engineering with a complete failure to consider human psychology.

There are two additions to the permissions API that I think would be very helpful:<p>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&#x27;t monitoring your phone at 3am.<p>Here is the problem though: most people don&#x27;t actually care. The vocal minority cares, but most Android users don&#x27;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.

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 <a href="https://play.google.com/store/apps/details?id=com.findsdk.apppermission" rel="nofollow">https:&#x2F;&#x2F;play.google.com&#x2F;store&#x2F;apps&#x2F;details?id=com.findsdk.ap...</a> (requires root I guess)<p>The most helpful one, even if you are not privacy&#x2F;security concerned is to disable wake up&#x2F;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.<p>Perhaps Android should rephrase these permissions as, for instance &quot;direct access to contacts without your knowledge&quot;, as opposed to &quot;access to user-selected contacts upon request&quot; (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).<p>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.<p>Developers could of course write the apps to not work under such reduced conditions, but Google Play could reject such apps.

I made app ethics[1] a while back in hopes to surface what some of the android permissions mean.<p>[1] <a href="http://appethics.org" rel="nofollow">http:&#x2F;&#x2F;appethics.org</a>

Crazy theory but stick with me please -<p>Why aren&#x27;t we as users allowed to fine grain the data on our device that we want the app to have access to?<p>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&#x27;s cloud service, assign the image to a contact and so forth.<p>But as a user I only want the app for it&#x27;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.<p>It&#x27;s then down to the app &#x2F; developer to handle the exceptions and offer a message saying &quot;You have taken a picture, but the app doesn&#x27;t have permission to save it to storage. Please allow access by clicking here, otherwise this feature will not work&#x2F;be unavailable&quot;.<p>A bit more of effort on the developers part, no question - but a user than has complete control over what an app can access.<p>I&#x27;m not an app developer, but skimming over how intents work and chiming along with this article - I don&#x27;t think it would be a significant change to the underlying structure of android to hand back specific permission controls to a user.

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.

Another reminder of how eagerly I await Xposed &#x2F; 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).

In the case of bluetooth, you can either (1) request BLUETOOTH_ADMIN permission and enable BT yourself, or (2) ask Android to show an &quot;Enable Bluetooth Dialog&quot; (BluetoothAdapter.ACTION_REQUEST_ENABLE) which doesn&#x27;t require that permission.<p>But #2 has been busted for a while <a href="https://code.google.com/p/android/issues/detail?id=60002" rel="nofollow">https:&#x2F;&#x2F;code.google.com&#x2F;p&#x2F;android&#x2F;issues&#x2F;detail?id=60002</a><p>They didn&#x27;t fix it, and marked it obsolete. So I guess we need BLUETOOTH_ADMIN after all.

Good article. As good as Google&#x27;s permission system is, it lacks obvious features. Maybe I&#x27;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&#x27;s essentially the same security model as the web.<p>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&#x27;t affect the code <i>or UI</i> of.<p>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&#x27;s contacts.<p>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.<p>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, &quot;Do you want this to happen automagically henceforth?&quot; which would then take full use of the Phone permission. This would also allow permissions to be toggled on&#x2F;off, which a feature I really want in Android.

Just curious though for these specific examples as it says &quot;if you read the source&quot;, could these intent&#x27;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&#x27;s halfarsed attempt at a privacy layer, it also doesn&#x27;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&#x2F;privacy guard that are just a few.<p>Although really, what needs to change isn&#x27;t just in android itself; it&#x27;s also developer behaviour. Stop <i>trying</i> to do intrusive things like prefilling forms, as it doesn&#x27;t benefit the user in any real way.

This is classic privilege elevation via a 3rd party privileged process. I thought Android&#x27;s permission system carrying the security context from app to app through Intent. Guess the assumption is wrong.<p>In most OS, the security token&#x2F;context of the initiating process is carried over to the target process when it&#x27;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.

The same goes for android.permission.INTERNET. Apps can open arbitrary URLs in the browser (which load without user intervention).

The theory seems great. The reality is not.<p>When you do that, you delegate your UX and proper functionning of your app to a third-party app.<p>The UX can vary according the app. One thing is certain, it won&#x27;t always be consistent with your app. It is also going to be more complicated for the user (more actions to make, more choices, just because you don&#x27;t want to add permissions).<p>The proper functionning is even worse. Did you ever heard about the fragmentation of Android? Well, Intents are where it&#x27;s worse. Some apps plainly don&#x27;t work, or are buggy.<p>Intents are great to save time prototyping something. However, if a feature is central to your app, you are better off ensuring yourself that it works well and is easy to use, something that Intents can&#x27;t guarantee.<p>Of course, the permission system is far from ideal, and some people will not install your app because you ask for some permissions. I&#x27;d say that&#x27;s a price to pay for developping on Android.<p>P.S.: some examples of Intents that don&#x27;t work so well:<p>1) sending a mail. Good luck finding how to properly use an Intent that is not handled by text apps and allow you to put attachments<p>2) picking a photo from gallery and resize. A lot of photo apps are plain broken for that Intent. And I&#x27;m not talking about some obscure device on a rooted Android, I&#x27;m talking about Google&#x27;s Nexus, with stock apps.

I recently got a Moto E as my first smart phone, ever, and after checking out some apps, I was astounded and befuddled by the access permissions that it seems every app needs.<p>Take ESPN&#x27;s fantasy football app, which requires: device and app history - whats apps are running, browsing history, bookmarks identity - accounts on the device, profile data photo&#x2F;media&#x2F;files - access to files on the device and the device&#x27;s external storage wi-fi connection information - whether wi-fi is enabled, names of connected wi-fi devices device ID and call information - determine the phone number and device IDs, whether a call is active, and the remote number connected by a call<p>I can understand why it might need access to the file system to, for example, upload an avatar. The access to wi-fi seems innocuous, although I would expect something like network connectivity and status to be delegated to a kernel module or background daemon with which an app interfaces.<p>But is there any legitimate (i.e. some non-financial oriented mine as much data as possible) reason it needs to be able to see what other apps are running, my browser history or who is on the other end of a call? There might not be any reason, and ESPN could potentially build the app to have as many or as few permissions as they deem valuable, because people want an app to manage fantasy football teams first. While this example might not be the best, since ESPN is a huge brand and there is no alternative if they are hosting your league, the situation was the same with so many other apps; just absurd permission requirements.<p>None were installed.