[Android Software Development] TraderJack:
It sounds like we are on the same page with most everything, but here. Make sure you read my two other posts here:

https://xdaforums.com/t/magisk-module-universal-safetynet-fix-2-3-1.4217823/post-87199657

https://xdaforums.com/t/magisk-module-universal-safetynet-fix-2-3-1.4217823/post-87199685

This is where I am defending the idea that the chart's entry for just MEETS_BASIC_INTEGRITY doesn't make a lot of sense in the context of the rest of the documentation, so when I say in my above quote MEETS_BASIC_INTEGRITY and MEETS_STRONG_INTEGRITY I am referring to the last two rows in the chart that are inclusive of MEETS_DEVICE_INTEGRITY.

My two threads above make the argument that MEETS_DEVICE_INTEGRITY must always be returned if a pass, regardless of which additional label it has.

I am still not 100% on this, but I can only go with what the docs are showing right now and they are not very good docs.

Yes. But according to my second of the two follow up posts I link above, it isn't even clear how STRONG_INTEGRITY is called based on the Play Store options that can be configured. Some of this may not be configurable with options in Play Store but have to be coded within the app to make the decision. That would make sense in the case of GPay where it clearly allows you to download it, but within the app it is restricting features based on the API call. That is a code path each dev needs to make in their app and not just a Play Store option.

I agree with your conclusion, except that I think some banks may actually want to prohibit users. For a while many features in my Chase app (like mobile deposit) wouldn't work even when I passed SN (not sure if they changed the app or I configured something different). Slightly different (because Apple controls hardware more), but my mother couldn't even use her older iPhone because the bank apps refused to install.

So, while I see your logic, not sure it will work out in our favor when all is said and done.

Maybe (?..?..?). I mean clearly all of these measures have to do various checks on the local system to determine if it meets certain criteria. SafetyNet certainly changed over the years to add different check. These bypasses were implemented by Magisk (Hide), USNF, and MHPC and for the most part we have been able to feed SN what it wanted in order to pass Basic Attestation. I see no reason that they couldn't have added additional checks to SN, or that the current checks in PI-API are the same that SN was using. It is the additional features they wanted to implement that made them move towards the new API.

After all, if they have some amazing new way to detect stuff, they could have just updated SafetyNet. The only new and amazing thing they really introduced was Hardware Attestation, and when they fully implement it (as opposed to opportunistically) on every device which truly supports it, we will be out of luck.

And these are the main new features I'm talking about. These should certainly tamp down on cracking apps or getting them sideloaded. Probably still won't help with all the "mod apk" files where they can probably strip out the API call all together. Still, this should be a boon to developers who use them but aren't the main gist of what is going to cause problems in context of our conversation here. Let's assume all the apps we are using are licensed for our use.

I believe that is correct. We still need to pass Basic Attestation and USNF allows us to do that.

It isn't clear that 11+ needs more props, etc spoofed. This may just be an issue with the ctsProfileMatch and Google still only enforcing HA opportunistically for some profiles and not others.

Also, as we saw with the HA rollout a year or so ago it seemed inconsistent for a while. People might be hitting different servers which are not in sync and they may be having a lot of changes (maybe even an AI tuning it) so that we might see inconsistencies at first.

So when you say "further spoofing", I'm not sure if my Pixel 3XL 12 will *ever* pass Play API without changing the fingerprint because Play API will require HA, not just suggest it. That being said a USNF/MHPC fix (or new app) that can inject fingerprint and other prop settings via zygisk to specific processes (option and process configurable) may be the best way to combat this. If so, I think that as long as we can present a phone that isn't able to do HA we should not be required to present MEETS_STRONG_INTEGRITY.

The only problem then is (as we discuss above) is what happens when GPay, Chase, and others are going to say "sorry you need a device that does HA in order to use this feature). We probably have at least another 2-3 years before they enforce that, but it will be the way they go. We just need the next wizard to figure it out from there :)