Skip to content
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

Open
OliverOffing opened this issue May 11, 2022 · 2 comments
Open

getInfo() compromises user identity #46

OliverOffing opened this issue May 11, 2022 · 2 comments

Comments

@OliverOffing
Copy link

Currently, calling webln.enable()—and accepting the prompt—automatically gives the website permission to call getInfo() 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 a linkingKey derivation and allows users to authenticate without having to compromise their identities.

@wbobeirne
Copy link
Member

wbobeirne commented May 13, 2022

Currently, calling webln.enable()—and accepting the prompt—automatically gives the website permission to call getInfo()

To be clear, nothing in the WebLN spec says this is the case. The docs explicitly state:

webln.getInfo

Ask the user for some information about their node. The request may be rejected by the user depending on the provider implementation.

This is user agent behavior, and a WebLN provider is free to reject calls to getInfo() with a RejectedError, UnsupportedError, or they could even provide an empty string for pubkey if they were so inclined (though that may cause some unexpected behavior.)

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 getInfo() was a little bit misguided though and is an anti-pattern for privacy to have websites expect to be able to call it and always get a pubkey back. I didn't put a huge amount of thought into it as LN was very much so in the enthusiast / toy stage, and there wasn't a ton of adoption of private channels and nodes behind Tor. Getting on the same page as LNURL and providing an auth() function sounds like a good idea for a feature.

@cmdruid
Copy link

cmdruid commented Jun 19, 2022

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants