Play Protect really is the root of all evil, Google certainly seems to be incentivized to write services like Play Protect that effectively act like malware/spyware in order to force users to see more ads by making it as difficult as possible to run effective system wide ad-blockers on mobile devices by crippling the ability of users to run non-Google sanctioned code on their devices at high enough privilege levels. They've deliberately designed Play Protect for maximum user hostility instead of trying to come up with ways to provide security while maintaining user freedom. For example they could have instead implemented much stronger sand-boxing of apps so that apps would have as little knowledge as possible regarding what type of environment they are running in, similar to webapps, yet they chose the exact opposite approach and went out of their to prevent users from restricting app permissions/system visibility deliberately.
Additionally the sideload blocking plan they published seems to be effectively Google deliberately using installation whitelisting in order to prevent users from removing ads from apps with tools like revanced(revanced is an APK patcher and relies on the ability to effectively self sign/install APK's without googles approval if running on bootloader locked devices).
These elaborate user hostile schemes of theirs even uses similar dubious technical justifications as manifest V3's ad-block crippling did for Chrome.
> GrapheneOS can not do anything about that.
I mean, they could help write exploits to help users bypass the Play Protect malware/spyware I suppose, although that probably doesn't align with their goals. I'm really not sure what other practical options there are in regards to fighting these malicious spyware services that Google wants to force on everyone.
Since Google doesn't have effective full control over the Android hardware supply chain like Apple does undermining the Play Protect spyware scheme should be much easier as one probably just needs to come up with some key extraction attacks against certified Android devices with terrible hardware security(lot of cheap Chinese SoC's used in Android phones that have rather poor cryptographic key protections). In theory one can then use extracted attestation keys to emulate a secure boot chain in software on other devices along with sufficient sandboxing to trick Play Protect into thinking it's running on a Google sanctioned bootloader locked device even when running with a custom OS.
GrapheneOS does not include any of the Google apps that implement Play Protect. You can install them, but they run in the sandbox like normal apps and so are not highly privileged. They are unable to block installation of apps, install apps or uninstall apps as they are on stock Androids
> GrapheneOS does not include any of the Google apps that implement Play Protect. You can install them, but they run in the sandbox like normal apps and so are not highly privileged. They are unable to block installation of apps, install apps or uninstall apps as they are on stock Androids
The issue is more that GrapheneOS still allows apps to view OS attestation information[0], which is similar how Play Integrity API attempts to prevent you from running on your own OS. The specific feature I'm referring to which is the problem is the Play Protect API which allows apps to inspect the host system bootloader/TPM state essentially. The problems with giving any apps(even webapps) access to this sort of attestation information are well documented[1] as it encourages app developers to lock out legitimate users who want to run unofficial operating systems. Effectively breaking this app verification capability is what is needed to prevent app developers from enforcing arbitrary security requirements on the host OS. Essentially GrapheneOS just wants app developers to trust their keys in the same way Google wants you to trust theirs(using the Play Integrity API).
Play Protect really is the root of all evil, Google certainly seems to be incentivized to write services like Play Protect that effectively act like malware/spyware in order to force users to see more ads by making it as difficult as possible to run effective system wide ad-blockers on mobile devices by crippling the ability of users to run non-Google sanctioned code on their devices at high enough privilege levels. They've deliberately designed Play Protect for maximum user hostility instead of trying to come up with ways to provide security while maintaining user freedom. For example they could have instead implemented much stronger sand-boxing of apps so that apps would have as little knowledge as possible regarding what type of environment they are running in, similar to webapps, yet they chose the exact opposite approach and went out of their to prevent users from restricting app permissions/system visibility deliberately.
Additionally the sideload blocking plan they published seems to be effectively Google deliberately using installation whitelisting in order to prevent users from removing ads from apps with tools like revanced(revanced is an APK patcher and relies on the ability to effectively self sign/install APK's without googles approval if running on bootloader locked devices).
These elaborate user hostile schemes of theirs even uses similar dubious technical justifications as manifest V3's ad-block crippling did for Chrome.
> GrapheneOS can not do anything about that.
I mean, they could help write exploits to help users bypass the Play Protect malware/spyware I suppose, although that probably doesn't align with their goals. I'm really not sure what other practical options there are in regards to fighting these malicious spyware services that Google wants to force on everyone.
Since Google doesn't have effective full control over the Android hardware supply chain like Apple does undermining the Play Protect spyware scheme should be much easier as one probably just needs to come up with some key extraction attacks against certified Android devices with terrible hardware security(lot of cheap Chinese SoC's used in Android phones that have rather poor cryptographic key protections). In theory one can then use extracted attestation keys to emulate a secure boot chain in software on other devices along with sufficient sandboxing to trick Play Protect into thinking it's running on a Google sanctioned bootloader locked device even when running with a custom OS.