Introducing Web3 Permissions
We believe the blockchain ecosystem needs to fix its consent experience once and for all. The days of repeated confirmations to complete simple tasks in an application are officially numbered.
MetaMask was initially built to be good enough to make interfaces with, but we knew that some hard questions remained: How much consent is enough? How much education makes consent informed? How much trust should be extended to a new site or person? How important is it to nag users about each transaction, even when most transactions are completely indecipherable to the average user?
It turns out that our initial approach was good enough, but not ideal. It was safe, but annoying. It was functional, but clunky, and we are awed by what app developers have accomplished even with this rough platform.
In attempting to resolve these tensions, we realized we were not the first to consider them. We have taken inspiration from great thinkers in the UX of security like Mark Miller, as well as principles demonstrated by economics and sociology. Ultimately, we arrived at some basic and prescriptive insights about how to help people — and computers — take maximally secure risks:
- Trust is Risk, and trust cannot be avoided when interacting with the world.
- The most secure system is one that extends the fewest permissions, per the Principle of Least Authority (POLA).
- People know when they can trust each other, and we should enable deliberate trust at a user’s discretion, per social collateral.
Between the principle of least authority and social collateral, we find a sweet spot; we believe that the best way to build a secure yet extensible decentralized system is to permit the fewest possible external permissions by default, while allowing users to take informed risks at their discretion.
The MetaMask Permissions System
In the past, we considered features either secure or insecure. Insecure features were locked up behind a confirmation screen or not implemented. This led us to pass on some feature requests by developers, such as allowing unlimited signatures or transactions from a given domain, or letting dapps set a user’s gas price or nonce.
To support such features, we must stop treating security as a binary property. Instead, of “Is this feature secure or not?” we ask: “What risk is associated with this feature, and how can we request the user’s informed consent?”
Our answer is that the Ethereum provider API should incorporate a permissions request system. We’ve implemented a new permissions framework for use with a branch of MetaMask that works with a sample dapp using our new permissions API. The prototype we share here is roughly equivalent to a pre-authenticated version of OCAP-LD. It looks something like this:
The simplicity of this example belies what is happening under the surface. In this branch of MetaMask, some methods (“restricted methods”) will return authorization errors until permissions have been requested. Multiple permissions can be requested at the same time on the connect screen, creating a kind of “terms of use” enforced on the user’s device at their discretion.
We have built this permissions system so that new restricted methods can be added easily. In other words, securely extending the useful API surface of MetaMask becomes about as simple as writing the method and a clear description of it. We are actively researching which methods developers want the most.
Some possibilities we’re excited about:
- Letting sites include a signature challenge at sign-in time.
- Letting sites specify the network(s) they need to connect to.
- Letting sites decrypt messages on a user’s behalf.
- Letting sites send transactions on a user’s behalf.
If access to a permission is power, then security is the degree to which that power is limited. Consequently, the permissions system includes extensible caveat system, which enables users to adjust the permissions they grant at the time of login.
Consider:
- An adjustable log-out timer.
- Selecting the account(s) that a site can view.
- Signing messages, but only within a domain.
- Sending transactions but only to a specific recipient, and only within a specific limit.
Of course, the purpose of this is to empower users and developers, and we will continue to support existing transaction behavior for those who prefer that.
In the Future: True Object Capabilities
Today these permissions are stored within a table in MetaMask. However, if we cryptographically sign them with e.g. uPort’s verifiable claims framework, or Linked Data Signature, we could compose them into cryptographic object capabilities like OCAP-LD. This would enable sites to store their own permissions, delegate them to another domain, or even redeem them on another computer system, including the blockchain itself.
Since these permissions objects could include signed proofs, they can be extended to not only represent local permissions, but also on-chain permissions, and the metadata necessary to redeem that permission.
For example, an application might require permission to withdraw some number of tokens to start a game. Those tokens could be locked in any number of different ways on the blockchain, by e.g. the allowance() method, a signed MetaTransaction, or another type of MultiSig. The application developer should not need to be concerned how exactly the user is storing an asset. Rather, they should only have to know that the required permissions have been granted.
Join The Conversation
We’re excited to make our platform the most secure and extensible it can be, all because of the things we want to make possible for people like you.
So please, if this system sparks something in your imagination, check it out, think about what you would do, and let us know how we can help create the decentralized web that you want to see. Specifically, we want to know the permissions you want to exist, and what the API should look like. Again, try it all out using this branch of MetaMask and this sample dapp. If you want to dive into the technical details, you can check out the permissions module itself and our Ethereum Magicians post.
Finally, we’re hiring. If you like meta-programming, and securing the future of the web, throw us a line, and see if we’d be a good fit!
