There are enough non-shitty banks and credit unions, at least in the US, that you should be able to easily switch banks to a better one. They have no moat.
FWIW my US bank works on GrapheneOS and they refund all ATM fees, so you can use any ATM you want. The only issue I've run into with them is they have a Zelle integration which is only available on the phone, and on GrapheneOS it just loads to a blank white screen. But that seems to be Zelle's fault. The bank is Charles Schwab if anyone is looking for a currently-compatible-with-GrapheneOS bank in the US.
I appreciate you giving it a shot, then! Our experiences are pretty different; I've almost always found solid working apps from F-Droid, and my main messenger, web browser, podcast app, ebook reader, RSS reader, calendar, tower defense game, and home screen launcher are all from F-Droid. I use the Play Store mostly for Google's own apps (namely Maps and YT Music) and my banking app.
No, that's not true - the change was that you could only install software from verified developers, not only from the app store, and now they've partially walked that back too and "are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified." ( https://android-developers.googleblog.com/2025/11/android-de... )
When we needed some work done, we asked family and friends too, and ended up with a cowboy. When the work needed to be re-done, we looked up local reviews for contractors, and ended up with someone who was more expensive but also much more competent, and the work was done to a higher standard.
> ended up with someone who was more expensive but also much more competent, and the work was done to a higher standard.
How do you know that? Or is it just that your bias is coybows are bad and so you assume someone who dresses and acts better is better?
Now step back, I'm not asking you personally, but the general person. It is possible that you have the knowledge and skills to do the job and so you know how to inspect it to ensure it was done right. However the average person doesn't have those skills and so won't know the well dressed person who does a bad job that looks good from the poorly dressed person who does a good job but doesn't look as good.
Perhaps I wasn't clear - I don't know enough to say if the job was good or bad just by inspecting it, I know the first job was bad because it didn't solve the problem, and then a more expensive contractor explained why, and did solve the problem.
Our issue was water intrusion along a side wall that was flowing under our hardwoods, warping them and causing them to smell. The first contractor replaced the floor and added in an outside drain.
The drain didn't work, and the water kept intruding and the floor started to warp again.
When we got multiple highly rated contractors out, all of them explained that the drain wasn't installed correctly, that a passive drain couldn't prevent the problem at that location, and that the solution was to either add an actively pumped drain or replace the lower part of the wall with something waterproof. We ended up replacing that part of the wall, and that has fixed the issue along that wall. (We now have water intrusion somewhere else, sigh).
If anything, I was originally biased for the cowboy, as they came recommended, he and his workers were nice, and the other options seemed too expensive & drastic. Now I've learned my lesson, at least about these types of trickier housing issues.
Also, no one mentioned evaluating someone by how they're dressed - the issue was family/friend recommendations vs online reviews, and I while I do take recommendations from friends and family into account, I've actually had better luck trusting online (local) reviews.
For me, the key problem being solved here is to have reasonably trustworthy web implementations of end-to-end-encrypted (E2EE) messaging.
The classic problem with E2EE messaging on the web is that the point of E2EE is that you don't have to trust the server not to read your messages, but if you're using a web client you have to trust the server to serve you JS that won't just send the plain text of your messages to the admin.
The properties of the web really exacerbate this problem, as you can serve every visitor to your site a different version of the app based on their IP, geolocation, tracking cookies, whatever. (Whereas with a mobile app everyone gets the same version you submitted to the app store).
With this proposed system, we could actually have really trustworthy E2EE messaging apps on the web, which would be huge.
(BTW, I do think E2EE web apps still have their place currently, if you trust the server to not be malicious (say, you or a trusted friend runs it), and you're protecting from accidental disclosure)
It doesn't seem like there's much difference in the trust model between E2EE web apps and App Store apps. Either way the publisher controls the code and you essentially decide whether to trust the publisher or not.
Perhaps there's something here that affects that dynamic, but I don't know what it is. It would help this effort to point out what that is.
On the web, if your server is compromised it's game over, even if the publisher is not malicious. In app stores, you have some guarantee that the code that ends up on your device is what the publisher intended to ship (basically signed packages). On the web it's currently impossible to bootstrap the integrity verification with just SRI.
This proposal aims at providing the same guarantees for web apps, without resorting to signed packages on the web (ie. not the same mechanism that FirefoxOS or ChromeOS apps used). It's competing with the IWA proposal from Google, which is a good thing.
> On the web, if your server is compromised it's game over, even if the publisher is not malicious. In app stores, you have some guarantee that the code that ends up on your device is what the publisher intended to ship (basically signed packages)
Not quite. It is possible for an account to be taken over or bought and a new update deployed. It is also possible for the server the app gets its data from to be taken over just like in your example and serve you fake data to make you regurgitate whatever data the malicious actor wants
Sorry, I should have been more concise - the two big differences are:
1) everyone gets the same code
2) it doesn't change too quickly
This means you can (esp with reproducible builds) audit that the code is correct and know that everyone is getting the correct code, and that misbehavior will be identified.
Very cool - played around with it, and it seems quite featured, and my test podcast worked!
I really appreciate the local-first, self-contained but very portable architecture, with an optional server connection to handle CORS and index and whatnot; that's a really solid approach.
Hopefully this isn't too annoying, but I saw you open-sourced what looks like the backend, do you have any plans/interest to open-source the front end as well, for people who might want to self-host?
Yay! And not at all annoying. No plans to open-source the frontend at this stage but I'll keep the request in mind. Btw, that backend was part of an earlier abandoned infrastructure attempt. Still cool code imo, but no longer running on it.
reply