The article unfortunately leaves out most of the points we made in the thread.
GrapheneOS supports hardware-based attestation and it's entirely possible for Google to allow it as part of the Play Integrity API. They choose to ban using GrapheneOS.
@GrapheneOS extraordinary claim. Where's the extraordinary evidence?
@GrapheneOS thanks for clarification on what you meant. Do you know if "real world" results are aggregated anywhere?
This sounds a bit like diesel-gate?
@falken Google CLAIMS that the Play Integrity API is based on certification by the Compatibility Test Suite. They also disallow OEMs launching devices not certified as passing the CTS and CDD which are based on AOSP which is aimed at preventing new players in the market such as GrapheneOS. South Korea outlawed the latter as an anti-competitive practice, and it's almost certainly going to get outlawed in the EU too. They're very likely going to get in huge trouble for all of this in the EU.
@falken We need the EU to focus on the Play Integrity API specifically and accelerate dealing with it because it's causing a growing amount of harm to operating systems not bundling privileged Google Play integration licensed from Google.
Worth noting that we are not talking about inconsequential CTS test failures or buggy tests with spurious failures. Pixels have some of failures like that, but it's not what we mean. We mean actually clear failures to comply and tests legit failing.
@falken Google uses the CTS and CDD to push a bunch of things unrelated to compatibility and security. They use it as a way to exert control. They disallow adding many kinds of privacy and security features via the CTS and CDD. However, they often add these previously disallowed features in new Android releases and they usually even make including them into CTS and CDD requirements if they don't require special hardware support. They want to be the only ones able to innovate in certain ways.
@falken Here's the current CDD for Android 14:
https://source.android.com/docs/compatibility/14/android-14-cdd
As an example, the CTS FORBIDS adding new regular permissions such as our Sensors and Network toggles, despite us taking great effort to preserve app compatibility by returning zeroed data from sensors just like their Sensors Off toggle in developer options and pretending the network is simply down for the Network toggle. They disallow showing user-facing security notifications as we do too, among various other things.
@falken 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, but MAY have a visible user interface when an unblocked security violation occurs resulting in a successful exploit.
This essentially forbids our special crash notifications for hardened_malloc protections and hardware memory tagging which help users deal with it and report issues.
This includes disallowing adding new security features that are configurable, unless it's supposed to be implied that it only applies to standard Android security features:
> [C-0-3] MUST NOT make SELinux or any other security features implemented below the Android framework configurable to the user or app developer.
Perhaps these points are meant to only apply to standard Android security features since they assume OEMs reduce rather than improving security, but it doesn't say so.
We add a toggle for disallowing ptrace (native debugging toggle) and plan to add one for dynamic native code execution which is already supported as something that can be toggle and is blocked for the base OS other than the Vanadium renderer sandbox for when JIT is enabled (we have it disabled by default with a per-site toggle). Those are based on SELinux features we added. We don't/won't make any standard mandatory Android security feature possible to disable, but it doesn't specify.
@falken CTS and CDD are filled with a whole lot of ridiculous requirements and things which go against improving privacy and security. It's often because they are focused on mandating preserving app compatibility in most ways. However, we care deeply about preserving app compatibility and we provide features like our Network toggle in a way that does not cause app crashes when it's disabled since it just pretends the network is down. They still disallow doing that kind of thing.
@falken Google has delegated certification of Android devices to third parties. Google also officially allows tests to fail by receiving waivers for them and they give these out incredibly freely to their partners. However, OEMs are heavily cheating at certification through the third parties certifying they're passing the CTS and complying with the CDD clearly not actually enforcing the rules. Google doesn't do anything when they find out there's cheating going on. Zero consequences for it.