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. Ashame+nd3[view] [source] 2025-08-26 17:07:42
>>brooks+Tg2
Great. Let's just require every single computing device to be verified, signed, and attested by a government agency. Just in case it is ever misused to attack a Google online service that cannot be possibly bothered to actually spend one nanosecond thinking on security.

What could possibly go wrong. It's not only morally questionable no matter what "advantages" it provides Google, but it's also technically ridiculous because _even if every single computing device was attested_, by construction I can still trivially find ways to use them to "brute force" Google logins. The technical "advantage" of attestation immediately drops to 0 once it is actually enforced (this is were the seatbelts analogy falls apart).

Next thing I suggest after forcing remote attestation on all devices is tying these device IDs to government-issued personal ID. Let's see how that goes over. And then for the government to send the killing squad once one of these devices is used to attack Google services. That should also improve security.

Here's the dystopian future we're building, folks. Take it or leave it. After all, it statistically improves security!

◧◩◪◨⬒⬓⬔⧯▣
9. brooks+3E3[view] [source] 2025-08-26 19:24:01
>>Ashame+nd3
You just proved the seatbelt analogy.

Yes, for SOME subset of attackers (car crashes), for SOME subset of targets (passengers), the mitigations don’t solve the problem.

This is not the anti-attestation / anti-seatbelt argument many think it is.

All security is mitigation. There is non perfection.

But it makes no sense to say that because a highly motivated attacker with a lot of money to spend can rig real attested devices to be malicious, there must be no benefit to a billion or so legit client devices being attested.

I think your enthusiasm for melodrama and snark may be clouding your judgment of the actual topic.

◧◩◪◨⬒⬓⬔⧯▣▦
10. Ashame+hJ3[view] [source] 2025-08-26 19:43:55
>>brooks+3E3
> Yes, for SOME subset of attackers (car crashes), for SOME subset of targets (passengers), the mitigations don’t solve the problem.

I won't solve the problem for _anyone_ once it is required, because it is trivial to bypass once the incentive is there. This is what kills this technically; it does not even go into the other cons (which really should not be ignored). Seatbelts absolutely do not have this problem.

> All security is mitigation. There is non perfection.

This is an absolutely meaningless tautology. It is perfectly true statement. It adds absolutely nothing to the discussion.

Say I argue in favor "putting a human to verify each and every banking transaction with a phone call to the source and the destination". And then you disagree, saying that there will be costs, waste of time for everyone, and that the security improvement will be minimal at best. And then I counter with "All security is mitigation, there is no perfection!".

Can you see what you're doing here? This is another textbook example of the politician's fallacy (something must be done; this is something; therefore we must do this).

It is trying to bypass the discussion on the actual merits of the proposal as well as its cons by saying "well it does something!" . True, it does something. So what? If the con is bad enough, or if the benefit too small, maybe it's best NOT to do it anyway!

> But it makes no sense to say that because a highly motivated attacker with a lot of money to spend can rig real attested devices to be malicious, there must be no benefit to a billion or so legit client devices being attested.

Not long we had right here in HN a discussion about the merits of remote attestion for anti-cheating: turns out the "lot of money" is a custom USB mouse (or addon to one) that costs cents to make. Sure, its not zero. You have to go more and more draconian in order to actually make it "a lot of money", but then you'll tell me I'm being melodramatic.

[go to top]