[protimewaster]

Meanwhile, it's probably A-OK for the app to run on a phone that hasn't received security updates for 5 years.

I don't get it. If they're worried about liability, why not check the security patch level and refuse to run on phones that aren't up to date?

I'm guessing it's because there are a lot of phones floating around that aren't updated (probably far more than are rooted), and they're willing to pretend to be secure when it impacts a small number of users but not willing to pretend to be secure when it impacts many users.

[maxloh]

Because a phone running an unknown OS is significantly more dangerous than a phone that hasn't received security updates for years. For example, a malicious OS maker could add their own certificate to the root store, essentially allowing them to MitM all the traffic you send to the bank.

Liability works on the principle that "if it's good enough for Google, it's good enough for me." A bank cannot realistically vet every vendor, so they rely on the OS maker to do the heavy lifting.

Even if they wanted to trust a third-party OS, they would need to review them on a case-by-case basis. A hobbyist OS compiled by a random volunteer would almost certainly be rejected.

[madeforhnyo]

I can add certificates on my unrooted android. That how HTTPToolkit [0] works, it only requires adb, which (thankfully) doesn't trip banking apps. Banking apps can (and do iirc) pin certificates, so a rooted phone adds no risk whatsoever.

Also in my experience a rooted phone experience is by far more secure than the OEM androids. Security is supposed to assess risk objectively, yet "running on a Xiaomi phone with 3rd party apps that cannot be uninstalled and have system access" is somehow more secure than "running on a signed LineageOS where user can edit hosts file".

[0] https://httptoolkit.com/

[Jean-Papoulos]

>Because a phone running an unknown OS is significantly more dangerous than a phone that hasn't received security updates for years.

That's just straight-up false ; the phone without security updates has known exploits its user knows nothing about (and certainly not how to avoid them). The phone with an unknown OS has a user capable of installing said OS, at the very least.

[protimewaster]

> Because a phone running an unknown OS is significantly more dangerous than a phone that hasn't received security updates for years.

I'm not convinced this is generally true, at least as can be detected by an app. Back when I had my phone rooted, it was configured so that it would pass all the Google checks and look like the stock OS. That configuration was probably dangerous, but apps were happy with it. Now that I run an OS that doesn't lie about what it is, I'm flagged as untrustworthy. What's the point in being honest?

Overall, I don't think they really have any idea what's a threat based on the checks they're doing, so I don't think they can say at all what's more or less trustworthy. But I think that a phone that reports being years out of date should reasonably not be expected to be secure, but yet they mark it as secure anyway. Many of those devices can be rooted in a way that can still pass their checks. I would think, if nothing else, that would be reason to block them, since they're interested in blocking rooted devices.

[tadfisher]

> If they're worried about liability, why not check the security patch level and refuse to run on phones that aren't up to date?

Google doesn't provide an API or data set to figure out what the current security patch level is for any particular device. Officially, OEMs can now be 4 months out-of-date, and user updates lag behind that.

Your guess is good, but misses the point. Banks are worried about a couple things with mobile clients: credential stealing and application spoofing. As a consequence, the banks want to ensure that the thing connecting to their client API is an unmodified first-party application. The only way to accomplish this with any sort of confidence is to use hardware attestation, which requires a secure chain-of-trust from the hardware TEE/TPM, to the bootloader, to the system OS, and finally to your application.

So you need a way for security people working for banks to feel confident that it's the bank's code which is operating on the user's behalf to do things like transfer money. They care less about exploits for unsupported devices, and it's inconvenient to users if they can't make payments from their five-year-old device.

And this is why Web Environment Integrity and friends should never be allowed to exist, because Android is the perfect cautionary tale of what banks will do with trusted-computing features: which is, the laziest possible thing that technically works, and keeps their support phone lines open.

[protimewaster]

All good points. Thanks for that!

I'm not an Android developer, but I was thinking they could use something like the android.os.Build.VERSION.SECURITY_PATCH call to get the security patch level. Maybe that's not sufficient for that purpose, though.

[KoolKat23]

There's definitely some way of telling, Enterprises can block sign in with no recent updates in Microsoft authenticator or whatever app they use.

[neumann]

It's more frustrating because my partner's pixel 4A cannot use google pay or the bank apps because it is an invalid os - I am guessing due to lack of updates? So, perfectly fine hardware, but crippled in functionality due to the lack of software updates.

[crumpled]

My partner has a 4a and no such issues. Are you talking about stock Android or something else,