zlacker

[return to "Google will allow only apps from verified developers to be installed on Android"]
1. arielc+542[view] [source] 2025-08-26 11:11:45
>>kotaKa+(OP)
Meaning to use your device you need to have a contractual relationship with a foreign (unless you are in the US) third party that decides what you can or cannot do with it. Plus using GrapheneOS is less of an option every day, since banks and other "regulated" sectors use Google Play Protect and similar DRMs to prevent you from connecting from whatever device you want. Client-side "trust" means the provider owning the device, not the user.

Android shouldn't be considered Open Source anymore, since source code is published in batches and only part of the system is open, with more and more apps going behind the Google ecosystem itself.

Maybe it's time for a third large phone OS, whether it comes from China getting fed up with the US and Google's shenanigans (Huawei has HarmonyOS but it's not open) or some "GNU/Linux" touch version that has a serious ecosystem. Especially when more and more apps and services are "mobile-first" or "mobile-only" like banking.

◧◩
2. pimter+V42[view] [source] 2025-08-26 11:20:21
>>arielc+542
I think Play Integrity is the fundamental issue here, and needs to go. That's the crux of the issue.

Allowing apps to say "we only run on Google's officially certified unmodified Android devices" and tightly restricting which devices are certified is the part that makes changes like this deeply problematic. Without that, non-Google Android versions are on a fair playing field; if you don't like their rules, you can install Graphene or other alternatives with no downside. With Play Integrity & attestation though you're always living with the risk of being cut off from some essential app (like your bank) that suddenly becomes "Google-Android-Only".

If Play Integrity went away, I'd be much more OK with Google adding restrictions like this - opt in if you like, use alternatives if you don't, and let's see what the market actually wants.

◧◩◪
3. avhcep+X52[view] [source] 2025-08-26 11:30:25
>>pimter+V42
Banks seem to actually "want" Play Integrity. At least they act like it. I bet they would like for normal online banking on user-controlled devices to completely go away.
◧◩◪◨
4. IshKeb+g82[view] [source] 2025-08-26 11:47:23
>>avhcep+X52
Only because it's there. I don't think the would demand it if it wasn't offered, but once it's there imagine being in a bank and saying to management "it recommend we don't enable this security feature that works on 99.99999% of phones".
◧◩◪◨⬒
5. mhast+ua2[view] [source] 2025-08-26 12:03:38
>>IshKeb+g82
As someone who used to work for a bank building applications I would say no. This is definitely a feature companies and organizations like banks would request if it wasn't available.

There are a lot of scams targeting vulnerable people and these days attacking the phone is a very "easy" way of doing this.

Now perhaps there is a more forgiving way of implementing it though. So your phone can switch between trusted and "open" mode. But realistically I don't think the demand is big enough for that to actually matter.

◧◩◪◨⬒⬓
6. const_+De2[view] [source] 2025-08-26 12:30:22
>>mhast+ua2
Play integrity does almost nothing to prevent malicious actors. In fact, id say overall it's probably more harmful because it gives actors like Banks false confidence.

Even with play integrity, you should not trust the client. Devices can still be compromised, there are still phony bank apps, there are still keyloggers, etc.

With the Web, things like banks are sort of forced to design apps that do not rely on client trust. With something like play integrity, they might not be. That's a big problem.

◧◩◪◨⬒⬓⬔
7. mike_h+2k2[view] [source] 2025-08-26 13:02:44
>>const_+De2
I've worked on such systems. Love it or hate it, remote attestation slaughters abuse. It is just much harder to scale up fraud schemes to profitable levels if you can't easily automate anything. That's why it exists and why banks use it.
◧◩◪◨⬒⬓⬔⧯
8. const_+4E2[view] [source] 2025-08-26 14:40:29
>>mike_h+2k2
1. I don't believe you. This is a measurement problem - you eliminated an avenue to measure abuse, because you are now just assuming abuse doesn't happen because you trust the client.

2. It does not eliminate any meaningful types of fraud. Phishing still works, social engineering still works, stealing TOTP codes still works.

Ultimately I don't need to install a fake app on your phone to steal your money. The vast, vast majority of digital bank fraud is not done this way. The vast majority of fraud happens within real bank apps and real bank websites, in which an unauthorized user has gained account access.

I just steal your password or social engineer your funds or account information.

This also doesn't stop check fraud, wire fraud, or credit card fraud. Again - I don't need a fake bank app to steal your CC. I just send an email to a bad website and you put in your CC - phishing.

◧◩◪◨⬒⬓⬔⧯▣
9. mike_h+VJ2[view] [source] 2025-08-26 15:02:13
>>const_+4E2
1. Well, going into denial about it is your prerogative. But then you shouldn't express bafflement about why this stuff is being used.

Nobody is making mistakes as dumb as "we fixed something we can measure so the problem is solved". Fraud and abuse have ground-truth signals in the form of customers getting upset at you because their account got hacked and something bad happened to them.

2. This stuff is also used to block phishing and it works well for that too. I'd explain how, but you wouldn't believe me.

You mention check fraud so maybe you're banking with some US bank that has terrible security. Anywhere outside the USA, using a minimally competent bank means:

• A password isn't enough to get into someone's bank account. Banks don't even use passwords at all. Users must auth by answering a smartcard challenge, or using a keypair stored in a secure element in a smartphone that's been paired with the account via a mailed setup code (usually either PIN or biometric protected).

• There is no such thing as check fraud.

• There is no such thing as credit card phishing either. All CC transactions are authorized in real time using push messaging to the paired mobile apps. To steal money from a credit card you have to confuse the user into authorizing the transaction on their phone, which is possible if they don't pay attention to the name of the merchant displayed on screen, but it's not phishing or credential theft.

◧◩◪◨⬒⬓⬔⧯▣▦
10. jofla_+qS2[view] [source] 2025-08-26 15:41:43
>>mike_h+VJ2
Well it is still a phone after all, what with UMA and baseband processing. You don't need to spend much time at Blackhat/Defcon to realize any true attempts at sealing it up are akin to plugging leaks in a sieve with epoxy. Its far too porus.

Meanwhile if attestation does reduce fraud, the ownability (by the user) of the device is now forfeit due to chasing a dragon's tail.

[go to top]