pull down to refresh
221 sats \ 3 replies \ @bordalix 25 Jun \ on: Opinion: PWAs and Bitcoin are a toxic marriage devs
I’m the solo developer of https://helm-wallet.com, a self-custodial PWA lightning wallet (that uses Liquid and Boltz under the hood) and I’ll make a comment on every point you made:
This is not 100% true. https://helm-wallet.pages.dev is a static server, it only serves files. The code is open-source, you can check there’s no phoning home. Better than that, there’s no home to phone to.
I have no idea how many times the wallet is open or used. I believe it's not a bug, it's a feature.
True. In Helm, your seed is stored locally encrypted with AES256. If you lose your password or you clear your browser storage, you will in fact need to restore your seed. Having said that, with Helm you restore your seed in seconds.
You can run Helm locally, is easy as:
- clone repo
- yarn
- yarn start
- access app on your browser localhost:3000
In order to minimize this risk, Helm can be run locally and is automatically deployed to more than one domain. I take advantage of webhooks to push code to 3 different repos (github, gitlab, bitbucket) and 2 automatic deploys (https://helm-wallet.pages.dev/ and https://bordalix.gitlab.io/helm-wallet/)
I'm looking for more free services like those, where I can automatically deploy a static site. A service like this based on Switzerland would be gold.
True. This is the facto trust level on the web industry. You rely on the same security when you access your home banking or any other sensible website. It’s not perfect, but it’s what we have.
See previous comment.
The key information here, your seed, is stored locally, encrypted with AES256, and available in plain text only on memory. It’s almost impossible for those in the distribution pipeline to do anything to steal it.
I tried :-)
But don’t trust, verify.
Good advice. With Helm users should restore their wallet and check for funds availability in different domains and locally. Everything should work just the same.
Not entirely true: you can use PWA with Tor Browser and access only onion addresses. This feature is implemented on Helm wallet, exactly to minimize the risk you refer to. Using Tor, you hide your IP address from Boltz and from the chain explorers.
Just my 2 sats.
Hi, and thanks for your work, helm looks cool! Clever choice to use Liquid swaps. I admire your choice to make it a static app, as those tend to work very well for running from source and can be deployed very easily.
Feedback: I just tried Helm out and unfortunately my money disappeared (0 balance shown) after depositing with LN. It reappeared once I refreshed the web page.
This is not 100% true. https://helm-wallet.pages.dev is a static server, it only serves files. The code is open-source, you can check there’s no phoning home. Better than that, there’s no home to phone to.
A static file server is still a server, and every time I open
helm-wallet.pages.dev in my browser (and every time I open the PWA), my browser makes a GET request to helm-wallet.pages.dev to fetch an HTML file which dictates what UI to display and what code to execute. That's phoning home and auto-update at the same time. Maybe it's not your home, since pages.dev is controlled by cloudflare, but that's still phoning home, in my opinion at least.Sounds like running the wallet from source would avoid this, so props to you for that choice! I love static sites in general.
The key information here, your seed, is stored locally, encrypted with AES256, and available in plain text only on memory. It’s almost impossible for those in the distribution pipeline to do anything to steal it.
It's absolutely possible. Simply distribute a version of the wallet's JS code which waits for the user to type her password in, and then decrypt the seed like the normal wallet does. Then the attacker can send the seed somewhere off-site or sweep the money to his own address.
Not entirely true: you can use PWA with Tor Browser and access only onion addresses. This feature is implemented on Helm wallet, exactly to minimize the risk you refer to. Using Tor, you hide your IP address from Boltz and from the chain explorers.
I'm not talking about IP addresses - i'm talking about deanonymizing on-chain transactions. If the gov had full access to individual samourai wallet seeds, they would have been able to see exactly who made which transactions and which TXOs belonged to whom, and so completely negate the purpose of coinjoining. And they could have confiscated that coinjoined money from anyone they wanted to at the same time.
I'm glad the justice department didn't attempt to distribute malicious samourai wallet builds after the seizure, because the same thing could've happened there to native apps. It's possible the only reason they didn't was because they didn't have the app-signing keys held by the samourai devs, and so the update wouldn't have been accepted by existing users' devices. This might have saved a lot of harm. A PWA would have been wide open to this class of malicious-update attack.
You can run Helm locally, is easy as:
Thank you! More wallet devs should make running from source easier. This is about the easiest you can make a static site to run so bonus points from me ++ :D
Pro tip: if you want to also distribute a native mobile application without changing your regular PWA build pipeline, you can create an app with Expo, bundle the static site files inside the application package, and then render the static site inside a WebView. For desktop, you can package and render the static site inside Electron (i'm guessing you probably have heard of that one before). Both approaches would help to avoid forced malicious update attacks, and would allow users to verify their installations automatically (app-signing) or out-of-band (with PGP).
reply
I will never make an iOS app, not while Apple has this on their Apple Developer Agreement.
I once made an Android app, for the sole reason (at the time) of having more accuracy on the user location. It's just a WebView for https://wheretosurftoday.com/, but now Google want's me to KYC :(
reply
In regards to the "phoning home" point, in web standards you can support offline mode, so it would be trust on first serve. However, as implemented Chrome force an update every 24 hours to prevent a website from being permanently hijacked. Trust is still required but not per request on sites that implement offline mode such as MutinyWallet.
reply