Recent searches
Search options
@AlgoCompSynth @arclight There absolutely is. Any phone running @postmarketOS (completely non Android) or @GrapheneOS or most other non-vendor deGoogled Android) would be an example. Even stock Android rooted lets you block or spoof location to apps.
We're going to be adding a Location Scopes feature soon similar to our Contact Scopes and Storage Scopes to replace Mock Location. Mock Location works but requires a dedicated app and is global when people probably usually only want to do it for specific apps rather than breaking location detection for Organic Maps or whatever else they use for maps/navigation, etc.
Mock Location has an API to detect using it but there's no point hiding it since apps would ban GrapheneOS.
Our own Location Scopes feature would be a separate thing so there's no reason the Mock Location API would need to show it as enabled. Location would not be coming from a Mock provider, so it doesn't make sense to set that. This would make it more compatible.
To avoid apps like Pokemon Go banning GrapheneOS, we could provide our own API to detect it which the vast majority of apps wouldn't use. Only apps which ban an alternate OS and decide to special case some would use it.
Standard Android does have the Mock Location feature. The issue is that apps can detect it and ban other OSes, which apps like location-based games are doing and are increasingly using Play Integrity's strong tier.
Most of these apps are already banning using GrapheneOS. A tiny minority are whitelisting the official builds. For user builds, they might as well turn off letting apps see Mock Location or Location Scopes is active, but we'd like official ones to not be banned.
@GrapheneOS @arclight OSs targeted like this need a hot patching feature to remove the detection from such malicious apps.
@dalias @arclight The apps are almost all using the Play Integrity API to disallow using any non-Google-certified OS where Google certified means licensing Google Play and complying with rules such as not allowing spoofing location without the app knowing. It's possible to spoof the lower tier of the Play Integrity API but it's not possible to keep it working consistently so it's not a solution we can use. The higher tier blocks spoofing, you'd need a supply of leaked keys they'd keep banning.
@dalias @arclight Currently, the situation is that these apps tend to ban GrapheneOS in the first place. The services check the results of the Play Integrity so modifying the app can't deal with it. In a few cases, we've convinced some banks and other apps to either stop doing this because it's misguided or to specifically whitelist GrapheneOS by verifying it with hardware attestation themselves. It's really hard to convince app devs to care since it's < 1% of their users being blocked.
@dalias @arclight We have failed to convince most apps devs to either remove it or whitelist GrapheneOS. Our understanding is that most of the banks are doing it because they are required by some of the regulations to check device integrity. Using Google's approach is less work and avoids them potentially being liable for doing it poorly. Governments heavily reinforced anti-competitive behavior by Google through these regulations rather than regulating against anti-competitive behavior.
@dalias @arclight In practice, we need to start by having our users file endless bug reports, 1 star reviews, etc. with the apps to get on their radar. We need to convince them to either remove the Play Integrity API checks based on them having absolutely no security value or if that doesn't work convince them to follow https://grapheneos.org/articles/attestation-compatibility-guide as a fallback approach. Many of these companies are outsourcing all their development. They may not even know they are doing these checks or want them.
@dalias @arclight It's quite awful and the approach doesn't scale. We need regulators to either disallow the entire approach and only permit pinning-based hardware attestation unable to be used in an anti-user way like root-based attestation (which is incredibly unlikely) or at least force Google to open up their system and force it to be based on actual security properties verified by a third party WITHOUT delaying our updates for certification. Google shouldn't get to make the rules.
@dalias @arclight https://source.android.com/docs/compatibility/15/android-15-cdd is the overall set of rules. It largely has nothing to do with security. It even has a bunch of rules which are anti-security or anti-privacy through forbidding making the kinds of privacy/security improvements Google makes themselves with each yearly release. They prevent others from innovating in a bunch of areas. Several of our privacy and security features already violate these rules including adding our Sensors and Network toggles.
@dalias @arclight We don't think our Contact Scopes and Storage Scopes violate the current set of rules but we aren't familiar with all of them. It would not be possible for a regular Android OEM licensing Google Play to implement either of those things because Google requires them to ship the Google's official builds of the unmodified Android Open Source Project Mainline modules for the Permission Controller and a bunch of other things.
@dalias @arclight Look at this requirement:
> [C-0-2] MUST NOT have a visible user interface when a security violation is detected and successfully blocked by the security feature implemented below the Android framework
We've added our own user-facing crash reporting system which helps users report bugs to us and to app developers. For example, if there's a kernel panic or hardware-level lockup, that gets reported after the reboot. We filter some sensitive stuff out and there's a copy button.
@dalias @arclight We have special notifications for memory corruption detected by hardened_malloc and through hardware memory tagging which help users report issues and work around buggy apps since they know why it crashed. It also informs people of real world attacks which were blocked. It's ridiculous to say we can't report stuff like detected memory corruption to users with zero false positives. There is a whole lot of stuff like that we disagree with and that is what certification is about.
@dalias @arclight Overall, extremely few apps are using the Play Integrity API. Nearly all apps doing stuff like trying to block location spoofing are using it along with banking apps which either wrongly believe it helps security or are simply required by regulation to check device integrity. Some countries even in Europe have laws which essentially only permit allowing iPhones or Google certified Android phones because they are the only 2 approved options for integrity checks. It's ridiculous.
@dalias @arclight Some of the banks we talked to said they'd love to add GrapheneOS because lots of people ask for it. However, they cannot do it without an approved way of checking device integrity. Since it tends to be per-country and quite complex, it's unrealistic for us to do it. We could in theory just make our own certified system for checking integrity based on hardware attestation but it's per-country and expensive...
We're actively talking to the EU Commission about all this.
@dalias @arclight Our stance is that Google should be forced to allow alternative operating systems to pass verification if they apply for it unless they can prove they do not meet the same security standards as the worst devices they permit to pass. It's a complete joke to allow a device with no security patches for 8 years but pretend as if a device that's far more secure than even the most secure certified device (stock Pixel OS) is somehow not meeting their security standards.