Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Real Problems That Web3 Solves, Part 1

billprin.com

Post reply on HN
Print view View original

121–130 of 319 posts

Re: Real Problems That Web3 Solves, Part 1

#121

Post by endisneigh »

thebean11 wrote: post #114
endisneigh wrote: post #109

Earlier quoted context omitted.

> Apologies if I'm missing something, if it's easy to spin up unique identities on both what's the difference here? It seems like it would be one or the other. Yes except for a centralized entity the admin would have recourse. How does a web server admin deal with it in the case of blockchain? > I've seen posts on this forum about it. It happens and there's not much you can do if it does. If we are talking about anec…

> Yes except for a centralized entity the admin would have recourse. Can you be more specific? How is it easier to sniff out a user using multiple emails vs multiple keys? > If we are talking about anecdotes I’ve seen people lose their private keys to phishing and consequently all of their money, so… Losing your keys is a huge problem that needs to be solved. I think social recovery is super promising in that respect…

> Can you be more specific? How is it easier to sniff out a user using multiple emails vs multiple keys?

If someone made 2109@gmail.com 238@gmail.com 2398@gmail.com you could contact Google, send them the information and potentially block all of them collectively and/or find the person responsible. This would be important if your application has to do with financial activity. How would you do this if someone kept making random private keys?

> I'd argue for logins specifically it's less of an issue in the MetaMask world, as you do not need to expose your private keys for that. You need to expose your password to log into Google.

I'm not understanding you. If you're someone who won't use Google, or a centralized service, then you are capable of hosting your own web server. If you're capable of that an email address + password is superior to blockchain and gives you more control.

If you're not capable of that and are using centralized services for things like email then you lose no more control using their oauth server.

You and author have yet to address failure modes, or the superiority of this compared to email and password.

Re: Real Problems That Web3 Solves, Part 1

#122

Post by rbanffy »

numtel wrote: post #111
rbanffy wrote: post #91

Earlier quoted context omitted.

If the ledger is not public, why would I trust it? If someone else claims they are you, how would I differentiate the conflicting claims?

Messages are signed by cryptographic signatures so nobody can claim to be you. This is how JWTs and many other protocols ensure message authenticity.

Nobody can claim they own the key you claim you owned, but, unless you have a person-to-key map somewhere, my claim I'm you is as good as yours.

Re: Real Problems That Web3 Solves, Part 1

#123

Post by mattlondon »

wan23 wrote: post #117
mattlondon wrote: post #89

Earlier quoted context omitted.

So if you are not going to go whole-hog and have one true identity for everything, why bother using anything apart from an email address? The argument seems to be that consistency allows you to prove ownership and re-use all of your content etc across the web by tying everything back to one verified identity. If you are having different identities on different sites then that benefit disappears, and I fail to see how…

Email addresses aren't really good for this. It's really easy to sign up for a service with someone else's email address, for example. Sure, if that person ever finds out they can potentially claim ownership of the account through a password reset, but it doesn't erase the fact that you have been using their "identity" for some time.

Is this still a thing though? Pretty much everything I've used in the past 10-15 years has required email validation before allowing you to do anything meaningful.

Either way though, I don't see how an account claiming to be "wan23" would be any more trustworthy to me as created off of the back of an email account or off of a wallet ID - I still have no idea (nor do I care) who you are.

Re: Real Problems That Web3 Solves, Part 1

#124

Post by endisneigh »

wan23 wrote: post #117
mattlondon wrote: post #89

Earlier quoted context omitted.

So if you are not going to go whole-hog and have one true identity for everything, why bother using anything apart from an email address? The argument seems to be that consistency allows you to prove ownership and re-use all of your content etc across the web by tying everything back to one verified identity. If you are having different identities on different sites then that benefit disappears, and I fail to see how…

Email addresses aren't really good for this. It's really easy to sign up for a service with someone else's email address, for example. Sure, if that person ever finds out they can potentially claim ownership of the account through a password reset, but it doesn't erase the fact that you have been using their "identity" for some time.

> Email addresses aren't really good for this. It's really easy to sign up for a service with someone else's email address, for example. Sure, if that person ever finds out they can potentially claim ownership of the account through a password reset, but it doesn't erase the fact that you have been using their "identity" for some time.

This is also true of a private key, in fact it's literally the same scenario...

Re: Real Problems That Web3 Solves, Part 1

#125

Post by mattlondon »

gillesjacobs wrote: post #115
jdlshore wrote: post #11

Several years ago, Mozilla/Firefox created "Persona," which was an open-source federated identity system that provided all the benefits described here. The idea was that it would eventually be built into browsers. I used it on a commercial site myself for many years. It failed to gain traction, and Mozilla eventually pulled the plug. Persona had many advantages over the Web3 vision described in this article. It was p…

Cryptocurrency ecosystems have the advantage of economic incentivization and if they're decentralised, uncensorability. Those are two major advantages.

> uncensorability

I suspect that this will be a major issue in the long-run. Once these sort of crypto-based logins become synonymous with CP and terrorism, they're going to be shunned by the average person on the street.

Yes yes yes, people use email and whatsapp for the same, but at least there is the option for Google and Facebook to censor or block/ban those users (and it feels like there is increasing legal/legislational tension to try and compel the tech giants to actually do something in this area). You cannot say the same about an indelible blockchain.

Re: Real Problems That Web3 Solves, Part 1

#126

Post by carlosdp »

jdlshore wrote: post #11

Several years ago, Mozilla/Firefox created "Persona," which was an open-source federated identity system that provided all the benefits described here. The idea was that it would eventually be built into browsers. I used it on a commercial site myself for many years. It failed to gain traction, and Mozilla eventually pulled the plug. Persona had many advantages over the Web3 vision described in this article. It was p…

I joined the team at Mozilla that developed Persona as an intern, just as they closed it down.

Persona failed because it was fighting against a head-wind of an already established trend of using Google/FB OAuth2, without giving the service provider any new benefits. There was no incentive for a website to actually implement Persona, since it was just another auth provider and users weren't using it. Users didn't use it because no one implemented it. Chicken and egg.

Websites that integrate web3 wallet login do get something new: built-in, straightforward payment rails.

Re: Real Problems That Web3 Solves, Part 1

#127

Post by thebean11 »

endisneigh wrote: post #121
thebean11 wrote: post #114

Earlier quoted context omitted.

> Yes except for a centralized entity the admin would have recourse. Can you be more specific? How is it easier to sniff out a user using multiple emails vs multiple keys? > If we are talking about anecdotes I’ve seen people lose their private keys to phishing and consequently all of their money, so… Losing your keys is a huge problem that needs to be solved. I think social recovery is super promising in that respect…

> Can you be more specific? How is it easier to sniff out a user using multiple emails vs multiple keys? If someone made 2109@gmail.com 238@gmail.com 2398@gmail.com you could contact Google, send them the information and potentially block all of them collectively and/or find the person responsible. This would be important if your application has to do with financial activity. How would you do this if someone kept mak…

> If someone made 2109@gmail.com 238@gmail.com 2398@gmail.com you could contact Google, send them the information and potentially block all of them collectively and/or find the person responsible.

Citation needed, I very much doubt Google would comply without a search warrant. For financial activity, it depends whether the application requires authentication, or simply funds. For authentication see things like DECO, where you could prove some personal information about yourself without actually revealing that information (SSN for example). Obviously that is piggy backing off of a legacy system; it's up to the application to say what data they need.

> I'm not understanding you. If you're someone who won't use Google, or a centralized service, then you are capable of hosting your own web server. If you're capable of that an email address + password is superior to blockchain and gives you more control.

You are completely wrong that everyone currently using MetaMask is capable of hosting their own web server. Securely hosting a web server is orders of magnitude harder than securely using MetaMask.

I think I did address both failure modes and the benefits. I agree with you that it's not ready to replace email and password, but I don't think the issues are insurmountable either.

Re: Real Problems That Web3 Solves, Part 1

#128

Post by endisneigh »

thebean11 wrote: post #127
endisneigh wrote: post #121

Earlier quoted context omitted.

> Can you be more specific? How is it easier to sniff out a user using multiple emails vs multiple keys? If someone made 2109@gmail.com 238@gmail.com 2398@gmail.com you could contact Google, send them the information and potentially block all of them collectively and/or find the person responsible. This would be important if your application has to do with financial activity. How would you do this if someone kept mak…

> If someone made 2109@gmail.com 238@gmail.com 2398@gmail.com you could contact Google, send them the information and potentially block all of them collectively and/or find the person responsible. Citation needed, I very much doubt Google would comply without a search warrant. For financial activity, it depends whether the application requires authentication, or simply funds. For authentication see things like DECO,…

> Citation needed, I very much doubt Google would comply without a search warrant. For financial activity, it depends whether the application requires authentication, or simply funds. For authentication see things like DECO, where you could prove some personal information about yourself without actually revealing that information (SSN for example). Obviously that is piggy backing off of a legacy system; it's up to the application to say what data they need.

There's plenty of evidence out there for this (https://www.jamesmadison.org/the-governments-secret-google-s...). Furthermore Google has a contact to official subpoena them if you want (https://support.google.com/faqs/answer/6151275?hl=en). For mild things you could just report abuse and escalate - https://support.google.com/mail/contact/abuse?hl=en

Again, you're not answering the question. What does the web administrator do if someone is creating fake accounts using a private key? If you're going to use third party systems you don't need blockchain to begin with.

> You are completely wrong that everyone currently using MetaMask is capable of hosting their own web server. Securely hosting a web server is orders of magnitude harder than securely using MetaMask.

You're addressing a claim I didn't make. I'm not sayin everyone using metamask can host their own server, I'm saying someone who isn't using a centralized entity anywhere can do it, by definition. Hosting a web server is trivial in 2022. You can literally setup a server by going to digitalocean.com right now, paying $5, and spinning up a one-click machine. Administrating it at scale is obviously more difficult, but it's trivial to setup a little oAuth server if you want.

Re: Real Problems That Web3 Solves, Part 1

#129

Post by spinny »

jeroenhd wrote: post #94
spinny wrote: post #57

Earlier quoted context omitted.

It can. It just happens that the easiest way to achieve this is using web3, even if there is no blockchains involved. The article is about login methods, not cryptos or web3

> It just happens that the easiest way to achieve this is using web3 Is it? U2F is actually rolling out to more and more websites but I've never seen any website offer to log in with a dropdown for cryptocurrencies

websites that are related to cryptos do it, others generally don't. try dappradar.com/ for example

Re: Real Problems That Web3 Solves, Part 1

#130

Post by thebean11 »

mwattsun wrote: post #62

I'm reading this with an open mind, but I have questions: > Problem #1: Owning Your Own Digital Identity & Fixing Authentication My very technical friends who are security minded are on keybase.io. Multiple usernames and passwords across the internet is solved in various ways without blockchain. There are a lot of good password managers (I use and encrypted text file.) I don't feel Google owns my identity because I u…

> This doesn't seem very workable in a practical sense. It seems like this could be spoofed fairly easily or the business service gets hacked

You could give keys to two businesses / people and require them both to agree before they can "unlock" the account. You could also add a timelock, so you have time to respond if they get hacked or collude against you.

These aren't really new ideas and exist in existing, non-crypto social recovery schemes.

Post reply on HN