Comment by teekert
1 day ago
My (Dutch) bank Rabobank also blocks GrapheneOS [0], I contacted them about it, you get the usual thing, that "security is very important to them". Arguing is completely pointless, they don't understand what they are talking about. The Rabobank app works fine on Android phones that haven't seen updates in years...
However, via Aurora store it works fine (inc Wero)... I do feel a bit uncomfortable about it, but it's a one-to-one connection to the Play Store, so should be fine... What I don't understand is how that can work, the app itself does no checking after it is installed I guess? Not how I'd architect it...
My other bank, bunq, keeps whining about some service but functions normally nevertheless (I should give Play services access to my "Phone", I don't understand what that entails so I refuse it). N26 and Trade Republic just work.
I don't get wireless payments via Google Pay, but I don't even want that. So I'm really looking forward to Walt [1]. I would even start my sub now if that'd help him get it available in a year... At the moment there is Curve Pay [2], they have their own NFC stack. Bunq also used to have that (back when they were very pro-privacy) but they ditched it in favor of that horrible Google Pay.
[0] https://discuss.grapheneos.org/d/24630-rabobank-app-no-longe...
[1] https://walt.is/
Try again! I recently installed Rabobank via regular Google Playstore on GOS without any problem
OMG it's available indeed! I can update it even though I installed it via Aurora! This became available last week then?
Does Wero work for you?
Btw, play store reports that it was installed from another source and may function differently than expected. I can update or reinstall.
Will try reinstall now.
I think two or three weeks ago. So far no limitations in usage observed. But hey, who knows, they could revert it just as well...
Wero I never used/tried...
1 reply →
> The Rabobank app works fine on Android phones that haven't seen updates in years...
Exactly. If these companies were so serious about security, they should also block devices with, let's say, >1 year of security updates backlog. But that's a completely different number of customers compared to negligible Graphene/Lineage/e userbases.
They do not block unupdated phones because that will force users to buy exceptionally expensive devices to keep updated. Another thing is actually supportability. Just like any enterprise software, it targets a set of common devices so they can provide support and QA on it.
Now, that isn't to say there aren't security issues, nor that QA is perfect on devices they do support (like with any enterprise software projects), but it is a valid reason from a business perspective to not support everything.
Why do you think generally OpenBSD and such platforms aren't supported by commercial software, nor most open-source software? It adds a lot of burden for testing and QA on developers who will need to become intricately familiar with yet another platform.
People stare blindly at some customer support answers and hinge everything on those words, but if you think carefully about how software, compatibility and support work, this all makes perfect sense.
> They do not block unupdated phones because that will force users to buy exceptionally expensive devices to keep updated.
Hardly true, if they permitted Lineage and so on.
> Just like any enterprise software, it targets a set of common devices so they can provide support and QA on it.
Not really, there are a myriad of devices and they're not testing on all of them. A "pound sand if you're on an unsupported device and it isn't working" policy would be perfectly acceptable, as long as the issue isn't directly caused by the developer purposefully breaking the application for a subset of users that fail Play Protect check or whatever.
6 replies →
If any of what you were saying were true, then this wouldn't be just a discussion about banking software all the time, and we would see it happen with all kinds of other software, scaling with the complexity of the application or the level of provided customer support or the intended sophistication of the user or how "enterprise" the target market sounds... but none of this is the case, and if you tried to cluster products that do this along some axes the ones that stick out like a sore thumb are all of the form "controls something sensitive": money (banking, payments, investing, etc.), health data, copyrighted media (streaming), and multiplayer gaming (due to cheating issues). All of these people are very open about why they think they do it, and while we know they are incompetent, they are not doing it to be malicious and they have no incentive to lie to you about this: if a bank were truly not supporting your device because it was rare, they'd just say it, and we have ample evidence of this from banks choosing to not support "niche" browsers (including an era of "anything other than IE6" omg ;P). So: "cool story bro", but it is clearly wrong, lol.
It's not about your security nor your account. They are protecting their app, their apis, their servers. Everything that makes the life more complicated for hackers will be deployed, even if that includes power-users hacking their own stuff.
Blocking people from rooting their own devices isn't meaningfully contributing to security, even if they think it is. Not relying on security through obscurity is one of the first things you learn when studying the subject.
1 reply →
That would be on Google. If Google says the phone with zero updates for 5 years passes system integrity, then who we are to argue
For Google control is the issue (and the data flowing with it), not security, and once again we in Europe just swallow that shit and mess up our supposed "open" standards. In this case it really is because there are no competent people making these decisions. They just trust Google when they say: "It's for security".
I think what we need to do is all complain in the same way, something akin to: GrapheneOS is the most secure Android option, it's just not catering to Google by sharing all user data with them. You are falling for the false argument from Google that this is about security. It's not, it's more about sovereignty and control. And you and your bank are catering to Google/the US and YOU are throwing YOUR privacy conscious users under the bus, because you do not fully understand the forces at play.
Idk, this can be much improved :)
1 reply →
Of course they pass system integrity. The whole point of the thing is not "it should be secure", it's "the user has not messed with it so we control it".
6 replies →
Walt looks great. Though I'm not sure I'd trust my financials to a service that posts "Launch dat shit" as a milestone in their roadmap on their homepage.
I actually love that about it. Look at those photo's, what a guy. Contrast this to some "pro" looking vibe coded website, I'll take that guy launching dat shit over that any day.
Why do we trust soulless orgs? Trust this dude who puts his own face on his product!
> they don't understand what they are talking about
Even though the banks' policies are driven by incident responses and real data, whereas your position is presented on theory.
Is your answer driven by real data about the decision making of banks?
Defend my criticism of ignorance of circumstances by pointing out some similar vague notion of how I spent 15 years working in banks even though they are not this bank and this situation? No thanks.
5 replies →
As someone who worked at a bank - some policy decisions are not driven by regulatory requirements or technical expertise.