Universal Logins update – new live demo
You can now test out universal logins right from your browser!
After some well deserved cooldown post Devcon4, the Universal Login team is back to work and we have new updates. First, let’s talk about devcon itself: during the whole “blcockhain week” in Prague, we presented Universal Login in 4 different venues: at Web3 Summit, Status Hackaton, DeFi Summit, Devcon and finally at the ECF Allumni meeting. The video of the Devcon talk is available on youtube:
Devcon4 was also a great place for Meta Transactions: besides the talk above we also had many others covering the topic, an onboarding breakout room, a standardization breakout room, and multiple off-schedule meetings, including a fantastic dinner organized by Pet3rpan. If you’re interested in learning more here’s a good list of talks to check that are related to Universal Logins:
- Recurring meta transactions to power l33t subscriptions! by Austin Griffith (Devcon4)
- Argent at the Dapp UX Awards
- Gnosis Safe — make crypto less scary, by Stefan George
- State of ENS, by Nick Johnson and Jeff Lau
Enough talk: play with it now!
Enough about devcon, we have updates on the system too. The most important one is that now you can test it out for yourself without having to install anything by ust going to our demo website:
example.universallogin.io
👆👆👆👆👆👆👆👆👆👆👆👆
Test it out! Go on, type a name and pick one you want, and an account will be given for you, as well as some tokens. You will then be redirected to our highly interactive webpage containing a single button. Try clicking it. Yeah, the big red one, can’t miss it.
It might take up to 30 seconds to take effect (we’re considering adding a pending transaction state so the user sees the result immediately), but soon you should see your name on the list of people who clicked the button. On the same page you’ll also see when was the button last clicked, as well as the current token balance of your account. These are all taken directly from the blockchain. Once you clicked your button, you can see that it actually took effect by looking at the Clicker Contract Events page on etherscan. Each time the button is pressed it creates an event with the address of the presser, the timestamp on when it was clicked, as well as how many seconds it had passed since the last time the button had been clicked (the “score”). On the Read Contract page you can also check the timestamp of the last time it has been pressed. You can also check the contract source code and check that the Clicker contract itself is a very simple one, that doesn’t do anything special to be compatible with Universal logins, it just emits an event for msg.sender.
If you have already worked with ethereum apps before, there’s only a few things you’ll find unusual: the transactions page of the contract is empty, and most of the transactions on the token come from a few accounts and these transactions themselves only show tokens transfers. This is because what’s actually happening is that these accounts are being submitted by the relayer, who calls the contracts, uses a meta-transaction to make it touch the Clicker contract, and then the contract pays them back in tokens. This is how meta-transactions work behind the scenes to make a better UX.
We also worked on many other things:
- Beside yarn dev:start that allows you to run locally you can now use yarn start to run on test network
- There are two scripts for registering ens domains on test networks
- As the demo app is now very complex (despite looking simple) we also created a separate repository for a boilerplate app that makes it easy to get started
- We are also now on npmjs!
- And we updated all codebase to ethers 4.0
Security concerns
Not everything is flowers, however. In order to do this magic, we are keeping private keys in an unsafe environment, the browser. If you haven’t so far we highly recommend you watch this amazing Devcon talk by the founder of both MyEtherwallet and MyCrypto: Unintended Consequences of Product Design, by Taylor Monahan, where she explains all the ways in which their website was attacked attempting to steal private keys, including attacks to the core infrastructure of domains systems that were completelly outside their control.
We ourselves were accidentally vulnerable: upon investigation Michael Yankelev, an external developer, discovered that one of our dependencies was Event Stream, a package that was transferred to a malicious author and updated it to steal crypto keys. If our system was live and using real money, it would be serious incident.
The bottom line, which sound obvious, is that the browser storage is not a great place to keep private keys. Many things can happen: the storage can be lost, the browser can be fooled into revealing it to a malicious website by switching the domain, the client code itself can be infiltrated. But still, we believe that onboarding without any extra downloads is essential and here are the steps we are studying to mitigate the problem:
- Limiting the privileges of the browser key, so that it cannot do anything without a second confirmation from a key kept in the server. For the user this would look like an extra step where they would need to do click a new link on their email at every action. We can take this a step further and only keep part of the actual key on the browser, using a scheme like Samir Secret Sharing to create a shared key shared between the browser and the server. Of course, if both the server and client were compromised, this would mean funds could be stolen. And the user should be given the option to remove the server key in the future.
- Limit the amount of funds that can be stored on the interface before the user is forced to install a secondary, trusted device or other backup options. This could be either a native client (unlike browsers, mobile environments often have secure enclaves to keep private keys safe), a browser extension (Metamask) or even a hardware wallet.
- Store all front-end in IPFS. This will be very valuable in the future, but at the moment it suffers from a few problems: because browsers don’t support IPFS natively, we would have to use a gateway, which not only reintroduces the trust issues on the gateway itself, but has issues on themselves when they use multiple apps on the same domain that allows apps to spy on other’s storage. An IPFS client guarantees that you’ll always be running the same code you trusted before.
And of course, this would be in addition to all the other common practices, including a larger audit of our dependency graph and having formal verification on the contracts.
Timeline
This is the single largest question we get asked: when can we use Universal Logins? An obvious lesson from the last section is that we don’t want to launch anything too prematurely, but also, since we have been having many requests from app companies wanting to launch soon with some sort of integration, so our main goal is to have an early testable beta on the main net by end of Q1 next year. That of course depends on many factors, among them budget. Universal Login has gone as far as it went thanks to the generous support of both Ethereum Community fund and ETHPrize, but these grants are ending soon and we are in the process of applying to new ones in other institutions. If everything goes according to plan, we hope that EthWorks will be hiring more developers for the project soon, so if you live in Warsaw (or want to try to work remote) please contact ethworks.io about it. Also, if you are already working in a project and want to see how you can give us technical or other types of help, please check out our repository and updated website: github.com/universalLogin and universallogin.io
That’s all for this year. Hope you had so much fun in 2018 as we had, and that 2019 will be even better for everyone! Happy holidays and new year.
