opened 04:18AM - 22 Sep 17 UTC
closed 12:43AM - 16 Jan 22 UTC
stale
A lot of debate has been happening around how we can make signing a more secure … process for end users. One of the common arguments is that while all of the proposed solutions may resolve the problem for advanced users (developers, tech savvy users, professionals, etc.) it doesn't address the problem of naive users not understanding what they are signing. They can often be thought of as the legalese presented to people in contracts: it is better than signing a blank sheet of paper, but to the average person its mostly gibberish.
An idea that @Arachnid and I started batting around in an attempt to come up with a long-term solution to this problem is to provide a mechanism by which things can be signed (ideally transactions and arbitrary messages) such that signer can present the user with informed consent without having to trust the UI.
The general premise is that the actor wanting a signature presents the signing tool with the data they want signed as well as a DSL that describes how the data should be presented to the user. The signer would then ask the target contract if the DSL is valid, and only prompt the user to sign if the contract asserts that the DSL is in fact valid.
This is quite similar to #712, though it strives to take things a step further than just function name and parameters.
As far as the DSL itself goes, one option would be a text-only DSL that allows for replacement variables. An example DSL may be something like
```
I would like to create an order offering ${data[0,64] as number} ${(data[64,64] as contract).name()} tokens in exchange for ${data[128,64] as number} ${(data[192,64] as contract).name()} tokens.
```
An untrusted dApp would send that DSL (exactly) to the signer along with the transaction they want signed. The signer would then ask the `transaction.to` contract whether the hash of the DSL is an approved DSL. If it is, then the signer would extract data from the `transaction.data` and do an `eth_call` to fetch the `name()` of the two contracts (tokens in this example) and finally generate the string to present to the user. This solution is very simple and allows for devices with small screens that can only present text (e.g., Ledger) to be able to reasonably present the user with information that the contract author has deemed as enough for informed consent.
Another more feature rich solution (in the extreme) would be to allow the DSL to be some form of constrained layout engine markup (e.g., HTML). The idea here would be that the signer could verify the DSL was approved just like with the text DSL, but would be able to use a basic UI to present the data to the user like the 0x OTC dApp:
For complex contracts, a full UI is much more understandable to an end user than a paragraph or two of madlibs text, and it gives the dApp developer the ability to create a generally better user experience.
The obvious disadvantage to the full GUI DSL is that it can't reasonably be rendered on a text-only display like a watch or hardware key. With the way this is proposed, a contract could support multiple DSLs so a well written contract may support both text only DSL (for small screens and screen readers) and also a GUI DSL for a better user experience for most users. This would allow dApp developers to provide high quality signing experiences to users on devices that support it with graceful degradation on devices that don't. It also allows signers to implement the presumably easier-to-implement madlibs spec fist, then expand towards the full GUI support implementation later.
Open Questions:
* What is does the madlibs DSL look like?
* What does the GUI DSL look like?
* Are the benefits of a GUI DSL over a madlibs DSL worth the additional implementation costs on signing tools?
* Are there existing DSLs that would give us broad support out of the box (e.g., HTML)?
* What datatypes should the signing UI DSL support?
* timestamp: could present users with a date/time picker on click
* counter: could have an up-down clicker
* range: could have a range slider with tick DSL defined tick size
* others?
If the DSL hash is signed over (function parameter), then a fully offline hardware wallet can trustlessly present the human readable transaction to you.
2 Likes