@blogdiva I also would walk away if I feel I am being used to launder secret deals. Did not have to, so far.

If it turned out that biometrics data was leaking from one of our SoCs (to the OS or cloud), that would be a high severity security issue that we would scramble to fix.

There is still the caveat that we only build chips and not end devices, so you also need to worry about the device manufacturers' secret deals, I suppose.

@blogdiva It is for detecting physical presence. Biometrics tell the phone you are present and unlocking the device and not someone else who shoulder surfed your PIN.

This can be a bug or a feature depending on one's threat model. My daughter can unlock my phone while I am sleeping to play games, or LE can point it to my face to get into it (this is also why lockdown mode was invented).

It still helps a significant percentage of users, who would otherwise use 1234 for their pins, to be more secure.

@vervain too bad I know what I am talking about, as this is part of my job at Qualcomm. I am not saying Google is not trying to track you or fingerprint you or determine your identity. What I am saying is that "this particular change" is not meant for that.

There is a side effect which may lead to more side-loading people enabling biometrics on their devices. I do not think this is the motivation behind this change, and you may call me naive for that.

Here is what I think what happened:
Google had many, mostly business, reasons, to disable side loading. I do believe, however, that there were a significant number of cases where people were tricked into sideloading malware or spyware [*], and this was one of the reasons why, when they walked back, their security folks asked for these changes to reduce misuse.

@blogdiva

[*] I don't have numbers but I can try to find out.

@blogdiva otherwise, I agree that biometrics have drawbacks. For instance, users can be made to unlock their devices through biometrics, but usually cannot be made to disclose passwords they know (in theory). This is a different, but valid threat model. Not the one they seem to be worried about.

I think it should still be fine to disable biometric auth once you enable side loading though. It may also be possible to enroll other parts of your (or others') bodies during the process to make it more fun.

@blogdiva yes, it is literally my job to make sure.

Google components like KeyMint interface with biometrics components from device and SoC vendors, but the OS, including the kernel is not involved in biometrics process at all. It cannot interfere with what sensors capture or how matching is done. It cannot read the biometric templates stored on the device either.

Individual device manufacturers may end up building less secure solutions, but the whole design assumes Google components do not have access to biometrics. Just the matching results.

@blogdiva biometric enrollment and authentication happens in the device. The biometric information never leaves the device [*]. As far as I can tell, this proposal does not change this behavior.

They ask for biometric auth to make sure the user enabling the feature is the person who enrolled their biometrics earlier, and is present physically, and not someone who managed to steal/guess your password or pin.

The delay is to reduce the possibility of a malicious app or site tricking the user into authenticating themselves one time and immediately installing a malicious app or something.

This does not mean I fully agree with what they are doing, but I am pretty sure they are not doing this to collect biometrics [**].

[*] This is a bar/promise set by iPhone when they first introduced biometric authentication years ago. A lot of effort goes into making sure biometric auth happens confidentially on the device. There are many other biometric authentication systems out there where the matching happens in the cloud. Phones do it all on device.

[**] They can collect biometrics from Google photos if they wanted to, like Facebook/Meta has apparently been doing for years on Facebook photos.