Question about this. As I'm unclear about what stage of use of the API an app is at.
Alladin Connect (garage door interface) was stalling on login and I got a Play Integrity pop-up from GOS for the first time. After blocking the API it immediately logged in, so I don't think "banned" is right, it I'm unclear.
I'm preparing to write to the developers. Anything specific I should be telling them?
I suggest that maybe GrapheneOS could block this API by default, so that apps wouldn't be able to store its verdict and reuse it after manually starting to block it. Sure, it's also possible to switch off internet access/toggle off the Network permission, but some apps can only start with internet connectivity.
Watermelon That's not how it's used in practice. Blocking it also doesn't generally achieve anything and is only provided for a very narrow set of services which are using it but not yet enforcing providing a result. The main purpose of the feature is identifying the apps using it, not blocking it.
spring-onion can you please elaborate a bit on security issues? There seem to be a hot mess of opinions around it and it is hard to pick some meaningful signal in all the noise
borgo I'm in the UK and as far as I'm aware Starling Bank supports GrapheneOS. Each time it's has been broken and reported, their devs have responded saying they have been made aware of the issues and pushing a fix for GrapheneOS soon - and the fix comes about and sanity is restored.
There's even a (or multiple?) thread in this forum about it and in the GitHub repo dedicated to which banking apps work on G-OS.
I think just for that itself, these people deserve to be applauded and I've got myself and many of my folks (I've installed G-OS for as many as I could convince in my family and also among friends/colleagues) as I could to use Starling, even if they for some reason don't want it to be their main banking app. I see it similar to donating for a FOSS project or crowdfunding exercise. On top of that Starling is actually damn good banking experience.
So we should have a pin-up of all these banks (along with the country/ies they operate in) and encourage folks to give them a try. That way they have more customer base, feel it important to continue supporting G-OS and have our loyalty. That might also have an effect on other banks falling in line when they see a precedent (otherwise the banking software industry works with pre-historic constraints and herd mentality).
andzhi4 It doesn't verify the signatures which prove apps genuinely came from the play store.
GrapheneOS can you imagine any reason for why the same app (same version) would sometimes fail to open due to play integrity check and other times it would work?
spring-onion spring-onion Thank you, I see how this could be a problem. I could not help, but checked how Aurora retrieves an app. They depend on their own gPlayApi lib, which in turn has all the URLs hardcoded (GooglePlayApi.kt)
companion object {
const val URL_BASE = "https://android.clients.google.com"
const val URL_FDFE = "$URL_BASE/fdfe"
const val CATEGORIES_URL = "$URL_FDFE/categoriesList"
...So I have to somehow poison users DNS lookup, add malicious root CA to their phone and serve an exploited but very similar to original apk that would persuade them to install, launch and give necessary privileges.
Aurora also has hardcoded Google Play cert in utils/CertUtils.kt, but it is used for some edge cases with microG
const val GOOGLE_PLAY_CERT =
"MIIEQzCCAyugAwIBAgIJAMLgh0...Anyway, if Aurora Store itself is not compromised, it does not look like something a script kiddy could pull through, to put it mildly. I think, at the point where an attacker can add their own CA to your system you already waist deep in trouble and Aurora is not even on the list :).
Please correct me if I'm missing something, I did just a very quick code lookup and might have missed important pieces
So I have to somehow poison users DNS lookup, add malicious root CA to their phone and serve an exploited but very similar to original apk that would persuade them to install, launch and give necessary privileges.
No, this is not how it works.
add their own CA to your system you already waist deep in trouble and Aurora is not even on the list
This is not how this works.
Please correct me if I'm missing something, I did just a very quick code lookup and might have missed important pieces
WebPKI does not provide strong assurance that you're obtaining valid APKs. Google's own servers also have layers of trust and APK signing is far more protected than the TLS entry point.
GrapheneOS Thanks, I agree proper chain of trust is much stronger than just TLS authenticating whatever host provides you the file. But this scenario assumes that Play itself might have been compromised and serves you malicious APKs on the API, correct? Then validating APK's signature after download would raise an alarm.
Also, Aurora using reversed engineered API probably does not help the situation.
I did not receive a feedback from Yuh yet. However, I wonder if I managed to get an idea on when it happens and when it doesn't. I just had the issue again, but I also managed to enter Yuh just a moment after.
I don't have it installed on my Owner profile, but in my "Fin-Profile" (that includes Google Play Services). It seems I only have the issue when I re-enter this "Fin-Profile" and Yuh has been open already before (normally on the same day). Closing Yuh and reopening it newly usually fixes the issue.
It seems the problem therefore only arises if:
I) the profile has been running in the background
II) Yuh has been running in the background and you're re-entering
This is why it might seem "random". So it could be that this integrity API is only checked by Yuh in case it has been active and you re-enter it, but not in the actual initial start up of the app.
Do you have a similar impression? Can you confirm? Anyone any thoughts?
Had the same issue with 'Eventim' just now. Got the API error message That sucks.
