GrapheneOS

Open source privacy and security focused mobile OS with Android app compatibility.

Website: https://grapheneos.org/
Forum: https://discuss.grapheneos.org/
X: https://x.com/GrapheneOS
GitHub: https://github.com/GrapheneOS

Public Key

npub1kwarc5z9lwhen05uknd2nuwhhthd4ws0cku3t9j3rchm0fcd6luslse0nj

NIP-05 Address

[email protected]

Profile Code

nprofile1qqst8w3u2pzlhtueh6wtfk4f78tm4mk6hg8utwg4jeg3utah5uxa07gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dslp5jg4

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1kwarc5z9lwhen05uknd2nuwhhthd4ws0cku3t9j3rchm0fcd6luslse0nj

Show more details

Last Notes

2026-08-29 16:19:30 CEST

We have a partial port of GrapheneOS to the Pixel 11 series after a week of work on it. We're unable to complete the port due to lack of support for ARM hardware memory tagging in software, firmware and near certainly hardware. It appears Google cut an important security feature to save money.

2026-08-24 20:08:52 CEST

AppCompatConfig version 8 released:
https://github.com/GrapheneOS/platform_packages_apps_AppCompatConfig/releases/tag/8
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/41432-appcompatconfig-version-8-released
#GrapheneOS #privacy #security

2026-08-22 19:35:22 CEST

- reply

It isn't feasible to provide a secure element on the same level as Pixels in the near term. Titan M2/M3 are incredible and it's going to take time for a solution from Qualcomm or another vendor to catch up. Qualcomm's QSEE is a TEE similar to Pixels using Trusty OS, Qualcomm SPU is a secore core similar to the Pixel secure core but they didn't have a direct equivalent to the Titan M2/M3 and OEMs just reused a eSIM/NFC chip from NFC in practice.

2026-08-22 19:33:47 CEST

- reply

Pixels are now very difficult to support. It's harder to support Pixels than it would be to support many other devices not doing more than publishing kernel sources. We use Pixels because they have the best hardware, firmware and software security among Android devices. As we said in the original thread though, it's very possible to do better than Pixels at security in many areas and we fully intend to do that with the Motorola devices.

2026-08-22 19:32:05 CEST

- reply

It was difficult to simply add support for the Pixel 10a after launch despite already having 9th/10th gen Pixel support. Pixel 10a is really a refresh of the Pixel 9a with the 9th gen Pixel SoC rather than a true 10th gen Pixel. Still, the way it launched with a quirky device branch not matching the standard AOSP releases led to it being problematic for us to support. We had to work around a lot of issues causing various crashes, etc. due to mismatches.

2026-08-22 19:30:57 CEST

- reply

We don't know if it will be feasible to support 11th gen Pixels prior to Android 17 QPR2 or even Android 18. Android 17 QPR2 was already well into development with public Betga releases available for a while already. The changes for 11th gen Pixels may not be rolled into it and that may happen with Android 18. It's certainly possible to add support with only Android 17 but it's way harder and we haven't determined if we're going to need to wait yet.

2026-08-22 19:29:44 CEST

- reply

Traditionally, newly launched Pixels would come with a device branch being pushed to AOSP. That was often based on a newer revision of the development branch than the existing devices. They also often add new features to AOSP for use on the new devices and those often initially appear in the device support branch. It makes it problematic to try to support the devices until the next major release pushed to AOSP has this all rolled into it.

2026-08-22 19:28:29 CEST

- reply

We can continue supporting all of the earlier Pixels. We added 10th gen Pixel support after Pixels were dropped from AOSP and should be able to do the same for 11th gen Pixels. However, it can be extremely difficult especially before the next major release of the OS is pushed to AOSP. For example, Pixel 11 moved to post-quantum-secure cryptography for verified boot and added it for hardware keystores. We need to figure out if it shipped in AOSP already.

2026-08-22 19:15:33 CEST

- reply

Instead, we have to request the kernel driver sources via a Google Forms setup (https://source.android.com/opensourcerequest) and they provide a link to the tarballs for the specific tag we requested. They throw all the code from dozens of Git repositories into a single massive tarball with no commit history. It can't be uploaded to GitHub as a single repository due to size. It also breaks uploading to GitLab even with our free Enterprise so we had to split adding files.

2026-08-22 19:10:57 CEST

- reply

Google has hardware memory tagging for a tiny set of processes as part of Android Advanced Protection Mode (AAPM) added in Android 16. They don't use it for the kernel, don't use it for the vast majority of AOSP userspace processes and don't use it for the device-related processes in the vendor HAL. They also don't use it for apps not explicitly opting into it which are negligible. We use it for the whole kernel and userspace including all base OS apps.

2026-08-22 19:09:46 CEST

- reply

A substantial part of our resources is spent on developing and maintaining support for making production builds of AOSP for Pixels. There's also a large portion of our resources used on making our hardening features work on Pixels. A subset of our features are hardware-based including hardware memory tagging, USB-C port protection and others. Hardware memory tagging also uncovers a massive number of memory corruption bugs in software in practice.

2026-08-22 19:08:26 CEST

- reply

Pixel 9a and earlier were officially the Android Open Source Project (AOSP) reference devices. It included official support for them including the sources for the kernel drivers and a large portion of the userspace device support code. They didn't have things set up for proper production builds with the vendor code built from sources so we had to put that together ourselves.
Android 16 removed support for Pixels from AOSP and we had to develop it again.

2026-08-22 18:31:53 CEST

- reply

We aren't getting funding from them and don't particularly need it. They're assigning engineers to work on porting GrapheneOS to the devices and maintaining it once that's done which is what we need. We want them to assign more engineers to it rather than giving us money.

2026-08-22 03:48:27 CEST

- reply

Supporting a flip device with vertical folding would be a new form factor for GrapheneOS. The main use case for those is a tiny phone to use with one hand in the folded form factor. The tablet-style folding devices we already support are extremely useful for web browsing, reading, maps, etc.

2026-08-22 03:45:36 CEST

- reply

We do plan to support Motorola's Razr Fold and Razr Ultra (flip) devices in addition to a regular device. We already support the original Pixel Fold (Pixel 7) along with the Pixel 9 Pro Fold and Pixel 10 Pro Fold. We still plan to add support for 11th gen Pixels including the Pixel 11 Pro Fold too.

2026-08-22 03:26:12 CEST

- reply

It's quite possible the successor to the Motorola Signature will be available in the US. If it wasn't then it could be imported. Many of our users are importing Pixels to countries where they aren't available via a package forwarding service in the US, EU or elsewhere. It's how we get phones to some of our developers too.

2026-08-22 03:13:40 CEST

- reply

If they sell the Motorola Signature (2026), Razr Fold (2026) and Razr Ultra (2026) then the 2027 devices we're supporting will probably be available.
We don't know how the RAM and SSD shortage will impact the availability and pricing though.

2026-08-22 02:56:52 CEST

- reply

Razr Fold (2026) and Razr Ultra (2026) are available in the US so hopefully the next generation ones are too. Motorola Signature (2026) wasn't available in the US but hopefully that changes.

2026-08-22 02:38:17 CEST

- reply

Pixels have become much harder to support. Android 16 removed support for Pixels and they became harder to properly support than many other devices rather than easier. It's crucial to keep up with the major OS updates to provide all the security patches and we do but it's much harder for us now.

2026-08-22 02:35:57 CEST

- reply

It's very realistic to provide better security than Pixels against remote attacks. It's far harder to provide a secure element as good as the Titan M2/M3. There will definitely be a decent secure element providing the current generation features including the Android 16 QPR2+ rate limiting design.

2026-08-22 02:33:43 CEST

- reply

These devices will meet or exceed of our official requirements including 7 years of proper updates, starting out with the Linux 6.18 LTS which can be upgraded to a new branch eventually, reset attack protection for firmware boot modes and everything else. There wasn't time to do it all for 2026.

2026-08-22 02:30:26 CEST

- reply

Next generation Snapdragon will have more mature support for MTE and greatly improved secure element support. It's still likely going to be a lot of work to get MTE fully deployed for the kernel and OS. We need all our hardware-based features including our USB-C port protection ported to it too.

2026-08-22 02:28:42 CEST

- reply

Tensor was a sidegrade or downgrade from Snapdragon in many ways. Tensor is paired with the fantastic Titan M2/M3 which was a huge security advantage. It also brought hardware memory tagging (MTE) with the Pixel 8. Snapdragon 8 Elite Gen 5 finally shipped MTE but it's broken on the non-Elite SoC.

2026-08-22 02:26:34 CEST

- reply

Flagship Snapdragon provides much better CPU and GPU performance and provide more of what's needed via isolated components on the SoC. That includes better cellular, Wi-Fi/Bluetooth and GNSS radios with solid security including good isolation. Snapdragon Pixels worked well for us and it will again.

2026-08-22 02:16:06 CEST

Initial focus for our partnership with Motorola is a regular non-folding device. Current generation Motorola Signature (2026), Razr Fold (2026) and Razr Ultra (2026) are very close to meeting our requirements but lack MTE, adequate secure element integration and other features being added for 2027.

2026-08-14 22:58:25 CEST

- reply

/e/ has highly privileged support for Google services built into the OS. It even downloads and runs Google Play executables with privileged access automatically.
That's not very important compared to /e/ being incredibly far behind on standard privacy and security patches. It's missing many High and Critical severity patches from Pixel Update Bulletins and far more. It lags months and even years behind on patches.
See our response at https://nitter.net/GrapheneOS/status/2081837057433915603 for much more info.

2026-08-12 01:11:34 CEST

- reply

Yes, wireless charging still works with the USB-C port mode set to Off. Setting it to charging-only provides most of the security value but we decided to offer the ability to fully disable it in case there are ever USB-PD vulnerabilities in the USB controller. USB-PD is a secondary form of limited data which could be used to exploit the USB controller itself, turn on USB data and then reach the remaining attack surface for USB in the kernel despite drivers being off.

2026-08-12 01:03:38 CEST

- reply

GrapheneOS blocks new USB connections while locked by default at both a software and hardware level. It can be enabled while unlocked too. It can even be set to fully disable USB while booted including USB-PD and other charging functionality. More info:
https://grapheneos.org/features#usb-c-port-and-pogo-pins-control

2026-08-12 00:59:50 CEST

- reply

Standard Android USB charging-only mode does not block new USB connections. It only means the device Android is running on isn't acting as a USB peripheral such as a webcam, MTP or MIDI device itself. USB debugging is another of those gadget modes which can be on simultaneously.

2026-08-12 00:59:39 CEST

- reply

Android 16 added Android Advanced Protection Mode which can be used to toggle on multiple extra security features. It blocks new USB connections at a kernel level while the device is locked. Our approach also blocks new USB connections at a hardware level and disables USB data.

2026-08-12 00:59:33 CEST

- reply

They have their tool pretend to be a certain USB peripheral to target specific Linux USB drivers. These exploits are widely used including against journalists and political activists. Here's a technical article about a specific case of this in Serbia:
https://securitylab.amnesty.org/latest/2025/02/cellebrite-zero-day-exploit-used-to-target-phone-of-serbian-student-activist/

2026-08-12 00:59:15 CEST

- reply

Exploiting Linux kernel USB vulnerabilities is how exploit tools from Cellebrite and other companies extract data from Android devices in practice. They also exploit firmware bugs in other boot modes but we convinced Google to eliminate most of that attack surface for Pixels.

2026-08-12 00:59:07 CEST

- reply

Android's standard USB menu being set to charging-only means the device has MTP enabled with file transfer disabled. It always has USB data and USB peripherals enabled. GrapheneOS USB-C port charging-only means USB data is disabled in hardware and kernel USB drivers are disabled.

2026-08-12 00:58:50 CEST

Android has USB data and a large number of USB drivers available including while locked. Plug in a mouse, keyboard, external drive or other USB accessory and you'll see that's the case. When Android says charging-only, it means not allowing file transfer.

2026-08-11 19:31:25 CEST

- reply

The initial devices with GrapheneOS support should be available in 2027. The initial devices will be flagships so they'll be higher end hardware than Pixels at a higher price. Lower end devices will take more time to meet our requirements since the updates and security features aren't as good. It's mostly due to how Qualcomm handles it. The latest Snapdragon flagships have the best security features. We'll also need Motorola to start paying them for longer updates below flagships.

2026-08-08 17:04:13 CEST

- reply

GrapheneOS shipped every single one of the patches they falsely claim were missed. We quickly moved to each new stable release of AOSP as the new base for the OS. Every patch included in AOSP or the stock Pixel OS was quickly included in GrapheneOS. We also included many patches they did not ship.

2026-08-08 17:04:04 CEST

- reply

The paper has a table listing the patches they're inaccurately claiming are missing in GrapheneOS. They claim the ones marked as green were manually verified to be missing. The first patch listed in the table is CVE-2015-6609, which we reported to Google in 2015.
https://source.android.com/docs/security/bulletin/2015-11-01#acknowledgements

2026-08-08 06:43:35 CEST

- reply

2026-08-08 06:30:09 CEST

- reply

2026-08-08 03:31:38 CEST

- reply

For Motorola devices, we plan to prepare our releases early and have everything ready for major Android updates at launch. We should be able to simply push the code to our own repositories for major Android releases. We'll need to host all the AOSP Git repositories ourselves.

2026-08-08 03:16:58 CEST

- reply

They're obligated to fulfill our requests. We need each of the Beta tags because we port and test in advance. If they don't want to deal with our endless requests for each release, they can simply push the tags to Git. They chose to waste the time of several employees on this.

2026-08-08 03:13:54 CEST

- reply

If they insist on using Google Drive, they could at least automate giving access. It shouldn't depend on a person going through a huge backlog as a low priority. Requests not being handled for weeks is unacceptable. They could simply push the Git tags and stop dealing with it.

2026-08-08 03:04:37 CEST

- reply

Google could simply push signed tags to Git instead of having a person assigned to go through form submissions and give access to specific files. They could also give access to folders instead of files to avoid needing to give us access to more files multiple times a month.

2026-08-08 03:00:01 CEST

- reply

These changes won't negatively impact GrapheneOS on upcoming Motorola Mobility devices. In fact, it's a major part of why our partnership exists. It only negatively impacts Pixels and hurts Google more than anyone else. Google wants to make Pixels worse for no apparent reason.

2026-08-08 02:51:56 CEST

- reply

Initially, Google would usually provide access to the tarballs within a couple hours. Lately, they're often taking weeks to get back to us. They're the ones who chose to use this archaic system instead of pushing Git tags and it's their responsibility to handle requests promptly.

2026-08-08 02:45:33 CEST

- reply

Prior to moving it to Google Drive, they started squashing the history into a single commit prior to pushing release tags. The tarballs provided via Google Drive have exactly the same source code. However, they went out of the way to make it more inconvenient in several ways.

2026-08-08 02:39:53 CEST

Google replaced pushing Git tags for certain source code with obtaining source code via Google Drive after making a request through Google Forms. It's completely ridiculous and they've gradually become very slow at handling requests. They're in clear violation of the GPLv2 now.

2026-08-07 22:47:29 CEST

- reply

In addition to one of the authors being a Senior Research Scientist at Google, it credits 4 people at Google for review including people in management. Google being so heavily involved in this extraordinarily inaccurate slop functioning as a hit piece on GrapheneOS is appalling.

2026-08-07 21:09:09 CEST

- reply

The paper links to a GitHub repository with code, data and a copy of the paper. It's strange they apparently never thought to run this against the AOSP release which the GrapheneOS release they tested was based on. There are 0 differences in most of the relevant code...
https://github.com/Demeter2025/AndroVET/tree/main

2026-08-07 21:01:46 CEST

- reply

This paper pushes Google's false narrative of alternatives to Google certified Android not providing standard patches and protections. A Google researcher being directly involved as an author is scandalous. The claims made by the paper about GrapheneOS are clearly false and it needs to be retracted.

2026-08-07 20:54:44 CEST

- reply

Play Integrity API is pushed based on the false premise that it's a security feature. In reality, it's a core pillar of an illegal anti-competitive business model and clearly harms security. It bans GrapheneOS despite it being far more secure than anything they certify including far better patching.

2026-08-07 20:51:29 CEST

- reply

Google published Android as an open source project and it succeeded based on it. For years, they've been engaging in illegal anti-competitive tactics to gain control over what was an open platform supposedly governed by a group of companies rather than Google. That includes the Play Integrity API.

2026-08-07 20:38:45 CEST

- reply

There are 4 authors listed for this. The person listed 3rd is a Senior Research Scientist in the Platforms Security and Privacy team at Google. It's published as part of the 2026 IEEE 11th European Symposium on Security and Privacy (EuroS&P). What happened here?
https://www.computer.org/csdl/proceedings-article/euros-p/2026/107400b376/2ixHNEzWcYE

2026-08-07 20:22:10 CEST

- reply

The paper is filled with statements which sound reasonable to non-experts but are nonsense. We wouldn't be surprised if most of the paper and code was LLM generated. There are many strong signs of it and it's hard to believe humans wrote all of this. We think it should be investigated further.

2026-08-07 20:16:34 CEST

- reply

Did a human truly write that sentence? We aren't aware of any background processes we've eliminated compared to AOSP. Our exploit protections certainly don't reduce CPU, memory or battery usage. We do take great care to minimize the overhead and provide toggles for features with a substantial cost.

2026-08-07 20:10:48 CEST

- reply

Aside from the incorrect premise and methodology, the paper is filled with many other inaccurate claims about GrapheneOS. Look at this example:
> For instance, GrapheneOS eliminates unnecessary background processes and applies exploit-hardening techniques to reduce CPU and battery usage.

2026-08-07 20:07:02 CEST

- reply

This paper is built around an incorrect understanding of how GrapheneOS is based on AOSP and Android's security patches. All of the patches included in Android at the time were shipped by GrapheneOS. If any of what they found was an actual issue, which is doubtful, then it was missing in AOSP too.

2026-08-07 19:56:37 CEST

- reply

It's common for the initial attempt at fixing a privacy and security issue to be incomplete or incorrect. These changes sometimes even introduce new vulnerabilities. There are often multiple rounds of partial fixes. Truly fixing it often requires major changes or rewrites impractical to backport.

2026-08-07 19:54:51 CEST

- reply

Many of the security issues fixed by Android for older releases aren't present in recent releases due to rewrites and changes to the code. Fixes in the development branch are often difficult to backport with major changes or entirely different approaches being needed. Backports are their own thing.

2026-08-07 19:48:16 CEST

- reply

If they checked the latest AOSP release at the time, they would have seen there's no actual difference in what their tooling finds between AOSP and GrapheneOS. The code they identified as not present in GrapheneOS wasn't in the latest AOSP release at the time. It also doesn't show anything is wrong.

2026-08-07 19:43:53 CEST

- reply

They should have easily figured out GrapheneOS releases are based on the latest AOSP release. They should have used their tooling on AOSP itself as a control. They would have gotten the same results for AOSP and GrapheneOS if they used versions from the same date. Instead, they're misleading people.

2026-08-07 19:33:33 CEST

- reply

The authors of the paper took the diffs from the Android Security Bulletins and created tooling to look for the changes made by those diffs being missing. They present the findings where they manually confirmed lines of code don't appear to be present as if those are missing patches in GrapheneOS.

2026-08-07 19:32:49 CEST

- reply

Android's development branch can do major refactoring and rewrites. It can make privacy and security improvements requiring substantial changes to the code. It can fix weaknesses requiring backwards incompatible changes. The backports don't even attempt to cover Low and Moderate severity patches.

2026-08-07 19:31:23 CEST

- reply

Android Security Bulletins are a list privacy and security patches backported to older releases of the OS. These aren't the privacy and security fixes made in the development branch but rather incomplete backports. Far more fixes made in the development branch and the approach is often different.

2026-08-07 19:27:33 CEST

- reply

The authors should have seen that each of releases has all of our changes to AOSP repositories cleanly rebased on top of the latest stable release. We do make substantial changes to AOSP but it can all be reviewed as a set of patches applied on top of the latest AOSP release with zero merge commits.

2026-08-07 19:20:55 CEST

- reply

This entire paper is based around a misconception. The authors wrongly believe we need to identify and incorporate all of the upstream changes into GrapheneOS. It's our changes we need to make sure to fully and correctly port to each new release of AOSP, not the other way around as they believe.

2026-08-07 19:08:13 CEST

- reply

We start fresh with each stable release of AOSP. All our changes are ported to the new source tree. There's no merging process but rather porting and submitting the changes to the new source tree. Major changes are often required including entirely rewriting certain features for the new release.

2026-08-07 18:59:34 CEST

- reply

Our AOSP changes are reviewed and improved on an ongoing basis. It's not only the code being improved but also commit structure. We're always preparing for porting to the next stable release. It's handled as if our AOSP changes are being prepared for submission to the project for the first time.

2026-08-07 18:41:21 CEST

- reply

The authors wrongly believe GrapheneOS has diverged from the Android Open Source Project (AOSP). The starting point for GrapheneOS is the latest stable release of AOSP with all of the AOSP security backport commits applied. Our changes to AOSP repositories are maintained as cleanly rebased patches.

2026-08-07 18:29:59 CEST

This paper is inaccurate slop. It makes a large number of clearly inaccurate claims about GrapheneOS and presents results which are verifiably false. It's filled with nonsense which appears AI generated.
> The Clone Strikes Back: Efficient Vulnerable Code Detection in Custom Android-based Systems

2026-08-06 14:05:51 CEST

- reply

Device and strong integrity won't pass since those require a Google certified OS. The difference between device and strong is mainly that strong always requires hardware attestation while device has loopholes permitting not having it. Strong is also the only tier with any form of security patch level check, but it only checks it for Android 13+ and permits a security patch that's up to a year out-of-date.

2026-08-06 13:36:49 CEST

- reply

> the unfortunate part is I can't download it from play store anymore at all
Do you pass the Play Integrity API basic integrity level? You can run one of the Play Integrity API checker apps to test this. We're getting inconsistent reports on whether people can install Revolut and sign into it. Some users are still able to do it while others can't. It's unclear exactly what they've changed which results in more people having issues installing it or logging in.

2026-08-06 04:44:14 CEST

- reply

Multiple traditional banks have started to specifically permit using GrapheneOS in addition to a Google certified OS. Revolut is doing the direct opposite. Most apps using the Play Integrity or similar checks also don't try to falsely claim GrapheneOS lacks security or compatibility as Revolut does.

2026-08-06 04:38:49 CEST

- reply

Revolut specifically tries to detect and ban GrapheneOS. It has checks for the build user/value values we set for deterministic builds so we had to change those. They also ban yellow verified boot state (locked with non-stock key) but not orange (unlocked) which we worked around.

2026-08-06 04:02:00 CEST

- reply

This likely still works for most users:
1) Log into a throwaway Google account so basic integrity passes.
2) Install Revolut via the sandboxed Play Store so the installer check passes.
We'll be shipping a secure solution fixing apps with an installer check in the near future.

2026-08-06 03:48:49 CEST

- reply

We worked around Revolut's blocking of GrapheneOS in January 2025 and got it working for everyone. However, it's still fully their intention to ban GrapheneOS and we've started seeing reports of users having issues logging in. It still consistently works when already logged in.

2026-08-06 02:48:07 CEST

- reply

If Revolut insists on doing a verification of the hardware, OS and app then they can use the hardware attestation API to verify GrapheneOS devices. They've received links to https://grapheneos.org/articles/attestation-compatibility-guide for years prior to their recent ban of GrapheneOS. They have no excuse to ban it.

2026-08-06 02:01:46 CEST

Revolut recently banned using GrapheneOS without any justification. They're falsely claiming to do be doing it for security reasons. In reality, they're enforcing licensing Google Play. Revolut doesn't enforce security standards. It runs on Android 9 with no patches since 2018.

2026-08-05 05:02:15 CEST

- reply

GrapheneOS passes basic integrity but isn't Google certified so device and strong won't pass. Around 10% of banking apps check for device integrity.
A growing number of banking apps are explicitly permitting GrapheneOS via hardware attestation as an alternative to the Play Integrity API. That means services checking for the Play Integrity API device integrity level doesn't imply those won't work on GrapheneOS.
It's very strange this photo sharing service checks the Play Integrity API.

2026-08-05 04:44:57 CEST

- reply

Is it triggering a Play Integrity API notification? It looks like it is that's only displayed as an option in the app settings when an app is using it. That means they're likely checking Play Integrity API responses on their server and enforcing basic, device or strong integrity.
You should try using a Play Integrity API checker app to see if you're passing basic which you should be.
Device and strong integrity are 2 tiers of assurance for Google certification which bans any other OS.

2026-08-03 23:21:58 CEST

- reply

The OS and firmware anti-rollback versions are only updated after it has successfully booted and disabled automatic rollback. It therefore can't trip in practice.
It can be tripped by attempting to install an OS using an unsafe install process even if it has current firmware. GrapheneOS uses a safe install process flashing firmware to the inactive slot, switching slot, rebooting and doing it again. It only installs the OS once firmware is flashed on both slots.

2026-08-03 23:11:33 CEST

- reply

Firmware and OS anti-rollback is a near universal feature on smartphones. It's not at all specific to Pixels and is a requirement for secure verified boot. Pixels support unlocking and flashing different firmware/OS images along with another OS verified boot public key to the secure element so it's more relevant. It's possible to hard brick a device with unsafe use of fastboot mode commands, but installing another OS can be done safely without it being possible.

2026-07-30 10:10:13 CEST

- reply

Desktop mode is fully functional. NFC works fine and there are tap-to-pay options available. Your bio implies you're in Norway so there should be multiple tap-to-pay options including Curve Pay compatible with GrapheneOS. Norwegian banks may also have it themselves since many European banks didn't move to Google Pay, although others did. Google Pay doesn't allow using GrapheneOS since it's not Google certified and it checks that via the Play Integrity API as do ~10% of banking apps.

2026-07-30 08:43:22 CEST

- reply

Our first official release based Android 17 was published 2 days after it was released. You'll still have the Android 17 features available on GrapheneOS such as the improved desktop mode that's no longer considered experimental. For the most part, only features tied to privileged Google app integration into the OS are unavailable.

2026-07-28 07:06:52 CEST

- reply

> sounds like you are talking about terrorism
That's an extreme reach while talking about an activist making a non-violent sacrifice for their beliefs.
> this dangerous feature
The feature is easy to understand and doesn't do anything unexpected. Enabling it and writing it down is legal.
He chose to use it in a way which has predictable consequences. There are plenty of other ways to use it without those.
> who value their data over their life
His life was never at risk.

2026-07-28 06:41:45 CEST

- reply

The situation was predictable and avoidable. For example, he could have made encrypted backups, set up the device again with what he needed in the very short term and restored the full data from the backups afterwards. Not every similar situation is predictable or avoidable.
Our duress PIN/password is for niche situations where someone makes the judgement call that the benefits outweigh the consequences. Plenty of people are willing to make a personal sacrifice for something.

2026-07-28 06:36:57 CEST

- reply

There was no court order for him to provide his PIN/password. The best option once he was already in the situation was very likely to refuse to provide it. He may have been held for many hours or even several days but likely would have been released without charges. If he was charged, he likely would have easily won based on the available information.
There are situations where using the duress PIN/password makes sense based on someone's priorities. We don't know his rationale.

2026-07-28 06:29:53 CEST

- reply

He wasn't going to be beaten until he provided the PIN/password. He might have been held for a long time but eventually would have been released. Refusing to provide a PIN/password is protected under US law in practice. That's not the case in a lot of the world but it is in the US.
Our duress PIN/password is a niche feature useful in specific circumstances. It's not one of the core protections against data extraction. Using it in the way he did likely wasn't a good decision.

2026-07-28 06:21:03 CEST

- reply

A smarter approach would have been refusing to provide the PIN/password and relying on the very strong protections against data extraction provided by GrapheneOS. It works very well at preventing it in the real world even against the most sophisticated adversaries.
There were multiple ways to prepare for the situation in advance to maximize protection against data extraction. Using a strong passphrase and rebooting in advance would rule out exploits being used to obtain user data.

2026-07-28 06:17:16 CEST

- reply

> GrapheneOS was never going to protect him in this instance
That's nonsense. He could have said nothing and let GrapheneOS protect the data from being extracted. Refusing to provide the PIN/password is protected under US law and GrapheneOS provides strong protection against exploits.
> the feature is worthless
Duress PIN/password is a useful feature. Someone using it in a case where they'd likely have been better off relying on the main protections doesn't make it worthless.

2026-07-26 15:44:41 CEST

- reply

An edit has been made to the post to add the following information:
> The duress PIN will also wipe the device when entered as a 2nd factor PIN for fingerprint unlock, but not a SIM PIN.

2026-07-26 06:17:48 CEST

We've published an overview of how we protect against data extraction from locked devices with the recently improved secure element rate limiting, locked device auto-reboot, strong passphrases, 2nd factor fingerprint PIN, stronger exploit protections and more:
https://discuss.grapheneos.org/d/40700-grapheneos-protections-against-data-extraction-from-locked-devices

2026-07-25 06:08:18 CEST

- reply

It will only be future Motorola devices providing what we need. The initial ones will be flagships because those will be the first with the updates and security features we need. It will be able to expand to more devices from there. We need to carefully choose devices but we do want to include some more budget devices. It likely won't go below equivalents to the Pixel 'a' series range because it's unlikely low end devices will provide what we need any time soon.

2026-07-25 03:34:16 CEST

- reply

The Motorola devices will be more internationally available especially once there are lower priced ones providing official GrapheneOS support. It 's starting with the flagships because Qualcomm rolls out security features to those first and it will likely be a while before even the high end non-flagship ones have what we need.

2026-07-25 02:27:16 CEST

- reply

We have a non-exclusive partnership with Motorola Mobility (Lenovo) to bring GrapheneOS to future devices from them providing all of our hardware requirements and official GrapheneOS support.
They'll provide us with the driver and firmware support we need without us needing to reverse engineer stock OS code and extract firmware, configurations, driver libraries, etc. from factory images.
It will start with flagships since they'll be the first with what we need but will expand.

2026-07-25 02:25:37 CEST

- reply

Most smartphones don't allow using another OS. Most of the ones permitting it cripple functionality including security if one is used.
Most computers including a large portion of smartphones lack of ongoing firmware security updates which we can't solve for those. It's quite important to have security updates for GPU, Wi-Fi, Bluetooth, cellular, NFC and UWB radio firmware along with other components exposed to attacks.
Most smartphones lack features we use to protect users too.

2026-07-25 01:19:47 CEST

- reply

You brought up both userspace compatibility and the userspace HALs. The kernel's rule of not breaking userspace doesn't stop userspace code breaking unless the the userspace code it depends on maintains compatibility too. Desktop Linux doesn't preserve the compatibility that the Linux kernel provides with legacy code. You brought it up implying Android didn't preserve it when it does a far better job with it in reality.

2026-07-25 01:11:55 CEST

- reply

Android also works fine with a mainline kernel.

2026-07-25 01:09:23 CEST

- reply

Desktop Linux doesn't follow the don't break userspace rule. It's a kernel rule not followed in userspace by those.
Android keeps ancient apps working. It uses store policies to force updating to new API levels with major backwards incompatible improvements. That includes yearly backwards incompatible privacy and security changes. Desktop Linux can't force similar app ecosystem improvements AND lacks the backwards compatibility.

2026-07-25 01:03:38 CEST

- reply

A standard Android kernel image (GKI) and userspace OS image with all of the non-device-support code (GSI) can be booted across all certified Android devices with all of the standard functionality working. The kernel image can be updated within a branch alone and the OS can be updated to new major versions. None of that is useful to GrapheneOS or Pixels. It's an annoyance for us rather than benefiting us. It's useful to others.