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. brooks+Tg2[view] [source] 2025-08-26 12:43:36
>>const_+De2
That’s a “seatbelts so no good because people still die in car crashes” argument with a topping of “actually they’re bad because they give you a false sense of security”

Play integrity hugely reduces brute force and compromised device attacks. Yes, it does not eliminate either, but security is a game of statistics because there is rarely a verifiably perfect solution in complex systems.

For most large public apps, the vast majority of signin attempts are malicious. And the vast majority of successful attacks come from non-attested platforms like desktop web. Attestation is a valuable tool here.

◧◩◪◨⬒⬓⬔⧯
8. pona-a+Yi2[view] [source] 2025-08-26 12:55:25
>>brooks+Tg2
How does device attestation reduce bruteforce? Does the backend not enforce the attempt limits per account? If so, that's would be considered a critical vulnerability. If not, then attestation doesn't serve that purpose.

As for compromised devices, assuming you mean an evil maid, Android already implements secure boot, forcing a complete data wipe when breaking the chain of trust. I think the number of scary warnings is already more than enough to deter a clueless "average user" and there are easier ways to fish the user.

◧◩◪◨⬒⬓⬔⧯▣
9. Sayrus+9o2[view] [source] 2025-08-26 13:24:32
>>pona-a+Yi2
And those apps use MEETS_DEVICE_INTEGRITY rather than MEETS_STRONG_INTEGRITY so a compromised device can absolutely be used to access critical services. (Usually because strong integrity is unsupported on old devices)

This reminds me of providers like Xiaomi making it harder to unlock the bootloader due to phones being sold as new but flashed with a compromised image.

◧◩◪◨⬒⬓⬔⧯▣▦
10. pona-a+dd3[view] [source] 2025-08-26 17:07:07
>>Sayrus+9o2
Maybe a good compromise is to change the boot screen to have a label that the phone is running an unofficial ROM, just like it shows one for unlocked bootloaders? If the system can update that dynamically based on unlock state, why can't it do it based on public keys? Might also discourage vendors/ROM devs from using test keys like Fairphone once did.
◧◩◪◨⬒⬓⬔⧯▣▦▧
11. drewbu+Mg3[view] [source] 2025-08-26 17:23:38
>>pona-a+dd3
Pixels with, for example, GrapheneOS already do exactly that:

"Your device is loading a different operating system."

[go to top]