pull down to refresh
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
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.
A static file server is still a server, and every time I open
helm-wallet.pages.devin my browser (and every time I open the PWA), my browser makes aGETrequest tohelm-wallet.pages.devto 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, sincepages.devis 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.
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.
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.
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).