121 sats \ 2 replies \ @conduition OP 25 Jun \ parent \ on: Opinion: PWAs and Bitcoin are a toxic marriage devs
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).
write
preview
100 sats \ 0 replies \ @bordalix 25 Jun
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
0 sats \ 0 replies \ @stak_kd1ls 25 Jun
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