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
