search

joule-labs / webln

Spec and client library for WebLN apps and providers
244 stars 28 forks source link

`getInfo()` compromises user identity #46

Open OliverOffing opened 2 years ago

OliverOffing commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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!