Ideal Permissions UX

[depatchedmode]

In #5 we discussed the need for more ideal permissions flows. During the presentation of ReCap, the review of How To Ask Permission, and the rich discussion that occurred in between, a few proposals for "bluesky" permissions flows came up.

We agreed at the end of the call to start prototyping these, and review them on the next call to try and assess how they succeed, and what technical roadblocks they may be impeded by.

Things we want to consider:

• importance contextual & progressive permissions: let's only ask people for permission when its relevant to their task at hand, and they have enough context to understand the request
• challenges with revocation, and creating a permissions management view
• the educational responsibilities in achieving informed consent & making the impacts of selective disclosure clear
• tension between increasing friction to aid safety & security vs decreasing friction to support task completion: see Antonela's anecdote about increase in the number of rejected transactions when they added warnings in Metamask.

An initial list of things to prototype or diagram:

• bespoke wallet UI for presenting ReCaps
• permissions management screen: "would you like to switch your trust level from ‘low’ to ‘medium’? you can always change it later under settings > permissions"
• permission revocation screens: how would these look different? What promise can actually be made? Probably would benefit from very thoughtful copywriting.
• updated version of the How To Ask Permission decision tree
• granting permissions in browser from a session key: to what degree is a browser a trusted UI?
• gamifying selective disclosure: eg. "Sharing your b-day takes 8 points off your disclosure score"

[depatchedmode]

I've got a first rough draft of a "How To Ask Permission" decision tree. Realized part way into it that there are at least two separate audiences for this: System Designers and Application Designers. System Designers are working on the protocol or operating system, and are establishing the ground rules and constraints for how permissions should be addressed. And then Application Designers play within those constraints.

Original:

Updated:

Lots has changed in the ~10 years since that initial decision tree was produced. In the present moment I think that the mobile OS's are doing a lot more to de-risk the system up front, and make it so that there is mostly only one mechanism to use for any given permission. Then there are a number of guidelines that suggest appropriate tactics for Application Designers to follow, given their specific context and need.

Next step for this decision tree, I think, is to consider more specifically how this applies to the blockchain space and wallet clients specifically — as they are somewhere between System and Application. But first I'm gonna switch gears and work on some ReCap UI flows.

[agostbiro]

Love this! One thing I'd maybe expand on is the consent dialogue. How much information should it contain? Can multiple permissions be requested in one consent dialog?

[depatchedmode]

Yeah I think best practices on bundling are the next thing to explore. The default should be one thing at a time, but I'm sure there are valid reasons to bundle authorizations. Is that determination made by the end-user preferences? The application needs? System context? All of the above?

Hoping to find some time this afternoon to sketch a ReCap example of this.

[agostbiro]

Cheers! For me the consent dialogue should be approached from the perspective of the end user. Are they going to understand what's presented there?

[depatchedmode]

Feedback from today's community call:

1. Where do default permissions fit in? This decision tree focuses on contextual permissions, and assumes an implicit set of default permissions. How might something like the onboarding process to the system itself establish a set of default permissions, which may or may not need to be overridden later by an application.
   • eg. in Tor browser you set your default browser settings
   • the onboarding process promotes the benefits of strict to your privacy & security
   • the strictness you set for those defaults may break a website you wanted frequently visit
   • this causes people to relax their global defaults, again decreasing their security & privacy
   • really they may have wanted to make an exception permanently, or one time, for this site
2. Where do delegated actors fit in? When it comes to things like Account Abstraction, or Fission Accounts, there will be a need and desire to delegate trust to 3rd parties. How do those acts of delegation fit into this flow? eg. Via account abstraction I delegate to a paymaster
3. Consent dialogue timing: is it showing up too late in this flow?
4. Could it be better organized by trust level? The first instinct was to delineate responsibility by system vs application. Perhaps a better, or complimentary way, to delineate responsibility would be by the level of trust the authorizer has in the authorizee. (Additional thought: does it matter if we're at the root of the delegation vs further down a sub-delegation chain?)

Next steps:

1. Simple test: Test this current decision tree using a CAIP-25 / EIP-6963 flavoured wallet connection flow, to see if it feels like it delivers the correct result.
2. Restructure: Identify where to place defaults and delegation / how to relabel system vs application to better represent the recursive nature of trust and authorization in a decentralized ecosystem. In a typical web3 dApp, the systems at play will be: a wallet client (eg. MetaMask or Coinbase Wallet), a browser (eg. Brave or Safari), a blockchain network (eg. Ethereum or Solana) and perhaps even a storage/identity provider (eg. Fission or Ceramic).