Wallet is unable to present all the information required for signer to make a solid accept/reject decision. The WYSIWYS principle (WhatYouSee-is-WhatYouSign) is broken now.
We are unable to reach web2 (legacy) sites because they do not implement any web3 logic. This is one of reasons why we are trying to reinvent wheels like twitter and facebook from scratch.
The root cause is in the Dapp architecture we have adopted from very beginning. We inject web3 for transaction processing into the website (Dapp) which is inherently unsafe environment with very limited chances for audit. That is why we use now wallets for Tx verification, running in more secure environment than Dapps.
Dapp Architecture based on web3 injection doesn’t support wallets properly. Lets try re-invent it.
We can let Wallet present exact we would like to sign. Make WYSIWYS great again
Because we handle Tx processing in Wallet and not in the Dapp, we can reach legacy sites like twitter now. Not all, but many of them: we need create a control injector for that.
We need let wallets load and render small Dapps (let us call it Dapplets) depending on current context and action. A Dapplet containter will make necessary security checks and audit status. More over it will present more info about Tx and Dapplet in the Header and Footer for better security.
The need for auditing makes a new type of hudle of adoption. I am curious what do you think of adding a restricted presentation layer (that it doesn’t allow mangling the original data visually) to https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md instead?
Just off the top of my head… can we make it as easy as:
1.Dapp sends a call to Web3.dapplet({myDappletObj})
var myDappletObj = {
name: "MyDapp", //name of your dapp
url: "urlOfYourDapp", //url for your domain here for general registery
category: ERC20, //type of asset for display purposes
message: { //your dapp object to be displayed
asset_name: "My CryptoKitty", //optional
asset_image: "image.com", //optional
traits: [...] //optional
message: "Hello bob" //optional for any other types
...///any other fields for the category types supported
},
trasactionObj: {...txData} //pass in normal transaction data
}
Where myDappletObj contains information similar to what a transaction contains, except it has extra data feeding it the object of the dapplet. Given the use of ERCs, we can accept ERCs transfers, general info such as names, images, ERC-721 assets, or DAO type interactions. Where every interaction is generalized and you are feeding a standard 1 of X number of possible type of widgets into the wallet.
Wallet then displays what was given in a limited form, just as it does with a transaction now.
I think the important thing is that it be determinable what DApplet code was running at any given block. Perhaps the default is that DApplets are immutable and deployed at the same time as the contract itself?
I have slightly another angle of view:
While contract audit became usual and desired, the dapp audit is still not in focus. This is because of inherent trade-off between UX and Security. Most projects currently follow User expectations and prefer UX at expenses of Security.
I proposed to extract security sensitive parts of Dapps into Dapplets which are much smaller, utilize simple UI and can be executed in restricted environment. That makes Dapplet audit even possible.
Dapplet audit could become part of contract audit and will not create additional obstacle for adoption.
If some project doesn’t not provide an audit, it could implement all UI as usual in a solid Dapp and without any Dapplets.
Yes, it could be thought as presentation layer to EIP-712 although not instead, but as an additional layer.
I confirm, I need to think deeper about EIP-712, but currently I think, the EIP targets another problem: it creates unambiguously (injective) signatures, which can not be later interpreted as valid in another semantic context.
Yeah, It is a valuable input, thank you!
I have similar template based way of thinking about visual layer, but I would more strictly separate calculations from data. I would be interested in detailed discussion.
I would completely replace the txData with json object. It makes no sense to construct txData in less trusted environment like Dapp in browser and then try to recover corresponding meta-data from passed txData in Wallet. This architecture was introduces years ago because of convenience and simplicity but it doesn’t fit security requirements and should be deprecated, IMHO.
It should be the Wallet, who should be responsible to construct txData based on parameters passed or loaded from other trusted sources.
I don’t think it is necessary, but same-origin is a good security note.
I was imagining the DApplet being represented as a hash and loaded from IPFS. Wallet is directed to a certain smart contract, queries the contract to find the hash of the canonical DApplet, and then loads it.
Yes ofc the data can be pulled wallet side. Was just giving an example that we would include the bare minimum that is included now, plus the extra additional data.
My concern for requiring these dapplets to be hosted or related to the smart contract, is that, once a dapp is deployed, a new dapple may be wanted to be used.
Also dapplets for 721 assets and other non traditional assets most likely need information from off chain to be included within the information passed to the dapplet
Yes, but quering the smart contract is not the only one way to get a trusted dapplet. The trust for 3rd party dapplet can be established by audit, for example.
I would like to see Dapplet audit as the part of the usual contract audit.
Sounds like the gist of the idea is the website logic injection. Having wallet screens sounds orthogonal and might be useful in general, but also kind of complex to spec so that all wallet implementer can agree on.
Yeah, in PoC implementation we are going the same direction using JSX-like compoments.
Are you in Paris now? Would like to talk about more in details. May be we could join our efforts.
