If you're like 99 percent of users, when iOS or Android asks you whether an app should be allowed to do this or that, you reflexively click the affirmative and give no thought at all to the substance of the request. Like the Acceptable Use Policy to which you also agree without reading, there's a reason these permissions requests exist, but very few people care.
Since there is a good reason for these permissions requests, it's worth asking who does it well and who doesn't. I looked into iOS, Android, Windows Phone and Windows (i.e., the Modern user interface/Metro apps). I think the similarities are more profound than the differences, but the differences are there if you look.
The main differences are in when the app asks for permission and what it asks for. Android users know that when they install an app they are usually presented with a list of permissions required by the app. iOS users get these requests as the app attempts to use the capability which requires permission. Windows and Windows Phone are hybrids. Sometimes they request a permission at install time, sometimes at run time. Sometimes they just inform you that they are using the feature without asking permission.
Android seems to ask for many more permissions than iOS or Windows. Android will ask, for example, whether the app should have access to the Internet. This is taken for granted in the other platforms. The number of permissions requested may actually be what made Google choose to have a single install-time request instead of dynamic, on-demand requests. Too many such requests at run-time could be an annoying user experience.
All operating systems use many of the same basic techniques, but Google goes in a different direction with them. The permissions model doesn't really work for any of them, but Android seems to me the most wrong. At the time a user is installing the app they don't want to have to read through a complicated list of permissions any more than they do a terms of service agreement. Google makes it worse by making the permissions very granular, asking permission for things like Internet access that probably makes some users decide not to take the rest of the list seriously.
Because of Android's all-or-nothing strategy, you need to allow all the permissions if you want to run the app. As a corollary, users can't change permissions at run-time, as the other platforms allow, at least in some cases.
The bottom line is that only on iOS does the operating system itself perform changes in privacy settings and other permissions with the user. Windows leaves this to the app developer, which is not necessarily a good thing, and in Android it can't be done at all.
Keep on clicking for more details on the different operating systems and how they — and you, the user — manage permissions. Thanks to Ojas Rege and Tomas Vetrovsky of MobileIron for providing invaluable consulting.
(All images by ZDNet/CBS Interactive Inc.)
Unlike the other operating systems here, iOS never asks permission at install time, nor does it list permissions information (at least not as a rule) in the Store. The App Store is smart enough not to offer an app that requires capabilities (e.g., a phone) that are not supported on the device on which the App Store app is running.
If you need to use a resource or perform an action for which iOS requires permission, iOS asks the user. The user can say no, in which case the functionality is either unavailable or works incorrectly. On a camera app I tested, when asked if I would give the app permission to use the camera, I said no. I was able to continue taking pictures, all of which were blank.
One area where iOS stands out against the competition is a unified interface in the system Settings app for managing permissions and other such settings for apps. Users can dynamically change the settings. As we'll see later, Android and Windows aren't quite as capable or polished.
Android deals with permissions up-front, and they are all disclosed on the Google Store page and, as shown here, at install time. The details on this list are expanded, so the user would have to scroll quite a distance to read them all.
As with iOS, the Android system Settings app has an Applications page where you can read all the settings, including those that require permissions. With iOS, the settings are changeable, but with Android you can only view them. The list for this app is long so I had to use two screens to show all the content.
If an app declares in its manifest that it needs a feature that requires permission, Windows Phone will notify the user at install time. As an example, the screen on the left on this page shows the HERE Drive+ app install which (obviously) requires location services.
Alternatively, when the app uses a feature that requires permission, Windows Phone will ask the user, as it does with location services in the Bank of America app on the right.
Consistently applied, a hybrid approach may be the best way. Perhaps apps should ask at install-time for permissions that are core to the purpose of the app, such as access to the camera for a camera app, but at run time on-demand for optional capabilities. The way Windows does it seems like the right approach to me, but the reasons why users sometimes get permissions at install time and not at others will be clear to very few users.
Windows 8.1 will sometimes just inform the user (in this case, in the Windows Store app) that it will be using a capability. For others it asks at run-time.
Apps in both Windows 8.1 (left) and Windows Phone 8 (right) can change their own permissions at run time. There is no central system UI for this as there is in iOS.