search

joule-labs / joule-extension

Lightning payments extension for Chrome
MIT License
353 stars 62 forks source link

Allow user to setup automatic payments per lapp #42

Open wbobeirne opened 5 years ago

wbobeirne commented 5 years ago

Provide an interface where a user can setup automatic no-ask payments for certain lapps. This would be limited by domain, and have the following configurations:

Should a maximum be exceeded, the user will be prompted for the payment instead of it being automatic.

Ideally they could configure this during or after a payment request (Maybe a checkbox?) There should also be a list of active auto pay configs, and some UI treatment for when you're on a page that can auto-pay (and perhaps after each auto-payment.)

PatrickZGW commented 5 years ago

LND #1160 could be interesting. Essentially a macaroon could be created that is tailored to a specific IP address with certain permissions. So even weekly or monthly payments could be possible. Or it could be done in the app itself. Maybe both is best.

wbobeirne commented 5 years ago

Yeah, I think macaroons are going to be the secret weapon for a lot of this stuff. That's definitely what I want to use in the future. I think unfortunately, in the short term, I'll just need to keep the admin macaroon hot while you're on a page you've authorized. I'm thinking the first payment will always require you to confirm (to decrypt the macaroon and get it in memory) and then it'll stay for the duration of the session. But a custom macaroon would be perfect for this instead.

leishman commented 5 years ago

I think this is an awesome feature, but just want to lay out a few security concerns and potential attacks that come to mind:

  1. Is there a good way to (optionally?) ensure the domain was accessed with TLS to protect against a DNS poisoning attack?
  2. I'm not familiar enough with the security properties of chrome extensions, but can you enforce some sort of same-origin policy to prevent malicious JS in ads or other plugins from pulling funds
  3. Should the recipient node id be locked in to prevent arbitrary payments made to malicious entities. What happens if the merchant changes their node or runs a fleet and wants to balance? Perhaps some DNS record to verify lightning node identity can be checked?
wbobeirne commented 5 years ago

Sorry for the delayed response, these are great questions. I think with a mix of low allowances and reasonable rate limits, there wouldn't be quite as much concern for wallet draining as, say, MyEtherWallet or EtherDelta have felt the heat for. However, I definitely want to do everything within my power to prevent those cases.

  1. I think this is pretty opaque to extensions. I can definitely tell if it was https, and now is http, but I can't tell if the cert is the same one and valid, or if it's invalid and the user clicked through, or if it changed.
  2. This is already done as much as I believe I can. However, if arbitrary JS can execute on your site (e.g. ads that run js that aren't in secure iframes) then there's not much I can do to stop this.
  3. I have most definitely considered this! This would work great on sites that operate on one node, but may lead to a bad user experience on sites that allow users to send directly to each others' nodes. Not sure if that'll be a common use-case though.

Ultimately I'd lean towards implementing 3 initially, potentially not having it be site-based auth at all, to prevent most of these hacking cases. That would also nicely get around any question of subdomains. Though it could introduce an issue with custodial services that host nodes for many different sites.

rawtxapp commented 5 years ago

Hey William,

FYI, this is now launched: https://rawtx.com/rawtx/update/2019/04/15/introducing-project-micro.html. Would love to get this kind of functionality in webln so that we can support a standard shared across wallets.