Permissions Scientific Way

If we put together everybody's 2 cents about improvement of iOS permissions from both visual and logical perspective, it would be huge pile of money. My 2 cents included. However, some people actually did some hard work to figure out how good is the current approach and what could be done to improve it.

University of California, Berkeley has Securtiy Research Lab, and that lab runs Smartphone Security project. These gals and guys took problem very seriously and made very interesting publication titled "The Effectiveness of Application Permissions" (don't be repelled by its dull scientific formatting). Key part is analysis of permissions of almost thousand Android applications and thousand Chrome plugins, trying to discover how permissions are used in the real world. I'll stick to the Android part.

For non-Android readers: Android has two groups of permissions: dangerous and normal. In short, permissions that could invade privacy or incur cost are considered "dangerous". These permissions are listed before installation; user must explicitly confirm them. Normal permissions groups are collapsed under "Show all" button and not normally displayed. Confirmation dialog shows permissions groups in large font and lists exact permissions in small font.

Some interesting findings

• On average, applications use just 4 dangerous permissions out of 56.
• Huge number of applications asks for "dangerous" Network.Internet permission. It is dangerous because it is not clear why application asks for Internet access.
• Combination of permissions indicate that free applications need them for advertisement.
• Recommendation that user shouldn't grant permissions to both Internet access and private data is not enforceable due to large number of applications needing Internet access.
• Improper granularity and threat level of some permissions forces authors to ask for larger number of dangerous permissions.

There is lot more in the paper. Do read it!

Fixing permission-based security

Knowing permission upfront is a good thing; it helps reviewers (be it app store or user) to focus on dangerous stuff. First step is preparation: create sensible list of dangerous rights. Split some dangerous rights into non-dangerous and dangerous ones so application can opt for non-dangerous, if possible. More appropriate threat levels and finer granulation of permissions (e.g. Internet access to single URL of well-known ad-provider) will considerably reduce number of requested dangerous permissions.

Verification process:

1. Create a list of rights needed by application (either provided manually by developers or automatically, according to the APIs usage).
2. Review applications that use dangerous rights. Here is hidden incentive for using less dangerous rights: faster review process. 
3. Enforce run-time checks against list of rights during execution of application.

I'm happy with that; I think that any systems that relies on humans is inherently unreliable. Next point proces that:

One of the big issue with install-time grant is that users just click OK. Alerting systems that will force users to stop and thinks is not yet invented.

Where are we now?

Android lacks code reviews, while iOS lacks permission lists. Google should change market publishing process, while Apple should change development tools, application packaging format and iOS. It will be interesting to see which company will manage to introduce whole process, within which time-frame, and at what cost.