Is frictionless Ethereum (and dApp) usage possible?
“In user experience, friction is defined as interactions that inhibit people from intuitively and painlessly achieving their goals within a digital interface. Friction is a major problem because it leads to bouncing, reduces conversions, and frustrates would-be customers to the point of abandoning their tasks” -Victoria Young
We have a friction problem in Ethereum.
The user experience for dApps that average digital service users expect is the simplicity of accessing a Google service — almost invisible to them; or they grow frustrated quickly and move on to the next thing they wanted to do — which is usually quite far from that of creating an cryptographic identity, signing up to a cryptocurrency exchange, downloading a browser plugin, install an app, a dApp browser, remembering passphrases or printing paper wallets and so forth.
There are good reasons for asking users to do these things and the products made to enable these are excellent (MetaMask, Parity Browser, Mist, etc.) , but you have to wonder if they’re a needed friction for the majority of Ethereum use cases? This is what this post tries to explore. There may very well be some ideas you think are terrible or misunderstood in here, if so, please do comment.
How do centralized services accomplish frictionless interaction then?
Why can’t the dApps experience be as frictionless as websites leveraging Google’s identity offering? Let’s try first to understand how that model roughly works: the user logs in using Google’s login form once; and an authentication token is stored on the device inside the browser, probably HTML5 local storage, that henceforth, until logged out or forcibly logged out by another logged-in session, is provided instead of our credentials to Google.
That authentication token is then only accessible to the particular Google account site that stored it. That is, nytimes.com or another random website cannot access that authentication token directly, but Google account based websites can leverage that identity as through messaging with the Google account website’s context.
If a device with the browser where the user has logged into Google with is stolen, the user can try to lock out that browser from acting with the Google identity through another logged-in session on another device.
Your immediate reaction to this analogy is probably that Google doesn’t handle your money or huge valuable assets and hence it can get away with this model.
Yet, for many use cases, this is secure enough. You handle different need of security for different scenarios in practice. An extra PIN/password or 2FA is utilised when payment to buy something on Play Store, as an example of this — not PIN up front for each use.
Frictionless Visa cards payments
To understand this model a bit further, let’s go to the money world for a bit. I have a Visa debit card with PayWave, you know, the contactless payment capability. There’s a limit by which it will not ask my PIN code — when the charge is below 15 USD.
Initially, the thought that if somebody had my card they could make payments easily without my PIN, terrified me. Until I tried how frictionless the experience of payment was.
I can literally drop my groceries on the counter in the shop and less than 15 seconds later, walk out with them all paid up.
A few years back, I had my contactless card stolen, but I was able to quite quickly get it blocked as a means to access my account. If you have your laptop, tablet or phone stolen today, you likely notice it quite quickly as well, though that’s not always guaranteed. And even so, having a PIN on your tablet or phone is quite normal practice today.
Similarly, Google’s security model as presented above wouldn’t be strong enough to protect my life savings of ETH. But it would be enough for handling micropayments, storage of documents or random tokens.
How do we do this in a Google-less, decentralised way?
I’ve approached this in a small proof of concept. “Zipper Vault” and an example Wallet (demo here) being one of the websites utilising it.
One of the better things to come out of Bitcoin is BIP32 or Hierarchical Deterministic wallets. The general idea is that using an initial seed, you can generate ‘wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins’, essentially a tree of keypairs from a single seed.
You might already say that today, there’s web wallets that create and store the key in a browser’s local storage and this is nothing new. That’s fine, but what if we could abstract key storage out of a web wallet and provide each website with its own tree of key pairs; where the root seed is as transportable as a HD wallet, but where each website wouldn’t have access to the root seed or knowledge of any details regarding it?
The puzzle piece making this happen is that of BIP39. While used protect your coins with a passphrase as well; because when you combine a mnemonic with a passphrase, you get a unique (and valid) seed usable with HD wallets. This can used to implement duress passphrases where you have a small amount of Bitcoin owned by the keys instead of giving away access to your life savings.
What if we placed the URL (practically browser origin) or IPFS/IPNS hash of a website as passphrase? Then for every device that shared the same mnemonic, they would be able to access the same keys when accessing the same website as well as keep the websites unaware of the details of the mnemonic and each other.
What if instead of the unique authentication token that Google would have placed in local storage, we would place a mnemonic?
With Zipper Vault, we prototyped this — where vault.zipperglobal.com is the keeper (in HTML5 local storage) of the mnemonic. Websites can then through a postMessage based API request to encrypt/decrypt using a particular derived keypair, sign using it, etc [warning: not yet production quality or fully functional].
The websites would not have access to the factual private keys as well, a-la Hardware Security Modules. If it’s the first time the Zipper Vault is accessed, it generates a new mnemonic in the background without user interaction.
How would we then disable a particular browser instance’s access if the device it’s on gets stolen? This can be accomplished if the Vault doesn’t keep the full mnemonic in local storage, but only keep a slice of it through Shamir’s secret sharing.
It would have a per-device key that would be used to encrypt the other slice; which could then be stored at a service that can be trusted to forget the encrypted slice when asked to. The request to forget could be authenticated by a key derived from the stored mnemonic, so another one of your linked devices could disable it, or other creative means.
The question is then, how -do- we protect life savings with a Google-like identity model?
The answer lies in the same magic that separates websites’ keys from each other; the passphrases — yielding a concept not unlike the approach of Visa PayWave. This can be any amount of bytes being added to construct a seed for a particular purpose related to a particular website, such as your preferred wallet storage code.
You can then imagine a scenario whereby a website requests to pop up a dialog for a passphrase entry from the Vault, or scan a printed QR code with the key data, or more exotic methods such as hardware wallets or ultrasound networking; and then the website gets access to then encrypt/sign/etc with this derived keypair tree; which owns your life savings.
An alternative method could be to hide the key data inside a derivation path, where k is an array of bytes containing a key, then the HD wallet derivation path could be m/0/k[0]/k[1]/k[2]/k[3]/…/k[len(k)]. Due to the ability to have public extended keys, it is possible as well to cache entire tree of public keys, even of passphrase+mnemonic generated seeds, in order to reduce network requests for the other slice of the mnemonic.
Things to explore though
- Vault is a single point of failure and centralised. It could be such that with ServiceWorkers that first time it downloads the code, it caches it all offline and checks regularly for updates, that user will be prompted to approve? Would an offline Vault be decentralised enough — after all, it’d be like downloading an ‘app’ into your browser.
- There’s also no guarantee that Vault domain would be serving legit code other than trusting Zipper as a publisher (but not so different from an App download)
- Browser extensions as a threat (that’d be a threat to Google account authentication tokens too, no?)
- DNS and TLS certificate security of vault.zipperglobal.com should be on par with Google’s
- How do we reach out to the user to ensure he conducts backup and further hygiene of his digital identity (maybe a profile picture on Vault-using websites w/ notifications); as well as remember to link in other devices he uses?
- How do you merge identities with good UX if you started using a Vault-using website on mobile; and then laptop, without linking them?
- Same identity vault could be leveraged towards Bitcoin keys or other blockchain key systems; or even connect up with private blockchain query nodes.
Now, how does a frictionless Ethereum world look?
Imagine being in a Ethereum meetup; you’re new — you have nothing but your smartphone. You walk over to somebody offering exchange from your local currency into ETH, hand her some bucks, she types in the USD amount and gets the amount of ether and a QR code shows. Underneath the QR code https://qrscan.io is mentioned as a means to scan it, which you go to on your mobile browser (works under Chrome), scan the QR code.
Then you’ve received the sent ETH, there’s a suggestion to add the wallet to your home screen showing on your screen and a request to permit push notifications. You then link up your laptop as suggested in a notification later on and you can now use those ETH on your laptop as well.
I’m sure there’s many other benefits from the fact you can begin using an dApp hosted on IPFS for example and have it feel as being an as integrated experience as using Google account using sites do.
The gas problem & blockchain nodes
However, two more things to mention. Gas. The biggest blocker for people starting to use dApps is that they can’t send transactions without having any Ether — something that can’t be expected of all new dApp users to have.
Some solutions do it such that they estimate the gas needed to conduct a transaction and then send that exact amount of ether to the account needing to do it; and then the send the Ethereum transaction after. This can be a bit fragile but on the other hand does not require modifications to existing smart contracts.
There’s also ongoing discussions at EIP662 about roughly the same, suggesting different methods of doing it.
As part of our experiments with Ethereum, we developed a solution where we have an AuthedForwarder smart contract that other contracts trust that when it calls particular whitelisted-by-them functions, the first parameter will always truthfully be equal to an address that was recovered from a specialised transaction signature (roughly signature of “allow this forwarder contract to send this calldata to this other contract and here’s a nonce so don’t even try to replay”).
It’s then a matter of submitting your transaction to a basic service (“Pay My Gas”) that then with its particular amount of ETH calls the AuthedForwarder smart contract. Any return values representable in bytes32 range can then be read from event logs, if so desired.
And secondly, also what INFURA introduced to the general public was the availability of public Ethereum query/IPFS nodes, is key towards frictionless dApp use. But at same time, the Vault should be able to tell dApps to use different IPFS and Ethereum query node URLs, such as your own, so an user can opt to be more decentralized if you so wish.
Join the discussion
If you’d like to discuss the Frictionless Ethereum concept and/or what we do at Zipper, Join us at Telegram at https://t.me/zipperoffical
Carsten (@stskeeps) is CTO at Zipper Global Ltd., (@zipperglobal)
