I am unsure whether I like the permission idea in general and the permission “send the transaction on your behalf” in particular. Users may be so careless giving permissions… I have a bad feeling re-implementing the usual permission paradigm once more.
I agree there are scary permissions we could add, and sending transactions is among the top, and so I’m not actually including any transaction sending permission as part of this proposal. That said, I will still defend the possibility of that permission, because I think it’s an important point.
Even today’s “prompt on every transaction” model relies on users mostly trusting the sites they visit, as most transactions are of unknown types, and are hard for wallets to represent to users.
For that reason, I think a properly designed permissions system will do a few things to improve the situation:
- Wallets should make dangerous permissions look dangerous. This isn’t an excuse to get users to click blindly. This is a time to rebuild the user’s sense of responsibility.
- Wallets should expose permissions that are meaningful to users. A token allowance is meaningful, but a hex blob is not. If we can identify the terms that convey the true risk a user is taking, I believe we can allow the risks a user takes to be much more comprehensible to them, which allows them to participate in informed consent. We cannot stop users from being reckless, but we can empower them to be careful with fewer steps.
- Wallets should allow users to attenuate permissions (add caveats), or reduce their impact when possible. An app may request a login, but the user may say “Just for the next 30 minutes”.
I imagine you might be thinking about your Dapplet proposal as an alternative security measure, but I think it actually could work better together: While we want to render transactions more coherently, there is a hard question about who you would trust to design your transaction approvals, so why not make “permission to render confirmations” a permission?
In Dapplets, you suggest a registry, and that the registry could have auditors, and I would suggest that this has moved the goal post, and now the concern is “who are the auditors?”. Rather than prescribe an imperfect solution, we could also just ask the user if they trust a given source for information.
I wish I could keep users safe by restricting functionality, but ultimately users will do extreme things to use applications if it isn’t easy. They’ll just trust the site to make a wallet for them, and they’ll fund it, or paste in a seed phrase. Rather than refuse to implement potentially dangerous APIs, I think it’s important for wallet developers to ask what APIs allow users to take the risks they want to make, as coherently as possible?