Email or username:

Password:

Forgot your password?
Top-level
Andreas K

@hackbod

And before you say it's about security. BS.

You can run your online banking and your driving license app from our interior ministry on an android that has not been patched for 3 years.

On such a phone, Malware can probably get root access via long list of known CVE. But it verifies as "manufacturer-provided-bootloader-locked" so everyone pretends that it's safe.

If Google cared about safety, they would check the patch level.

@Lillian_C14 @didek

16 comments
Andreas K

@hackbod
Or even better, the libraries that check for a safe device would check for the patch level and then for the most important security bugs.

But that would achieve security which nobody is interested in, right?
@Lillian_C14 @didek

Dawid Rejowski

@yacc143 @hackbod @Lillian_C14

Google have SafetyNet that is triggered when you uninstall preinstalled Facebook or YouTube from the phone, but not when OS is 5 years old.

Not that checking if device is old will be a good idea eather...

Andreas K

Actually checking how old the software is, would be probably not such a bad idea. But it would force giggle partners to provide security updates.

The EU will do that in the next years (effectively from 2025 for 5 years I seen to remember), but Google could do that too. They don't.

Dianne Hackborn

@didek

Not sure what you mean SafetyNet being triggered when uninstalling apps? Though I don't know what OEMs are doing on their devices, Pixel doesn't come with Facebook pre-installed and YouTube is pre-installed on the system image so you can't really uninstall it.

Maybe this is some specific OEM doing something odd on their device? Which device do you see it on? What is the experience caused by SafetyNet being triggered?

Dawid Rejowski

@hackbod

This wasn't direct or serious.
What I mean is unlocking the capability to even uninstall these apps first, unlocking bootloader and deleting the apps from system partition.

Dianne Hackborn replied to Dawid

@didek

Ah okay! I don't think you will ever get the ability to delete things from the system partition, because (1) that is always read-only (only modified by the boot loader and that is important), (2) it would mean factory reset couldn't return you to the original state, and (3) even if you did, you couldn't use the space because it would only free that space in the system partition, not data partition.

OEMs are encouraged to use Play Auto Install instead.

Dianne Hackborn

@yacc143

Ah so you are not talking about the source code, but the anti-abuse features.

It is important to understand that this is not Google pushing stuff, but addressing developer demand. That is, the choice is not "Either Google provides SafetyNet or apps don't do anything," it is "Either SafetyNet or apps instead use other 3p solutions that are more fragile and problematic." In fact growing use of 3p solutions has made Android dev problematic as they break with each new platform version.

Dianne Hackborn

@yacc143

By and large I don't think Google uses SafetyNet for its own apps, because it isn't seen as so necessary... except for stuff like contactless payments. And there is no way you would have contactless payments without device integrity verification.

I also find it frustrating how much app developers feel the need to protect themselves from the platform with this stuff, but I don't see how to generally convince them otherwise. (And Apple's Android security FUD doesn't help.)

Andreas K

@hackbod Ah, but the point is:

Google requires manufacturers to provide the hardware functionality for a PlayStation level verification. Or they do not get the Google apps.

OTOH, Google does not educate developers on correct security practices (as in check how fresh the security patches are, or even use a library that actively checks for exploits, instead of “verifying” that your user is running an unsecure 3 years old Android).

Because that would cause havoc for their business.

Andreas K

@hackbod Actually, with some tender love and care, my custom rom, with root, does Google Pay.

And you won't believe it, nobody was defrauded because, shock, it's me, the owner who rooted the device. Not some malware. If I wanted to defraud anybody, I could read up on all the beautiful design faults in the EMV protocol that the payment industry managed to design into it.

Google is not very anal about verification.

But by not taking a stand, and not doing the right thing, they are spreading it.

Andreas K replied to Andreas

@hackbod So what exactly is Google fearing if Google Pay is running on a Custom ROM?

The EMV protocol is meant to be cryptographically secure, and I'd hope that you store the card credentials on the secure hardware enclave that all Androids must have due to Google requirements.

So what threats exactly is Google protecting against by doing a verification?

Andreas K replied to Andreas

@hackbod I mean I do online banking all the time on a Fedora Linux laptop, with, *gasp*, Secure Boot disabled.

(Btw, SMS is still legal as a 2FA authentication under the current EU payment directive. While banks tend to force (“guide”) users into “smart apps”, the initial handshake still happens via SMS.)

Andreas K replied to Andreas

@hackbod So tell me because you said, “And there is no way you would have contactless payments without device integrity verification”.

Against what threats does that device integrity verification protect the user/system? The secrets are in the secure hardware enclave in mobile. The EMV protocol is designed to be cryptographically secure.

You should be able to publish the traffic on the Internet, and nothing bad happens.

You should be able to modify the traffic and the payment fails.

Dianne Hackborn replied to Andreas

@yacc143

Okay given the false equivalence between Android and PlayStation; blanket dismissal of modern best practices of hardware security modules for software validation, at rest encryption and authentication and biometrics protection; and ignoring my points about the expectations and requirements of app developers... it seems clear there isn't really much opportunity for a discussion, so I am going to bow out.

Andreas K replied to Dianne

@hackbod You still have not explained which threat Google Pay protects against by verifying that the mobile is untampered, but not checking that the security patch levels are up to say in the past 12 months.

And yes, Googlified Android gives App developers the tools into their hands to validate the whole system chain starting with the boot loader to the app. You call it “best practices in hardware security”. I call it Playstation style lock down.

Andreas K replied to Andreas

@hackbod You seem to forget that the newer "free software licenses" explicitely deal with the issue of the "freedom" of the user being able to modify the software and apply it to his device.

What's the point of that freedom, if you make sure that "best practices" include making sure that the open source Custom ROM cannot run most of the software for the platform?

So explain what's the threat for the Google Pay running on a Custom ROM?

Go Up