Hello Adrienne - Thanks for the good thoughts. I think we all 100% agree that installation time is the wrong time to ask. I'm wondering about your thoughts on asking for all permissions at the same time (in a list, with the option to selectively allow different permissions) or as they are used? The former seems less obtrusive, since the user is only interrupted once, but tends to lead to users just approving everything without thinking about each permission. I guess part of the decision will be how many permissions we expect any specific application to need. If it is one or two (like geolocation and contacts), as you go would be okay. If it is more than two or three, getting multiple requests is going to be too intrusive. The idea that some permissions are implicitly provided (based on a previous decision or some heuristics) is part of the plan. But we may still want to enumerate the permissions in a permissions manager application so a user can see what things an app is using and explicitly turn them on or off even if they are enabled or disabled by default. I agree that framing things in terms of explicit risks is a good idea, but can we always say what they are? Letting an application know your IMEI can certainly be used to "track you across applications" is one risk, but an app could also use it for other nefarious uses. And there are reasons where granting IMEI is legitimate. Trying to come up with the right messages might be impossible. On the idea that permissions should be built into the user's natural flow, I agree. I think it goes further. If we can determine that a user explicitly took an action to perform a task, we can assume they have implicitly given permission. If a user presses a shutter button to take a picture with the camera, they are implicitly giving permission to use the camera. Likewise, if a user enters credentials for Facebook, we can assume they want to post to their Facebook wall. Whether we can do this at all or in some cases for web applications, I don't know yet. I like the idea of auditing. I'm not sure what you mean by when a specific permission is actually used, but the idea of giving the user a sense of how often an application is using the permission is certainly possible and could be shown in a permissions manager. -Jim Straus
On Mar 6, 2012, at 9:28 PM, Adrienne Porter Felt wrote: > Thanks for the pointer, Fabrice. > > I've been studying Chrome extension & Android app permissions; some of those > results are relevant to this discussion. Links to the full papers are below. > Here are some of the main lessons and recommendations from those studies: > > -- Permissions significantly limit the severity of Chrome extension > vulnerabilities. I therefore think that manifest-based permissions would be > a *very* valuable addition to a new web app platform. If a web app is owned > (e.g., an XSS bug), at least the permissions would limit the attack to a > subset of the API. This doesn't necessarily mean that permissions have to be > shown to the user the first time s/he visits a web app: the upfront > permissions could act as a maximum bound on the number of runtime permissions > that the web app can get. > > -- Installation is the wrong time to ask about most permissions. People > don't have enough information to decide, and we find that many people assume > they will be asked again at runtime before the actions actually occur. > > -- A permission system does not need to prompt every user about everything. > For example, there is relatively little risk attached to letting an app turn > your Bluetooth on or off. People have finite attention spans, and every > additional warning devalues the permission system. People should only be > asked about things that have very clear, definite risks. The system should > support a separate "paranoid mode" where people can voluntarily enable more > warnings. > > -- Developers tend to think in terms of actions and resources, but people > have a hard time connecting actions and resources to risks. Any warnings > should be framed in terms of concrete risks. For example, "read phone state > and identity" talks about resources but "track you across applications" > refers to the risk of letting an application know your IMEI. > > -- Whenever possible, permissions should be built in to the user's natural > system flow to avoid the need for permission dialogs. For example, there are > three possible ways for a web app to send a text message: (1) it asks for > permission via a dialog and then directly sends a text message, (2) it uses > WebIntents to point the user to a trusted platform text messaging system, or > (3) the platform provides a trusted "send SMS" that a web app can embed > somewhere in its UI. Options #2 and #3 are highly preferable to option #1 > because it doesn't interrupt the user to ask for permission; instead, we just > implicitly know that the user wants to send an SMS message. As many things > should be built using #2 and #3 as possible. Some apps may need to use > approach #1; however, support for that should be added later (when it is > requested by enough developers) to avoid everyone using that "shortcut." > (Android provides options #1 and #2, and a lot of developers unnecessarily > use #1.) > > -- Auditing. Once a user has granted a permission, users should be able to > see when they are actually used. > > -- If a user is shown an Always/Once/No permission dialog, there should be > some context for the "Always" option so the user knows what that will entail. > Is this app going to send 1 text message, or 30,000? Matt Finfiter & Dev > Akhawe suggested something interesting: collect statistics on how permissions > are used in aggregate (e.g., how often) and present the statistics as an > optionally-visible part of the dialog. > > Cheers, > Adrienne > > --------------------- > Papers: > > An Evaluation of the Google Chrome Extension Security Architecture > http://www.eecs.berkeley.edu/~afelt/extensionvulnerabilities.pdf > Found vulnerabilities in Chrome extensions; Section 6 discusses the impact of > permissions on the scope of the vulnerabilities. > > Android Permissions: User Attention, Comprehension, and Behavior > http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-26.pdf > Did two user studies to see whether people pay attention to, understand, or > act on permissions. Most interesting results relate to comprehension. > Section 7 summarizes the results and provides a set of concrete > recommendations for improving permissions. > > Android Permissions Demystified > http://www.cs.berkeley.edu/~afelt/android_permissions.pdf > Looked at how well developers use Android permissions and the types of > mistakes they make. Section 6 presents the results (the rest of the paper > talks about the tool). > > Also, Franzi Roesner has a paper talking about how to embed permission > widgets into UIs to avoid the need for permission dialogs: > http://research.microsoft.com/pubs/152495/user-driven-access-control-nov2011.pdf _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
