Developers have to go out of their way to implement triggering Play Integrity API checks in their app and then retrieve the results to check on their services. They're putting a lot of effort into banning anything not licensing Google Mobile Services. It's definitely not a security feature since it permits devices with no security updates for more than 8 years but not a far more secure OS than anything Google certifies. Google doesn't allow GrapheneOS to obtain certification and certification comes with highly anti-competitive rules which would be completely unacceptable. Their licensing system has been ruled illegal in South Korea and other countries should not only do the same but ban the Play Integrity API and other related anti-competitive features. These are not actual security features and that's an excuse for the actual purpose of enforcing their GMS licensing model including forcing including a bunch of Google apps with extremely privileged access and using their builds of many OS components shipped from the Play Store.
HN user
strcat
They don't need to do anything to support GrapheneOS. They only need to stop actively going out of the way to block it and any other alternative OS via the Play Integrity API. They put significant effort into blocking anything other than iOS or a Google Mobile Services Android stock OS certified by Google. They're not only blocking a non-stock AOSP-based operating system but rather anything other than iOS or a Google Mobile Services Android device certified by Google.
The kernel drivers are all published in the GrapheneOS kernel repositories. A subset of the libraries/services in the vendor partition used with those drivers are closed source.
Pixels were headed towards all of the device support code for the OS being open source along with open sourcing large portions of the firmware including for the TEE (Trusty OS) and secure element (OpenTitan). It was ended after the launch of Android 16. It's a major factor in why GrapheneOS is going to be focused on future Motorola Mobility devices. You can still see a large portion of the Pixel userspace driver libraries and services in the AOSP source tree but they stopped pushing new releases for a lot of it.
Fairphones are far from meeting the security requirements to run GrapheneOS and have chosen an incompatible path. It won't be available for their devices.
https://discuss.grapheneos.org/d/24134-devices-lacking-stand...
You should read https://discuss.grapheneos.org/d/24134-devices-lacking-stand... about /e/ and also look at what they say about devices with strong privacy and security including but not limited to https://grapheneos.social/deck/@GrapheneOS/11635397373214317....
/e/ has drastically worse privacy and security from the Android Open Source Project or especially and iPhone. It's not a step up from standard AOSP. It lags many months behind on many High/Critical severity patches, years behind on overall patches and rolls back the privacy/security in a bunch of ways. It includes many invasive services.
It has many default enabled highly privileged Google services including downloading Google Play executables such as droidguard and running those with similar privileged access as they have on a Google Mobile Services OS anyway.
/e/ is the direct opposite of a privacy or security focused OS. It doesn't provide bare minimum standard privacy and security patches while setting an inaccurate Android security patch level. It lags many months behind on patches even on devices where they're the least behind. It's typically years behind on kernel, driver, firmware and major OS updates. It doesn't keep the standard privacy and security protections intact and lagging behind on OS updates means not having the current ones. It sends user data to OpenAI and other third parties without consent.
https://community.e.foundation/t/voice-to-text-feature-using...
https://codeberg.org/divested-mobile/divestos-website/raw/co...
https://discuss.grapheneos.org/d/24134-devices-lacking-stand...
/e/ and Murena have repeatedly claimed providing strong privacy and security mainly benefits criminals and claim devices doing it are mainly used by criminals. Here's one example of many:
https://grapheneos.social/deck/@GrapheneOS/11635397373214317...
An iPhone is a hardened device with drastically better privacy and security than an /e/ device. It would fall under the claims from /e/ and Murena about hardened devices.
Fairphone doesn't design or make their smartphones. The devices are designed and made by a large ODM. It's entirely feasible to use a modern SoC with current generation security features and provide proper updates. Their ODM isn't doing it to cut costs.
Fairphone quickly stops providing Linux kernel updates and has months of delay for Android userspace backports along with driver/firmware backports. The delay for yearly updates typically starts at a year and gets longer as devices get older and they've always skipped the quarterly updates.
Using a modern SoC, properly configuring it, using proper signing keys (Fairphone has repeatedly used publicly available sample private keys) and providing proper updates is most of what's needed to meet the requirements. That's entirely doable by the few OEMs designing their devices in-house such as Motorola Mobility. Samsung and Google along with many of the ODMs making devices for Nothing, Fairphone, etc.
https://discuss.grapheneos.org/d/24134-devices-lacking-stand...
No, but all of the kernel drivers are open source and always were. The closed source userspace libraries such as the Mali GPU library aren't a barrier to porting to a new kernel version which is what was said above. We could move to 6.12 ourselves but we choose to wait for them for much broader testing which is happening with Android 17 QPR2.
GrapheneOS is security before anything else.
GrapheneOS is a privacy project highly focused on usability and compatibility. Privacy depends on security so it has to put a lot of work into security too and it has always been a major focus, but it's a misconception that it's all about security.
This means they strongly advice against using other software many in their core audience are predisposed to like: Firefox, Signal, plugins for browsers, F-Droid, ect.
GrapheneOS doesn't recommend against Signal but rather it's the main recommendation for end-to-end encrypted chat from the project including via the Molly fork of Signal.
The explanations are usually quite... blunt, and they're not exactly open for discussion (which makes sense, from a pure security perspective, those apps are indefensible).
This isn't true. GrapheneOS provides nuanced information with detailed explanations for these topics.
For security reasons, GrapheneOS uses ahead-of-time compilation for apps. The stock OS compiles the heavily used parts of the code dynamically in-memory and then does partial ahead-of-time compilation later in the background. The install-time compilation will become more asynchronous in the future so the app can be used right away.
GrapheneOS will eventually have a GrapheneOS RCS app, but for now RCS is fully supported via Google Messages and sandboxed Google Play:
RCS via Google Messages and sandboxed Google Play is fully supported on GrapheneOS:
It runs on tablets and folding devices. There hasn't been a recent tablet meeting the requires but the Pixel 9 Pro Fold and Pixel 10 Pro Fold are supported. Both of those are phones folding out into a close to square tablet. There will be more standalone tablets supported again.
Here's an example of what they're responding to with inaccurate personal attacks:
https://grapheneos.social/@GrapheneOS/116353973732143171
GrapheneOS posts factual information debunking inaccurate claims from groups attacking it. Some of those groups react to their misleading claims being addressed with personal attacks. Threads about GrapheneOS on Hacker News usually have multiple posts with personal attacks towards our team from people influenced by those groups.
There are a lot of devices with the ability to install another OS and lock the device with verified boot, but none with the required updates and security features other than Pixels. Fairphones are near the bottom for security among the available options.
It's not one of the main issues with their devices but Fairphone has had a lot of issues with verified boot including using publicly available sample private keys for signing firmware and OS images across multiple device generations. It's not a strength of their devices.
It's a fork of the Android Open Source Project (AOSP) with major privacy/security improvements and alternatives to Google apps/services. The massive set of changes needs to be ported to new major versions of AOSP.
The apps also need to be updated to the Android 17 target API level but that can happen over several months following the OS itself being ported to it. The app aspect is something all Android developers need to deal with due to new target API levels bringing backwards incompatible improvements.
It isn't only developed for Pixels. Pixels are currently the only devices permitting an alternate OS with the required updates and security features. GrapheneOS has a partnership with Motorola Mobility and there will be official GrapheneOS support for a subset of next generation Motorola devices.
See https://privsec.dev/posts/android/banking-applications-compa... for banking apps. Anything that's not a banking or government app is extremely likely to work. Very few other apps ban using a non-Google-certified OS and that's the only significant reason for incompatibilities. GrapheneOS has a per-app exploit protection compatibility mode to work around memory corruption bugs caught by the features. It's in the process of overhauling the secure spawning feature to avoid tripping rare anti-tampering measures in certain banking apps. Play Integrity is increasingly the only compatibility issue. Some apps using Play Integrity have explicitly permitted GrapheneOS though.
GrapheneOS exists to greatly improve the privacy and security of an existing open source OS project. Android Open Source Project has good privacy and security as a starting point.
Pixels provide strong hardware and firmware security. Pixels have made multiple significant hardware and firmware level improvements based on recommendations by GrapheneOS. GrapheneOS now has a hardware partnership with Motorola Mobility which includes working with Qualcomm. It isn't only a software project.
Regularly leaked data on the capabilities of Cellebrite show they have the least success with GrapheneOS by far despite specifically hiring for it based on their job postings.
Those are much less private and secure than the Android Open Source Project on Pixels without the major privacy and security improvements of GrapheneOS. Those aren't privacy or security hardened devices.
Ubuntu Touch is drastically less private and secure than AOSP let alone GrapheneOS. Volla's devices don't come anywhere close to meeting the update and security requirements for GrapheneOS. GrapheneOS is a Linux distribution much closely following along with the Linux kernel LTS releases, unlike those devices. It also regularly moves to new Linux kernel LTS branches. Pixels are in the process of moving to the 6.12 LTS branch with Android 17 QPR2. 6.18 is currently in the early stage of stabilization.
Android Auto is fully supported and shouldn't be any more flaky than it is on the stock OS. It's often flaky due to a bad USB connection or problematic implementation in the car. That's just how it is everywhere.
Google Wallet bans using anything other than an unmodified Google Mobile Services stock OS but there are alternatives in certain regions. In Europe, there are a lot of banking apps with tap-to-pay compatible with GrapheneOS and also Curve Pay. PayPal also has a limited tap-to-pay launch in Germany.
Using Sandboxed Google Play doesn't defeat the purpose of using GrapheneOS and neither does using Google apps. It does not exist specifically to avoid Google apps or services. It exists to provide a highly private and secure OS retaining high usability and app compatibility. Being able to use sandboxed Google Play is an important part of what it provides. Many GrapheneOS users don't use it and many who do use it are only using it in a dedicated profile for a small subset of apps but that's not at all required to heavily benefit from GrapheneOS. Moving to more private apps/services over time does make sense but it isn't mandatory and users can choose what kind of compromises they wan to make.
Yes, those are all compatible and the only way to use them is as regular sandboxed apps without any special access. Sandboxed Google Play can be installed in the profiles of your choice. Installing it in the main Owner user is a valid choice and doesn't at all ruin what GrapheneOS provides but you can make a dedicated work profile or Private Space for it to keep it separate. Only apps in the same profile can see it and use it, so you can control which apps will use their functionality depending on it that way.
GrapheneOS is highly usable and compatible with nearly all Android apps. It has a similar experience to a mainstream Android OS if you choose to set it up that way such as using sandboxed Google Play in the main profile (which does not ruin what it provides at all, it's a perfectly valid setup). The purpose of GrapheneOS is to provide far better privacy and security than the Android Open Source Project (AOSP). AOSP is a lot more private and secure than a traditional desktop OS including one ported to mobile.
See https://grapheneos.org/faq#recommended-devices for the device recommendations. There are going to be Motorola devices with GrapheneOS support within a year too.
The kernel drivers are fully open source and moving to new kernel branches is a standard part of the update process. Pixels are currently moving from 6.1 and 6.6 to 6.12 with Android 17 QPR2. This is part of the hardware requirements for GrapheneOS listed here:
The position of GrapheneOS is that attestation shouldn't be used to restrict people to an allowlist of hardware and operating systems. It can be used to without forbidding them from using what they want to use. However, if it's going to be used to make an allowlist of hardware and operating systems, then it needs to permit any any at least as secure as what they're permitting to be approved. Instead, they're enforcing Google's business model for licensing Google Mobile Services while not requiring secure devices at all. There's no security value in the current Play Integrity API which permits devices with no patches for 10 years.
Even the Play Integrity API strong integrity level only enforces being no more than 1 year behind on the official Android security bulletins which are 3-4 months outdated at release so that's nearly a year and a half behind of patches. It also has the massive loophole of permitting being arbitrarily behind on patches for earlier Android versions than Android 13, so even the strong integrity level permits a device launched with Android 8 with no patches applied since then. That's not a security check, it's a business model check to lock out alternatives not licensing Google Mobile Services. The licensing terms for Google Mobile Services have been found to be illegal in multiple countries. Google enforcing agreeing to those terms with the Play Integrity API is a truly extraordinarily violation of antitrust laws. Governments are not only failing to act but adopting it themselves. It's going to be looked back on as a massive failure for technology regulation/legislation along with government tech policy beyond that.
Dual booting would sacrifice a lot of the hardware-based security feature integration and would be much further from passing attestation checks. GrapheneOS fully supports hardware-based attestation but Google doesn't permit it in the Play Integrity API. Directly booting the fully unmodified stock OS is required to pass the hardware attestation checks for the stock OS. GrapheneOS appears as GrapheneOS in the attestation metadata and a dual boot setup would appear as that specific dual boot setup. Since it would have a bunch of security sacrificed for it, it would be far harder to convince services to permit that. It would be counterproductive.
GrapheneOS has near perfect app compatibility other than the Play Integrity API banning it from the overall tiny number of apps using it. It has per-app compatibility toggles for privacy and security features which trip other anti-tampering checks, find memory corruption bugs in apps, etc. There are a couple known compatibility issues from anti-tampering checks from the secure spawning feature but it has a toggle.
The stock OS isn't what's needed but rather directly booting it from the firmware with 0 modifications. Dual booting would require booting something else and major modifications to deal with hardware APIs not designed for multiple operating systems using them at the same time. Secure element / TEE APIs including the hardware keystore and attestation, etc. are not designed for dual boot. A/B updates, verified boot, firmware updates, etc. would need to be dealt with by the bootloader system. It would be complex and messy. The end result would not be a hardened device or one compatible with standard attestation checks.
Dual booting would be much further from passing attestation checks and would be incompatible with a bunch of the hardware-based security features. The boot slots are needed for A/B updates and include the firmware partitions. They're not useful for this and don't provide useful functionality for it. It would be entirely possible to build a bootloader for loading multiple different operating systems but it would be a hacked together mess without proper firmware updates or security. It would require heavily modifying both GrapheneOS and the stock OS to fit them into it. It would require losing a lot of the hardware-based security integration. What would be the point? The end result would be much further from passing attestation checks than GrapheneOS. GrapheneOS has near perfect app compatibility with the exception of the Play Integrity API. Other anti-tampering checks are largely compatible with GrapheneOS with the exception of tripping from certain hardening features which is increasingly being resolved with workarounds and there are toggles to avoid it already.