GrapheneOS is an open source privacy and security focused mobile OS with Android app compatibility. It's focused on the research and development of privacy and security technology including substantial improvements to sandboxing, exploit mitigations and the permission model. GrapheneOS also develops various apps and services with a focus on privacy and security. Vanadium is a hardened variant of the Chromium browser and WebView specifically built for GrapheneOS. GrapheneOS also includes our minimal security-focused PDF Viewer, our hardware-based Auditor app / attestation service providing local and remote verification of devices, and the externally developed Seedvault encrypted backup which was initially developed for inclusion in GrapheneOS.
GrapheneOS is a collaborative open source project, not a company. It's used and supported by a variety of companies and other organizations. It won't be closely tied to any company in particular. There will eventually be a non-profit GrapheneOS foundation, but for now the developers represent the project.
GrapheneOS improves the privacy and security of the OS from the bottom up. It has a hardened kernel, libc, malloc and compiler toolchain with many low-level improvements. These changes are designed to eliminate whole classes of serious vulnerabilities or provide meaningful barriers to exploitation. We avoid making changes without a clear rationale and we regularly work towards simplifying and replacing these low-level improvements. The malloc implementation is our own hardened_malloc providing cutting edge security for modern systems. The hardened_malloc project is portable to other Linux-based operating systems and is being adopted by other security-focused operating systems like Whonix. The hardened_malloc README has extensive documentation on it. Our work also heavily influenced the design of the next-generation musl malloc implementation which offers substantially better security than musl's previous malloc while still having minimal memory usage and code size.
There are also many under-the-hood changes at a higher level, including major improvements to SELinux policies particularly for the app sandbox. GrapheneOS tries to avoid impacting the user experience with the privacy and security features. Ideally, the features can be designed so that they're always enabled with no impact on the user experience and no additional complexity like configuration options. It's not always feasible, and GrapheneOS does add various toggles for features like the Network permission, Sensors permission, restrictions when the device is locked (USB peripherals, camera, quick tiles), etc. along with more complex user-facing privacy and security features with their own UX.
GrapheneOS has made substantial contributions to the privacy and security of the Android Open Source Project, along with contributions to the Linux kernel, LLVM, OpenBSD and other projects. Much of our past work is no longer part of the downstream GrapheneOS project because we've successfully landed many patches upstream. We've had even more success with making suggestions and participating in design discussions to steer things in the direction we want. Many upstream changes in AOSP such as removing app access to low-level process, network, timing and profiling information originated in the GrapheneOS project. The needs of the upstream projects are often different from ours, so they'll often reimplement the features in a more flexible way. We've almost always been able to move to using the upstream features and even when we still need our own implementation it helps to have the concepts/restrictions considered by the upstream project and apps needing to be compatible with it. Getting features upstream often leads to an improved user experience and app compatibility.
Official releases are available on the releases page and installation instructions are on the install page.
The official GrapheneOS releases are supported by our Auditor app and attestation service. The Auditor app and attestation service provide strong hardware-based verification of the authenticity and integrity of the firmware/software on the device. A strong pairing-based approach is used which also provides verification of the device's identity based on the hardware backed key generated for each pairing. Software-based checks are layered on top with trust securely chained from the hardware. For more details, see the about page and tutorial. These also support other operating systems.
No Google apps or services
GrapheneOS will never include either Google Play services or another implementation of Google services like microG. Those are not part of the Android Open Source Project and are not required for baseline Android compatibility. Apps designed to run on Android rather than only Android with bundled Google apps and services already work on GrapheneOS, so a huge number of both open and closed source apps are already available for it.
AOSP APIs not tied to Google but that are typically provided via Play services will continue to be implemented using open source providers like the Seedvault backup app. Text-to-speech, voice-to-text, non-GPS-based location services, geocoding, accessibility services, etc. are examples of other open Android APIs where we need to develop/bundle an implementation based on existing open source projects. GrapheneOS is not going to be implementing these via a Google service compatibility layer because these APIs are in no way inherently tied to Google services.
We're developing support for installing microG as a regular app without any special privileges. This will allow users to choose to use a partial reimplementation of Play services in a specific profile. We won't be supporting arbitrary signature spoofing by microG or any other app since it seriously compromises the OS security model. Guarding it by a permission isn't enough, both because users don't understand the substantial impact on the security model and it weakens security for the verified boot threat model where persistent state such as granted permissions is controlled by an attacker. Instead, the OS will specifically make microG signed with our microG signing key appear to other apps as signed with the Google Play services key. It won't bypass any other signature checks, only a check for Play services, and other apps also won't be able to pretend to be Play services to intercept FCM messages, obtain Google credentials, etc. It will not be granted any privileged permissions or other special capabilities unavailable to a regular untrusted app.
In the longer term, we also plan to offer a more minimal compatibility layer which pretends that Google services are offline rather than implementing them. Users will have the choice between no implementation of Play services, microG and this minimal implementation not implementing Google services. This choice will be available because we won't be bundling any of this into the OS. Ideally, Google themselves would support installing the official Play services as a regular Android app, rather than taking the monopolistic approach of forcing it to be bundled into the OS in a deeply integrated way with special privileged permissions and capabilities unavailable to other cloud service providers competing with them.
GrapheneOS was founded by Daniel Micay in late 2014. It started as a solo project incorporating his previous open source privacy/security work. The project initially created a port of OpenBSD malloc to Android's Bionic libc and a port of the PaX kernel patches to the kernels for the supported devices. It quickly expanded to having a large set of homegrown privacy and security improvements, particularly low-level hardening work on the compiler toolchain and Bionic. Work began on landing code upstream in AOSP and other upstream projects. A substantial portion of these early changes were either successfully landed upstream or heavily influenced the upstream changes which replaced them. The project was able to move very quickly in these days because there was so much low hanging fruit to address and it wasn't yet trying to produce a highly robust, production quality OS.
In late 2015, a company was incorporated which became the primary sponsor of the project. GrapheneOS was previously known as CopperheadOS while it was sponsored by this company. The intention was to use the company to build a business around GrapheneOS selling support, contract work and customized proprietary variants of the OS. The company was supposed to serve the needs of the open source project, rather than vice versa. It was explicitly agreed that GrapheneOS would remain independently owned and controlled by Daniel Micay. This company failed to live up the promises and is no longer associated in any way with GrapheneOS. The fact that the company was accidentally founded as 'Coppperhead Limited' was just the beginning of a multi-year trainwreck holding back and poisoning a successful open source project it ended up leeching off rather than supporting.
In 2018, the company was hijacked by the CEO who attempted to take over the project through coercion, but they were rebuked. They seized the infrastructure and stole the donations, but the project successfully moved on without them and has been fully revived. Since then, they've taken to fraudulently claiming ownership and authorship of our work, which has no basis in fact. They've tried to retroactively change the terms of their involvement and rewrite the history of the project. These claims are easily falsified through the public record and by people involved with the open source project and the former sponsor. This former sponsor has engaged in a campaign of misinformation and harassment of contributors to the project. Be aware that they are actively trying to sabotage GrapheneOS and are engaging in many forms of attacks against the project, the developers, contributors and supporters. Meanwhile, they continue profiting from our open source work which they falsely claim as their own creation.
After splitting from the former sponsor, the project was rebranded to AndroidHardening and then to GrapheneOS and it has continued down the original path of being an independent open source project. It will never again be closely tied to any particular sponsor or company.
Copyright and licensing
The copyright for GrapheneOS code is entirely owned by the GrapheneOS developers and is made available under OSI-approved Open Source licenses. The upstream licensing is inherited for the modifications to those projects and MIT licensing is used for our own standalone projects. GrapheneOS has never had any copyright assignment and the developers have always owned their own contributions.
The tiny portion of the code written by people under contract with the former sponsor has not been included in the project since it was ported from Android Oreo to Pie in 2018. This code became obsolete and was no longer useful. The vast majority of the code from the previous era was owned by Daniel Micay, with very few exceptions. It was never written under any contracts or employment agreements, was never assigned to any company or organization and was the continuation of the original independent open source project. The code was originally published under the same permissive open source licenses that are used by GrapheneOS today. Only a small portion of this historical code is actually still in use today. Most has become obsolete or has been replaced by rewrites taking better approaches than in the past.
There was an era from September 2016 until the project split from the former sponsor in 2018 where non-commercial usage licensing was used for revisions to the existing permissively licensed code. This was an attempt to prop up the sponsor that was supposed to be supporting the open source project. This did not impact ownership of the code and Daniel Micay has relicensed the portions of the code that are used by GrapheneOS. GrapheneOS does not contain any code based on code under non-commercial usage licensing. Great care was taken to avoid pulling in anything that was not solely owned by Daniel Micay, which was the case for nearly everything in the project.
Details on the roadmap of the project will be posted on the site in the near future.
To get an idea of the near term roadmap, check out the issue trackers. The vast majority of the issues filed in the trackers are planned enhancements, with care taken to make sure all of the issues open in the tracker are concrete and actionable.
In the long term, GrapheneOS aims to move beyond a hardened fork of the Android Open Source Project. Achieving the goals requires moving away from relying on the Linux kernel as the core of the OS and foundation of the security model. It needs to move towards a microkernel-based model with a Linux compatibility layer, with many stepping stones leading towards that goal including adopting virtualization-based isolation.
The initial phase for the long-term roadmap of moving away from the current foundation will be to deploy and integrate a hypervisor like Xen to leverage it for reinforcing existing security boundaries. Linux would be running inside the virtual machines at this point, inside and outside of the sandboxes being reinforced. In the longer term, Linux inside the sandboxes can be replaced with a compatibility layer like gVisor, which would need to be ported to arm64 and given a new backend alongside the existing KVM backend. Over the longer term, i.e. many years from now, Linux can fade away completely and so can the usage of virtualization. The anticipation is that many other projects are going to be interested in this kind of migration, so it's not going to be solely a GrapheneOS project, as demonstrated by the current existence of the gVisor project and various other projects working on virtualization deployments for mobile. Having a hypervisor with verified boot still intact will also provide a way to achieve some of the goals based on extensions to Trusted Execution Environment (TEE) functionality even without having GrapheneOS hardware.
Hardware and firmware security are core parts of the project, but it's currently limited to research and submitting suggestions and bug reports upstream. In the long term, the project will need to move into the hardware space.
See the FAQ section on device support.