Designing a permission system

Asking users to make security-oriented decisions is not always wise.  For instance, Android asks the user to accept (or not) the permissions granted to an application at installation time.  Recent studies highlighted that only 17% of users paid attention to permissions during the installation phase.
Felt et al. in the paper “How to ask for permission” defined four potential strategies to manage permissions:

  • The designer automatically grants permissions without involving the end user. This strategy is valid if the designer makes the good decision and if no application abuses the end user. In any case, the end user should be able to reverse the decision.
  • The designer integrates the decision process within the task that the end user fulfills, and that will require a new permission. This is what happens when the user decides which directories a friend may access, or has to push on a button to send a message. Usually, the end user is not even aware that he takes a security decision. The end user is not distracted from his primary goal: performing the task.The paper calls that Trusted UI (which I find misleading)
  • The designer opens a dialog box when a decision has to be taken. The end user is distracted from his primary goal. Therefore, these dialog boxes should be rare and restricted to decisions that would have severe adverse consequences.
  • The designer proposes at the installation to the user to select all permissions. Android applies this strategy.

For the two last scenarios, the user should be helped with explanations that will highlight the potential risks he takes when making the decision.

An ideal product would mix the four approaches.  The authors propose an implementation strategy summarized by the figure below.



The paper is

A.P. Felt, S. Egelman, M. Finifter, D. Akhawe, D. Wagner, and others, “How to Ask for Permission.,” HotSec, 2012 available at

Leave a Reply

Your email address will not be published. Required fields are marked *