GrapheneOSThe 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.
Play Integrity API has no minimum security patch level and nearly all these apps use weak software-based checks that are easily bypassed by attackers. The hardware-based checks rely on trusting every key distributed to every certified Android device, which are often leaked.
Hardware-based attestation can be used for security purposes such as verifying device integrity with a pinning-based approach without the weakness of being vulnerable to leaked keys from the whole Android ecosystem since specific per-app keys in the secure element can be pinned.
Play Integrity API is claimed to be based on devices complying with the Compatibility Test Suite and Compatibility Definition Document. We have irrefutable proof that the majority of certified Android devices do not comply with the CTS/CDD. Play Integrity API is based on lies.
Essentially every non-Pixel device has important CTS failures not caused by CTS bugs. OEMs are cheating to obtain certification. Google claims GrapheneOS can't be permitted because we don't have a certification where they freely allow cheating and don't ban non-compliant devices.
Since Play Integrity doesn't even have a minimum security patch level, it permits a device with multiple years of missing patches. Hardware attestation was required on all devices launched with Android 8 or later, but they don't enforce it to permit non-compliant devices.
The reality is that the Play Integrity API permits devices from companies partnered with Google with privileged Google Play integration when they're running the stock OS. It's easy to bypass, but they'll make changes to block it being done at scale long term such as if we did it.
It does not matter if these devices have years of missing security patches. It doesn't matter if the companies skipped or improperly implemented mandatory security features despite that being required by CDD compliance. Failing even very important CTS tests doesn't matter either.
Google can either permit GrapheneOS in the Play Integrity API in the near future via the approach documented at https://grapheneos.org/articles/attestation-compatibility-guide or we'll be taking legal action against them and their partners. We've started the process of talking to regulators and they're interested.
We're not going to give Google veto power over what we're allowed to do in GrapheneOS. We comply with CTS and CDD except when it limits our ability to provide our users with privacy and security. Google wants to be in charge of which privacy/security features can be added. Nope.
Google's behavior in the mobile space is highly anti-competitive. Google should be forbidden from including Google Mobile Services with privileged access unavailable to regular apps and services. GrapheneOS sandboxed Google Play proves that hardly anything even needs to change.
Google should also be forbidden from participating in blocking using alternate hardware/firmware/software. They've abused their market position to reinforce their monopolies. They've used security as an excuse despite what they're doing having no relevance to it and REDUCING it.
Google is forbidding people from using a growing number of apps and services on an objectively far more private and secure OS that's holding up much better against multiple commercial exploit developers:
https://grapheneos.social/@GrapheneOS/112826067364945164
They're holding back security, not protecting it.
GrapheneOS (@[email protected])
Attached: 3 images Here's the Cellebrite Premium 7.69.5 iOS Support Matrix from July 2024. 404media recently published an article based on the same April 2024 docs we received in April and published in May. Many tech news sites including 9to5Mac made incorrect assumptions treating that as current.
We've put a lot of effort into collaborating with Google to improve privacy and security for all Android users. Their business team has repeatedly vetoed even considering giving us partner access. They rolled back us being granted security partner access by the security team.
As with how they handle giving out partner access, the Play Integrity API serves the interests of Google's business model. They have no valid excuse for not allowing GrapheneOS to pass device and strong integrity. If app developers want to ban it, they can still do it themselves.
After our security partner access was revoked, we stopped most of our work on improving Android security. We continued reporting vulnerabilities upstream. However, we're going to stop reporting most vulnerabilities until GrapheneOS is no longer blocked by the Play Integrity API.
This year, we reported multiple serious vulnerabilities to Android used by widely used commercial exploit tools:
https://source.android.com/docs/security/overview/acknowledgements
If Google wants more of that in the future, they can use hardware attestation to permit GrapheneOS for their device/strong integrity checks.
Authy's response about their usage of the Play Integrity API shows their service is highly insecure and depends on having client side validation. Play Integrity is thoroughly insecure and easily bypassed, so it's unfortunate that according to Authy their security depends on it.
If Authy insists on using it, they should use the standard Android hardware attestation API to permit using GrapheneOS too. It's easy to do:
https://grapheneos.org/articles/attestation-compatibility-guide
Banning 250k+ people with the most secure smartphones from using your app is anti-security, not pro-security.
It's very unfortunate when new apps adopt the Play Integrity API and stop working. Authy isn't a very good choice for 2FA but many people use it and it's a problem for us for a widely used app to be incompatible. A single widely used app losing compatibility is a big deal to us.
ArcticFoxProbably a good excuse for Graphene OS users to migrate to a better 2FA solution. If Authy allows export, its super easy to switch to Aegis.
sTiKyt 
@SilverFox1 @GrapheneOS
Problem is, lately Authy is so broken you can't even log into it from a non-grapheneOS phone, because Twilio shit-ass service is incapable of sending an SMS to your phone number
So even if you manage to get your hands on another phone (which is diabolical, not everyone has spare phones for no reason), you can't even open Authy to access or export your 2FAs
Problem is, lately Authy is so broken you can't even log into it from a non-grapheneOS phone, because Twilio shit-ass service is incapable of sending an SMS to your phone number
So even if you manage to get your hands on another phone (which is diabolical, not everyone has spare phones for no reason), you can't even open Authy to access or export your 2FAs
Bart Groeneveld@GrapheneOS For me, that is one of the reasons to avoid apps on the Google Play Store. Developers of the apps there will assume Play Integrity just works, so any app from there could just stop working for me.
(Nonetheless, thanks a lot for providing a relatively secure and private option to use the Play Store).
(Nonetheless, thanks a lot for providing a relatively secure and private option to use the Play Store).
aerique@GrapheneOS Will you be bringing this to the attention of the EU?
Do NOT Fear|🇺🇸🇺🇦🐊🦉🌊💙@GrapheneOS Any regulatory effort in this regard will fail because iPhones are locked to iOS, and Google & Co. can use that as a defense that they're being unfairly targeted
@jdrch They can't, because this isn't about a Google operating system but rather primarily non-Google operating systems licensing their apps and services under anti-competitive terms. There are a lot of OEMs trying to fight it around the world already and they've had success in some regions such as South Korea already. Google wants to have the control of it being their own OS but without it being their own OS, and without taking responsibility for security, etc. since it's not their OS.
@GrapheneOS Ah I understand what you mean, now
Nereuxofficial@GrapheneOS Is this in the EU or are US regulators also interested in this monopolistic behaviour?
@Nereuxofficial EU Commission
rj191@GrapheneOS Just curious if there is anything that can be publicly updated about this?
Would love to see GrapheneOS get the proper recognition it deserves for security and privacy by not being treated as a second class custom ROM citizen that is "unsecure" due to commercial reasons.
I hope the legal route bares fruit!
@rj191 There's no update on it yet beyond the talks with regulators progressing and talks with a company interested in helping us file a lawsuit progressing.
GrapheneOS isn't a custom ROM though, it's an OS. None of phone operating systems people call ROMs in this field are actually ROMs but we don't want it referred to that way unlike others.
@GrapheneOS Thanks,
That in itself is informative that Google haven't tried to come to the table in a meaningful enough way where you stop progressing the legal route.
TIL, will "duckduckgo"... The definitions of ROM vs OS in this context.
@rj191 ROM refers to read-only firmware such as the boot ROM on the main SoC which is responsible for loading, verifying and then running the first stage of updateable firmware.
@GrapheneOS CTS has been meaningless for a while because the only thing that really matter to Google is Play Store APK compatibility.
⊥ᵒᵚ Cᵸᵎᶺᵋᶫ∸ᵒᵘ ☑️@GrapheneOS extraordinary claim. Where's the extraordinary evidence?
@falken How is this an extraordinary claim? Run the Compatibility Test Suite on any Android device and you'll see the many failures. The whole point is that it's supposed to pass on production builds. It inherently can't pass on development builds. You can run the CTS yourself on any certified Android device you own, by design. The claim proves itself running the suite. There are many clear CDD/CTS violations but the clear proof doesn't require talking about any specific one.
@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?
This sounds a bit like diesel-gate?
@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.
@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.