Hacker News Reader

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...

(Wero=iDeal)

> 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.

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 :)

> It's not, it's more about sovereignty and control

The bank doesn't care about either. It cares about the risks, costs and opinion of the regulator on how well it evaluates and controls those risks.

If risks can be transferred to an external party and DNB signs on it, sure. If DNB says reliance on this specific external party is a risk in itself, then sure, there will be a plan for that too. The plan could be "if google becomes a problem we can publish a new version of the app using grapheneos attestation anchors in N weeks"

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".

Well, yes? The law says that the bank should do the thing and the bank does the thing to the best of it's ability, given what people usually work there.

> the bank does the thing to the best of it's ability

No they don't. At best, they do a cost-effective proxy for what should be done.

Oh, you have no idea. It's not even about costs. In a 200 year old company the level of corporate disfunction and the average skill level of people is something else entirely. Nothing ever happens unless the regulator holds a blowtorch wired to a timer to the CEO's ass.

If the device is "insecure", doesn't that mean you - as a user - can exploit one of those insecurities to "mess with" the device without system integrity being aware?

Or are you saying the device is insecure BUT has no local privilege escalations you can take advantage of as a user?

It could have RCE but not privilige escalation. But I don't buy it, because 5 years without kernel patches is at least 5 escalation exploits being written by the an llm in 5 minutes

It means the spyware information flow and Google's ability to remotely modify the device have not been disabled.

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.

"Hardly true, if they permitted Lineage and so on."

I agree, but that is also totally unrealistic for normal people.

Btw, My son has a 200 eur Samsung Galaxy A26, very fine device for the price I have to say, and supported until feb 2031.

This bank claims "security is very important to them". In another, the poster reports getting training spam every week.

Installing Lineage isn't that hard. If they're going to badly inconvenience some customers / force hardware purchases, why not start with the ones who are most likely to get their accounts drained?

> Hardly true, if they permitted Lineage and so on.

GrapheneOS have written about (in)security of LineageOS:

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

I'm sure they're completely unbiased source. But seriously, the real question is whether lineage is more or less secure than the stock ROMs that are currently allowed.

I have read the first comment in your link and just replied to it. Pretty sure it's incorrect as I've seen a LineageOS device in September with a September security update level, and you can see in Gerrit[0] that the version string bumps are merged every month, with the commit messages including which CVEs were fixed. New images are built weekly[1].

What I think happened is that GrapheneOS assumed the blog post meant that those updates happened at the time of the post, while the post is actually announcing things that were done in the last few months.

[0] https://review.lineageos.org/q/subject:%22release:+Bump+Secu...

[1] https://download.lineageos.org/devices/frankel/builds

That's just a string, it doesn't mean that you actually have all the latest patches:

> Most non-Google-certified operating systems are setting an inaccurate Android security patch level by ignoring the non-AOSP portion of the patches. GrapheneOS doesn't do that but most of the other AOSP-based projects not being certified by Google are doing it. OEMs were caught doing it too but it's not clear if it was intentional in most cases as it is with the alternate operating systems.

https://news.ycombinator.com/item?id=49768635

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.

Not relying on security through obscurity doesn't mean obscuring things is bad for security, it just means this is not sufficient. Relying only on this or getting a false sense of security due to this would be bad.

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.

As someone who worked at a bank - some policy decisions are not driven by regulatory requirements or technical expertise.

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.

So you say there is real world data on this.

Do you have anything to back this up? What I am asking for is specifically does the usage of an OS other than the preinstalled one have a causal, direkt link with the user's bank account being attacked and money being stolen from it?

You go first.

Direct specific evidence to back up the criticism that these guys are not looking at data and just making up dumb rules to reduce their customer base.

You are making an authority argument. I and most others are not buying the validity of that authority having been subjected to insane (in)security (non)standards by banks elsewhere and one other sibling commentor even mentioning their work experience for banks as evidence.

It is on you to back up your claim.

In my career travels I am yet to find any professional group crow as confidently from on top of a hollow position as software developers. I think it has to do with daily operating from inside a deterministic environment, it gets projected out into human situations.

I take you resorting to name calling as not having any actual argument. It is always the same with this. When you ask for how this supposedly helps and what specific threats it protects against you just get vague references, gesturing in the direction of supposed authorities and the more you ask for an actual threat model the less precise and the more avoidant it gets.