How to Ask For Permission

[agostbiro]

Hi folks,

I wanted to start a discussion around a permission UX framework that I really like. It's described in the paper, How to Ask For Permission by Porter Felt et al.

The gist of it is to minimize the information load on the user and eliminate upfront permissions and warnings whenever possible by replacing them with automatic grants and trusted UIs or context-specific confirmation dialogs:

Upfront permissions are not great, because

1. If all permissions have to be listed upfront, it's too much information and users just ignore them like EULAs.
2. The user doesn't really know if the application really needs those permissions before actually using the app.
3. Developers are likely to ask for more permissions than the app needs if they have to list all the permissions upfront as opposed to requesting them in the code for a specific feature.

Similarly, too many warnings are not great, because if most apps come with warnings, then users just start ignoring them. This used to be a big problem on Android.

I think iOS comes closest to the system described in the paper and their docs are very helpful too:

Request permission only when your app clearly needs access to the data or resource. It’s natural for people to be suspicious of a request for personal information or access to a device capability, especially if there’s no obvious need for it. Ideally, wait to request permission until people actually use an app feature that requires access. For example, you can use the location button to give people a way to share their location after they indicate interest in a feature that needs that information.

Avoid requesting permission at launch unless the data or resource is required for your app to function. People are less likely to be bothered by a launch-time request when it’s obvious why you’re making it. For example, people understand that a navigation app needs access to their location before they can benefit from it.

---

Finally, I think this permission UX framework aligns well with the principles set out by @depatchedmode :

Easy & Obvious: Most vulnerabilities in a system occur when we find insecure workarounds, so the secure path must be the easiest and most obvious path for us to take.

It's easy for developers to ask for minimal permissions and difficult for users to grant too wide permissions. ✅

Maximally De-risked: It is not realistic to expect us to be experts in keeping things secure. Therefore, systems must take the responsibility to reduce our risk by default as much as possible.

Users are only prompted to make decisions that they're qualified to make (e.g. let Uber use my location when I'm ordering a car). ✅

Just Granular Enough: We should have control over what we permit other systems, individuals, and organizations to see and do with our data. However, this control should not be so granular that it becomes overwhelming and burdensome for us to set up and maintain.

It's a good balance between granularity and not being too annoying. ✅

Sufficiently Legible: Informed consent is critical. We must be able to understand the actions and outcomes before we take those actions. Actors and objects in the system should also be labeled clearly and in a way that we can quickly understand.

Making permissions contextual and one at a time achieves this. ✅

Sufficiently Auditable: Mistakes will be made. All actions taken on our data should be auditable & reversible. All permissions we delegate should be revokable. Parts of our history should be ejectable.

In this system apps have to be designed to work with minimal permissions and gradually request more, so users can revoke permissions and still use the app. ✅

Aware Things Change: Nothing is forever. Our circumstances may change; the world may change. We need optionality to move our data, adjust our threat models, and rotate our security factors.

Revocability achieves this in the context of permissions. ✅

Reflective of My Intentions: Most critically, the system must still enable us do what we intend to do. It must allow us to present ourselves to the world in the many ways we desire or need to be presented.

Again, making permissions contextual and one at a time achieves this. ✅

[maurerbot]

This is an big interest of mine.

Do you know what the latest research on this topic? I ask because this paper and the sources seem to be around right after the first iPhone was released (2007) and at the same time the OAuth protocol was published (2011/2012).

Since then we've seen Apple become a big proponent of permissions and privacy when it comes to mobile and has even taken OAuth to the extremes when it comes to generating secrets for web apps.

In any case we're seeing more and more "progressive authorization" being used throughout a user journey to limit what you're asking from the user until you need it. If there is any newer research on this practice that would be useful for this discussion.

[agostbiro]

Great question! I'm not aware of newer research on progressive authorization, but I'm not well-versed in the literature. There are a bunch of papers though comparing iOS and Android permissions and on the effectiveness of warnings. Hopefully someone else can chime in on this.

Can you share more about how Apple does progressive permissions with OAuth? I'm not familiar with Sign-in w/ Apple, but it sounds very interesting.

[maurerbot]

OAuth is used for "sign in with Apple" use cases (specifically on the web but can be used on mobile too). Developers can request new scopes for new access tokens further down the user journey in their applications as needed. I don't think Apple has more scopes then "email" right now but other services do (e.g. Google, Github, Rollup)

The way progressive authz works is, as a dev, I can as you for your email address at registration time and then ask for your location information down stream when I need it.

[depatchedmode]

Welcome @maurerbot 👋 Sounds like you'd definitely be interested in taking a look at UCAN and CACAO as well as the ReCap proposal for how to construct a standard message payload and trusted UI in the wallet client.

Anybody happen to know Adrienne? If not, I'll reach out to her to see if she's got bandwidth to join the discussion or at least point us to the latest research into Progressive AuthZ in general.

[salieflewis]

Been trying to think about this in the context of SIWE. But to be fair my knowledge of SIWE is primitive at best. Can anyone present some examples of when SIWE is useful and then potentially how this relates to it? Anecdotal evidence would be great.

The pattern is always, connect, then SIWE. But if we're following the principles laid out above, that signature step probably lives deeper in the flow.

[depatchedmode]

@salieflewis I definitely have some thoughts about this as it relates SIWE and ReCap (the AuthZ extension to SIWE). Right now, the proposal as I understand it is to bundle ReCap into the initial SIWE dialogue and have all permissions listed and granted up front. There is no provision for progressively asking for permissions as they become relevant, or adjusting them post facto, without going through the full SIWE dialog again and adjusting the whole bundle of permissions.

Our approach takes the unique requirements and constraints of each permission into account. This is a departure from existing platforms, which have applied a single permission-granting mechanism to all permissions.

For the reasons laid out in this paper / presentation, I think that tight coupling ReCap to SIWE severely limits its effectiveness. I think we have an opportunity to leap-frog mobile OS permission systems instead of just replaying history.

I raised these concerns to the ReCap folks a few months ago and they were pretty open to it. Gonna see if I could get them to join and help direct our efforts in improving the proposal.

• ReCap Spec: https://github.com/spruceid/siwe-recap
• ReCap blogpost: https://blog.spruceid.com/extending-sign-in-with-ethereum-to-authorizations-recap/

[salieflewis]

Not familiar with ReCap at all, so thanks for shedding light on this. I'll read up on the links you sent to get a better understanding.

[depatchedmode]

This is an excellent discussion, thank you very much @agostbiro for kicking it off. Apologies for being slow to get to this; wanted to come to it with my full attention. Would love to dedicate the next community call to this topic, actually. Going to schedule time and send out the invite this afternoon.

For anyone lurking this thread that's a bit more audio/visual, found a presentation from Adrienne on the paper: https://www.usenix.org/conference/hotsec12/workshop-program/presentation/felt

Progressive Authorization is a great place for us to start focusing on heuristics & patterns.

Some things I think are worth revisiting / challenging in this paper — mostly focused on The Guide:

• Severity and revertibility should switch places. I suspect there may be different decision trees for the lowest severity things than for the highest severity things. And because severity is a complex spectrum, I think there's a very wide-band grey area between those extremes.
• What do we actually mean by "severity"?
• revertibility and alterability seem almost identical. In what ways are they meaningfully different?
• "Trusted UI" in the wallet client space is still really under explored, particularly in terms of conventions that all wallet clients share. SIWE & ReCap are helping to break ground here. Would be great to lean into this more (eg. Choosers for ERC-721/1155's)
• Terminology feels a little unclear or dated. I know "Trusted UI" is a reasonably understood term in the academic arena, but "Trusted UI", "Confirmation Dialogue" and "Install-time Warning" all feel insufficient to explain the application landscape that exists today. Would be great to try and refresh the terminology here.
• In the blockchain space, who are the "Platform Designers"? Specifically as it relates to this line:

  Platform designers should not enable multiple mechanisms for the same permission without carefully considering developer incentives.

• An area where mobile OS's still lack is auditing / reviewing granted permissions. As the world changes, and as I change, there are probably changes to my definition of what is still "low severity" and it'd be great to have something to help me do a bit of permissions housekeeping.

[agostbiro]

Thanks for setting up the next call @depatchedmode . You raised some very good points here and I'm looking forward to the discussion. Some random thoughts:

We definitely need to adopt much of the terminology to better fit a decentralized web setting.

On the trusted UI side spender approval dialogs would be interesting to discuss as well.

Re revertibility vs alterability: I think "interactivity" may be a better term than "alterability".

Consider the case of taking a photo in an application. The application could prompt the user to give it access to the device's camera and then get access to the camera from the OS after which the user takes the photo in some custom application UI. But a better solution is for the operating system to provide a trusted UI that the user can open from the app and use that to take a photo. This way the permission grant is implicit as the user carries out the action and it's always the same UI so users know what's going on.

In the photo case the action is not revertible imo, as the app could've uploaded the image to a server before the user could undo the action, but it is interactive.

An example where the action is revertible, but not interactive could be enabling roaming data. It can be switched off any time, but it's just a yes/no question, not a task where the user influences the outcome.