{"action":"created","issue":{"url":"https://api.github.com/repos/ethereum/EIPs/issues/719","repository_url":"https://api.github.com/repos/ethereum/EIPs","labels_url":"https://api.github.com/repos/ethereum/EIPs/issues/719/labels{/name}","comments_url":"https://api.github.com/repos/ethereum/EIPs/issues/719/comments","events_url":"https://api.github.com/repos/ethereum/EIPs/issues/719/events","html_url":"https://github.com/ethereum/EIPs/issues/719","id":259698709,"number":719,"title":"Trustless Signing UI Protocol","user":{"login":"MicahZoltu","id":886059,"avatar_url":"https://avatars2.githubusercontent.com/u/886059?v=4","gravatar_id":"","url":"https://api.github.com/users/MicahZoltu","html_url":"https://github.com/MicahZoltu","followers_url":"https://api.github.com/users/MicahZoltu/followers","following_url":"https://api.github.com/users/MicahZoltu/following{/other_user}","gists_url":"https://api.github.com/users/MicahZoltu/gists{/gist_id}","starred_url":"https://api.github.com/users/MicahZoltu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MicahZoltu/subscriptions","organizations_url":"https://api.github.com/users/MicahZoltu/orgs","repos_url":"https://api.github.com/users/MicahZoltu/repos","events_url":"https://api.github.com/users/MicahZoltu/events{/privacy}","received_events_url":"https://api.github.com/users/MicahZoltu/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":33,"created_at":"2017-09-22T04:18:34Z","updated_at":"2018-03-23T21:03:44Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"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.\r\n\r\nAn 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 the contract that will eventually review the signature can verify that the user was presented with an appropriate UI to make an informed decision as to what they were signing.\r\n\r\nThe 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, after prompting the user with the information presented as described in the DSL, would then sign the data along with a hash of the DSL used for presentation.  The contract that wants to verify the user was properly informed would verify that the signature is of the supplied parameters plus a hash of the DSL (which is baked into the contract).\r\n\r\nThis is quite similar to #712, though it strives to take things a step further than just function name and parameters.\r\n\r\nAs 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\r\n```\r\nI would like to create an order offering ${amountA} ${tokenA.name()} tokens in exchange for ${amountB} ${tokenB.name()} tokens.\r\n```\r\nAn untrusted dApp would send that DSL (exactly) to the signer along with the variables `amount`, `token` and `destination`.  The signer would then do an `eth_call` to fetch the `name` parameter from the token and 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.\r\n\r\nAnother 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 contract could assert that the the signer should present the user with a basic UI to present the data to the user like the 0x OTC dApp: \r\n![image](https://user-images.githubusercontent.com/886059/30728433-077329da-9f0d-11e7-80f4-e201230bfd44.png)\r\n\r\nFor 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.\r\n\r\nThe obvious disadvantage to the full UI DSL is that it can't reasonably be rendered on a text-only display like a watch or hardware key.  One option would be to have the solution _require_ a madlibs style UI (which can render anywhere) and allow contracts to _optionally_ include a GUI.  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.\r\n\r\nOpen Questions:\r\n* What is does the madlibs DSL look like?\r\n* What does the GUI DSL look like?\r\n* Are the benefits of a GUI DSL over a madlibs DSL worth the additional implementation costs on signing tools?\r\n* Are there existing DSLs that would give us broad support out of the box (e.g., HTML)?\r\n* Should the EIP provide recommendations on mutability of the signing UI (any mutability of the signing UI introduces a new attack vector, but immutable signing UIs means no UI improvements after user feedback).\r\n* What datatypes should the signing UI DSL support?\r\n  * timestamp: could present users with a date/time picker on click\r\n  * counter: could have an up-down clicker\r\n  * range: could have a range slider with tick DSL defined tick size\r\n  * others?"},"comment":{"url":"https://api.github.com/repos/ethereum/EIPs/issues/comments/375797765","html_url":"https://github.com/ethereum/EIPs/issues/719#issuecomment-375797765","issue_url":"https://api.github.com/repos/ethereum/EIPs/issues/719","id":375797765,"user":{"login":"dpyro","id":297124,"avatar_url":"https://avatars3.githubusercontent.com/u/297124?v=4","gravatar_id":"","url":"https://api.github.com/users/dpyro","html_url":"https://github.com/dpyro","followers_url":"https://api.github.com/users/dpyro/followers","following_url":"https://api.github.com/users/dpyro/following{/other_user}","gists_url":"https://api.github.com/users/dpyro/gists{/gist_id}","starred_url":"https://api.github.com/users/dpyro/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dpyro/subscriptions","organizations_url":"https://api.github.com/users/dpyro/orgs","repos_url":"https://api.github.com/users/dpyro/repos","events_url":"https://api.github.com/users/dpyro/events{/privacy}","received_events_url":"https://api.github.com/users/dpyro/received_events","type":"User","site_admin":false},"created_at":"2018-03-23T21:03:44Z","updated_at":"2018-03-23T21:03:44Z","author_association":"NONE","body":"> The goal of this proposal is specifically scoped to solving the untrusted dapp UI + trusted contract problem.\r\n\r\nIf I understand correctly, this EIP is so the signer can use the contract to verify the UI presented to the user is whitelisted. So far I only see these methods for a contract verify this using a rich UI:\r\n\r\n- Verify the UI against hardcoded hashes deployed with the smart contract. The obvious drawback is that new UI revisions cannot be used until a new smart contract is deployed. It's probably not useable for a rich UI which needs handle additional issues such as localization and an ever-growing list of legalese disclaimers and phishing warnings that current dapps need to maintain.\r\n- Verify the UI against an adminstrator-only updated list maintained by the smart contract. This allows the UI to be revised and more UIs to be added without deploying a new smart contract. However, the administrator of the smart contract needs to also be both a trusted and continuously active party. This also puts the administrator in a targeted position since they are now the weakest link in the trust chain.\r\n- Delegate UI verification to another smart contract (such as a DAO). I honestly don't know the implications of this one.\r\n\r\nI don't think verifying the authenticity and integrity of a rich UI can be done in any single proposal. A tractable base for transactions is a standardized method for signers to query a smart contract for a human readable string of the main call. For example, a contract that contains:\r\n\r\n```solidity\r\ntransfer(uint256 amount, address destination)\r\n```\r\n\r\n**may** also have (if the plaintext of the method is available)\r\n\r\n```solidity\r\ntransferAsString(uint256 amount, address destination, string lang) public view returns (string)\r\n```\r\n\r\nor (if the plaintext of the method is not available)\r\n\r\n```solidity\r\nasString(uint256 funcSelector, bytes parameters) public view returns (string)\r\n```\r\n\r\n(I'm almost certain there's a better way to do this!)\r\n\r\nWhich can return\r\n\r\n```\r\nYou are transferring 15 ABC tokens to MicahZoltu.eth.\r\n```\r\n\r\nThis also permits someone who is examining verified contract source code to easily verify the generated string is not malicious."}}
{"actor":{"display_login":"dpyro"}}