microg
Vending: Added PI access management
New:
- Access to the Play Integrity API by third-party apps can be controlled on the microG Settings page.
- Displays the most recent Play Integrity API access result.
- When an IntegrityToken retrieval error occurs, the last successful result is returned.
Why not just rename the SafetyNet option to Play Integrity and merge all code together? In my opinion it don't make sense to have one enabled and one disabled.
Also the base SafetyNet is dead, the remaining code is probably just used as part of Play Integrity.
SafetyNet, Play Integrity and ReCaptcha Enterprise all share the use of DroidGuard. The current "Allow device attestation" toggle in the SafetyNet section already controls DroidGuard (and thus effectively Play Integrity). Best forward would be to:
- Rename the SafetyNet section to "Device Attestation"
- Integrate Play Integrity with the existing system used for SafetyNet and ReCaptcha.
Having a dedicated Play Integrity is indeed confusing.
Thanks for the reminder, which made me confirm my previous modification plan.
Only add extra code to the existing code; whether or not to delete previous code is determined by mar-v-in.
@mar-v-in I wonder if it is possible to "proxy" the requests done by apps with the old SafetyNet code to the new Play Integrity so that old apps may still works.
NOTE: Even if the "proxy" code is NOT perfectly valid, as long as the app believe it it is fine.
@ale5000-git that's not possible, the format of those two are different and we can't migrate them as they're signed cryptographically.
@mar-v-in What about returning the new format response in the old format request? Maybe there are apps that just check if the response signature is valid and not the content (just a guess, not tested)
I don't think they even use the same signing key, so that wouldn't work either.
Apps that use SafetyNet are dead, I don't think it's worth the effort for us to try getting a few of them running that have a terribly broken implementations.
@mar-v-in My final suggestion is this:
- For the parts of code that still works, keep them;
- Instead for the parts of codes that always fails (and can't be fixed) change them to NOT doing a real request but just behave like the device has NO internet connection so they can at least degrade gracefully.
(maybe also keep documentation of the previous behaviour as code comments; remember that Google change their mind pretty fast)
For bank apps the user may have to use an old version because the new version removed support for some Android versions; and the app may still work (with a warning displayed to the user) even if SafetyNet fails but if the code is removed completely then the app may crash.
When an IntegrityToken retrieval error occurs, the last successful result is returned.
@DaVinci9196 The token has a nonce, an old token can only be a valid response to a new request if it has the same nonce as the previous request. Either add logic to ensure the token is only returned for requests with the same nonce (which should never happen, a nonce is meant to be only used once) or just completely remove this part from the PR.
When an IntegrityToken retrieval error occurs, the last successful result is returned.
@DaVinci9196 The token has a nonce, an old token can only be a valid response to a new request if it has the same nonce as the previous request. Either add logic to ensure the token is only returned for requests with the same nonce (which should never happen, a nonce is meant to be only used once) or just completely remove this part from the PR.
The initial intention of this approach was to resolve the 429 exception issue caused by frequent requests, but it seems that the previous scope was too broad. The scope has now been modified to be limited to the sync request.