-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
getInfo()
compromises user identity
#46
Comments
To be clear, nothing in the WebLN spec says this is the case. The docs explicitly state:
This is user agent behavior, and a WebLN provider is free to reject calls to Should sentiment about this function decide that it's completely unwanted for privacy purposes, it could be deprecated. But for the time being it still seems like it could be useful for sites that require your node's pubkey for things like monitoring services. I completely agree though that |
I would like to voice my support for webLN adopting LNURL-Auth type authentication. It is a very simple and elegant solution: user wallet generates a new pair of keys derived from their private key and information/TLD of the website, then signs a challenge and produces the key for that site. Very simple and allows easy backup/recovery of keys, without revealing the primary public key or any other sensitive information. I feel strongly that with LNURL-auth, the issues of privacy and authentication are a solved problem. A number of major wallets already support this spec, and it would be really great to see this as a standard in WebLN! |
Currently, calling
webln.enable()
—and accepting the prompt—automatically gives the website permission to callgetInfo()
which exposes your node id and pubkey. To fix this security issue, we could just remove this method from the spec. Alternatively—and if authentication is one of the goals of webln—then I'd suggest we do something similar to what LNURL-Auth has done, which uses alinkingKey
derivation and allows users to authenticate without having to compromise their identities.The text was updated successfully, but these errors were encountered: