Hacker News Reader

Comment by Zak | Hacker News Reader

Without evidence that using an OS that isn't approved by Google or Apple actually correlates with a higher rate of account compromise or fraud, I do blame them for trying to force it on users.

I've done a couple casual web searches for such evidence and come up short. If somebody has good data on this, I don't think they're publishing it.

View on HN

I'm pretty sure it's actually anti correlated: not because degoogled Androids are safer by themselves, but because the average user is way savier than the average Joe (which have an out of date Android full of unpatched security vulnerabilities, in the first place).

My theory is that they're trying to counter simulated phones. In the old days fraudsters would use their stolen credentials on a windows RDP rented from someone who sells fraud infra with clean IPs. I wouldn't be surprised if fraudsters have tried to develop an android based VM meant to look like a legitimate customer endpoint.

Though the most effective way to cut out that kind of fraud is to stop using SMS for authentication, which banks don't seem to be interested in doing.

What's actually used is banks of old, used phones with broken screens, controlled via usb. They can be had for rather cheap.

Which is silly because you can get an attested phone for like $50 and factory reset it between "customers"

That's my first instinct too. I've seen a claim that devices with root, which is distinct from degoogled, both of which are distinct from using a third-party Android distribution, have an increased probability of malware. I suspect that statistic includes things like secondary devices people use for cheating in pay-to-win games and the like.

It would be interesting to see statistics comparing who 1. Byod (just gets a SIM card from the carrier) 2. Keeps updating their phone to whatever the carrier offers via billing credits 3. Just keeps using the same phone they got from the carrier when they started

Their main concern is malware not capable of exploiting OS vulnerabilities. They focus on protecting against malicious clones or modifications of their apps along with enforcing having a mandatory app sandbox and not running non-approved accessibility services, non-approved keyboards, etc.

Most of the banks don't require not being months or years behind on bare minimum Android security patches let alone requiring anything close to proper security patches. That may rapidly change in the near future due to AI accelerated exploit development making exploits far more accessible and broadly deployed.

Nearly all these apps aren't banning GrapheneOS on purpose but rather because they're doing the least possible work to implement weak anti-tampering measures. Play Integrity device or strong integrity levels are an easy way to do it. They can use strong integrity if they're willing to forbid extraordinarily insecure devices failing to meet a very low bar for security. Most banks aren't willing to do that since it would mean blocking the majority of Android devices so they use device integrity which barely does anything more than enforcing licensing Google Mobile Services to reinforce Google's monopolies. Even the strong integrity level doesn't enforce much more than that, it's mostly just much harder to bypass at scale.

Since that’s “likely” correlated (and a “likely” is often enough), a product manager will take the most optimal decision for themselves and the company - reject such use cases as unsupported. This is easier than to manage such an edge case for “a few” legitimate users.

Few orgs understand compliance. While there might be some compliance people at the org level, individual teams implementing features will need to have a good line to them. In the end, knowledge is siloed and everyone needs to deliver on time. So it’s easier to forbid with some controlled collateral damage than to permit with an uncontrolled downside variance. Just a derisking hedge.

Serving use cases that drift away a bit “too far away” from the average (+ some sigmas) use case is not economically justified for a product manager - their KPIs would deteriorate from such “altruism”. No one will care if a few low-margin customers can’t use the product.

Not using remote attestation requires exactly zero effort, but some jerk put it on a checklist and now middle managers want it.

Reply on news.ycombinator.com