Thread by @sniko_

Refresh our memory on what we learned in 2017/2018, which ultimately led to us removing that "feature" from our web platform (redd.it/8wenmw) and started an effort to get other projs to remove this antipattern.

Tweet thread will be for DeSo but other projs take note

https://twitter.com/nadertheory/status/1480360261982715905

First, let's start with what DeSo is and isn't, so we can describe its potential scope to users.

DeSo itself is a L1 blockchain, however it offers an identity solution on its subdomain with a public code lib that apps can use to help user onboarding

docs.deso.org/identity/ident…

This onboarding allows users to authenticate via Google or input their seed phrase (which also generates a seed phrase if you are new)

Summary: Seed generation is done within the iframe and stored (encrypted) in LocalStorage

First, let's discuss the technical implications of this design choice.

The encryption happens client side, with an encryption key based on the hostname using the identity service

However, since it's all stored this way, something with higher privileges in the browser can read..

For example, with a browser extension, we can read all the data from DeSo identity and exfil to somewhere

I created a PoC that would so this.

Although we can get the EC PK, the secret recovery phrase is unencrypted in LocalStorage

github.com/409H/poc-deso-…

If you think there is not malicious interest in browser extensions, you are wrong.

Not only do I (author of ext with ~50k installs) offers to buy my ext namespace every month, we have seen developer accounts being compromised

pandasecurity.com/en/mediacenter…

https://twitter.com/sniko_/status/1358058620315918339

The social implications are worse as it is teaching people to type their secrets into a website for authentication, smth that bad actors will capitalise on (and they still do from when the tech was still new and this pattern was "normal" in 2016..2018)

https://twitter.com/sniko_/status/918793849979498496

Users will become accustomed to "oh its fine with DeSo, so I'll do it here" and it will create a very bad expensive habit for your end-users.

Your persistent locally stored data will be safe with DeSo, until it isn't.

Asking for raw secrets on a website is not needed, especially with the tech/packages we have today

Web3Modal (@pedrouid) has a lot of out-of-the-box providers to allow for external trusted-battletested key management solutions to be implemented into app

github.com/Web3Modal/web3…

But DeSo is not the only project that has done this, but they do seem to be the only project that is doubling-down on their antipattern of allowing raw secrets on the web

For Ex. Kyber removed this feature when the community pointed out it was a bad idea

https://twitter.com/loi_luu/status/1280514152675659778

I urge the community to shine the spotlight on any and every project that allows this antipattern - we aren't doing anyone any favours enabling this type of convenience to end users.

@nadertheory I am more than happy to give you data to help you change your mind on this stance

hehe 😇 it all makes sense now

DeSo = ✨ Don't Ever Sign On ✨