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

grapheneos_at_grapheneos.social@momostr.pink

Profile Code

nprofile1qqst8w3u2pzlhtueh6wtfk4f78tm4mk6hg8utwg4jeg3utah5uxa07gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dslp5jg4

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1kwarc5z9lwhen05uknd2nuwhhthd4ws0cku3t9j3rchm0fcd6luslse0nj

Show more details

Last Notes

2026-09-30 18:54:43 UTC

- reply

Your website promotes highly insecure and non-private options. Your site wrongly claims the options you promote are more private than using macOS or iOS.
/e/, iodéOS and LineageOS do not provide highly important standard Android privacy/security patches and protections. iodéOS and /e/ lag significantly further behind on updates than LineageOS.
/e/ and Murena heavily mislead users about privacy and security along with heavily pushing anti-privacy authoritarian talking points.

2026-09-12 19:22:07 UTC

- reply

Bitcoin's lack of on-chain privacy is a massive flaw. The mass surveillance enabled by the transparency blockchain is so far against the original ideals of the project.
Lightning doesn't provide strong privacy and isn't a solution to the lack of privacy in the Bitcoin base layer. Semi-centralized approaches as side chains aren't solving it either.
There's no fundamental blocker against Bitcoin implementing a shielded pool.

2026-09-12 16:12:07 UTC

- reply

GrapheneOS gets a lot of support from people on Hacker News despite a bunch of malicious accounts trying to undermine us and moderation biased against us. We didn't have a solution to the past 2 weeks of our posts getting flagged today beyond asking for help on social media since we need people to vouch for our posts to undo that.
If we were going to leave hostile spaces then Mastodon would be the first to go especially after the most recent few rounds of unfair attacks on us.

2026-09-12 15:41:31 UTC

- reply

Hacker News is owned by Y Combinator, an American venture capital firm heavily invested in surveillance tech. Their moderators have time to remove our posts for copy-pasting small amounts of text but not to remove years of libel and harassment. Perhaps it's time for legal action.

2026-09-12 15:34:37 UTC

- reply

There have been years of personal attacks directed towards our team on Hacker News primarily consistenting of libel. Many of these the threads with this content are highly search ranked. Hacker News moderators have been clearly active in many of those threads without removing it.

2026-09-12 15:31:52 UTC

- reply

Posts from these accounts making endless personal attacks on our team, linking to harassment content and making clearly disingenuous attacks are what should actually be getting flagged. Those posts getting flagged is becoming more common and the trolls have been complaining.

2026-09-12 15:21:55 UTC

- reply

If you have an established account on Hacker News, enable "showdead" in your settings, open our flagged posts and press "vouch" to help restore them. People have gone back through quite a lot of our posts and wrongly flagged them despite there being nothing inappropriate at all.

2026-09-12 15:20:22 UTC

- reply

There are numerous accounts malicious towards GrapheneOS on Hacker News which show up to make disingenuous attacks on it and downvote/flag all of our posts. Here's an example of one of those accounts which openly promotes Kiwi Farms harassment content:
https://archive.ph/JAunG

2026-09-12 15:13:51 UTC

Nearly all of the recent posts we've made on Hacker News are now being flagged which hides them from everyone by default. You can see this if you log into an account and enable "showdead" in your settings. Please vouch for our posts if you can do that.
https://news.ycombinator.com/threads?id=grapheneos

2026-09-11 01:49:56 UTC

- reply

People's conversations, thoughts and financial transactions have been largely private for most of human history. Law enforcement still managed to do their jobs. They can continue to do so in a world where privacy technologies preserve historical privacy norms.
We use and support open source projects working on restoring the privacy provided by cash including Monero. Moving from cash to credit cards, PayPal, etc. is an ongoing privacy disaster. Bitcoin and Ethereum currently are too.

2026-09-11 01:31:21 UTC

@npub19xk…6hgp GrapheneOS is an open source privacy project with a development team spread around the world. It exists to protect people from corporate and government surveillance.
GrapheneOS isn't a business and our legal entity is a Canadian non-profit organization.
GrapheneOS is entirely funded by donations. The majority of the donations are made via cryptocurrency.
We pay people an hourly rate set in USD or CAD. We currently pay around 14 people with Ethereum donations and 1 person with CAD.

2026-09-08 19:08:42 UTC

- reply

It's what we expect external contributors to do especially since the majority of people trying to make contributions are clearly heavily using AI models to do most of the work.

2026-09-08 18:54:51 UTC

- reply

The developer creating the code is the author. They need to fully understand the code, rewrite whatever they generated with AI tools as necessary and take full responsibility for it. A tool they used to make it isn't who we consider the author. Creating a Git commit with an IDE resulting in the IDE claiming to be a co-author of the code is silly. It's a way of doing marketing via Git commit messages. We removed that from several small commits fixing minor issues someone submitted.

2026-09-08 18:07:22 UTC

- reply

We don't forbid using AI models for writing code but pull requests largely created that way will typically be rejected or skipped due to not meeting our requirements. It needs to be well written code which appears to be regular code written by a human regardless of the level of AI assistance involved in making it. It should not look like AI generated code. We do want to know if AI models are being used and how they're being used rather than people using it but not telling us they're using it.

2026-09-08 17:52:43 UTC

- reply

Going from having a working implementation of a feature to code we can merge often takes a long time. It can take months or even more than a year. It doesn't always work out. Sometimes we decide a feature ended up being too invasive or risky for other reasons and don't want to include it. We'll often do rewrites. Contributors need a full understanding of what they've submitted and need to be prepared to make substantial changes including fully rewriting it multiple times. AI slop isn't accepted.

2026-09-08 17:48:26 UTC

- reply

We have high standards for code being merged into GrapheneOS, especially for code in critically important parts of the project. Most of the changes made to the OS are to critically important parts of the code. It takes a long time to get features to meet our standards. There's usually a lot of back and forth review with many improvements requirements for anything significant. External contributors shouldn't try to take on major features without talking to us and planning that out with us first.

2026-09-08 17:43:19 UTC

- reply

We want people to report very serious Android Open Source Project security bugs to us but we can't handle a lot of minor issues. We don't generally need Chromium security bugs reported to us because they handle those far more quickly and have a far better system for releasing it. Linux kernel security bug reports are useful if they refused to fix it (arm64 kASLR) or it didn't get backported to the LTS. GKI LTS being behind the LTS is a separate problem we'll be addressing ourselves again soon.

2026-09-08 17:35:27 UTC

- reply

It isn't a good idea for people to point a model at an open source project and then start submitting bug reports to it. People need to be able to confirm the issues themselves with relatively high confidence before reporting it. It's okay to make some mistakes but it should not be the majority of what's reported. We do want people to report these kinds of security bugs to us but the signal to noise ratio is far too low right now. Even frontier models spew out contrived nonsense and fabrications.

2026-09-08 17:11:11 UTC

GrapheneOS imposes a set of restrictions on how generative AI can be used in our project and community. It isn't forbidden but rather we imposed rules based on actual issues.
Posts made in our forum, chat rooms, issue tracker and the rest of our project must be written by humans. There's an exception from this rule for translation and accessibility features. That means commit messages, pull request messages, bug reports and feature requests are expected to be written by humans, not a machine.

2026-09-08 12:49:58 UTC

- reply

We didn't say that at all. We said we've started using AI models for extra passes of code review for our own code and that it consistently finds real issues missed by human code review.
We could use it to find a large amount of serious bugs in many of the upstream open source projects we depend on lack resources to identify and resolve a large number of upstream security bugs ourselves. There's already a massive effort doing that for the Linux kernel and many other projects without us.

2026-09-07 06:01:57 UTC

- reply

Android 17 QPR2 Beta 4 added minimal firmware support for MTE but they still have it fully disabled in the stock OS. It's now possible to enable it via fastboot mode and then use it in the stock OS via ADB but it's not in the regular state it is for the other devices with MTE support. It isn't available as part of Android Advanced Protection Mode or as a developer options feature.
It isn't clear why it isn't enabled for use in the stock OS yet. It appears to work fine and performs fine.

2026-09-06 07:36:42 UTC

GrapheneOS version 2026090500 released:
https://grapheneos.org/releases#2026090500
See the linked release notes for a summary of the improvements over the previous release.
Forum discussion thread:
https://discuss.grapheneos.org/d/41757-grapheneos-version-2026090500-released
#GrapheneOS #privacy #security

2026-09-02 02:02:03 UTC

- reply

Multiple Google engineers we've contacted have said they aren't able to give us any information about this so we're left doing reverse engineering and relying on leaks. The leaks do not seem reliable and do not match what we see. Our concern is that MTE may actually be broken due to CPU errata.

2026-09-02 02:00:16 UTC

- reply

Our initial testing indicates performance isn't substantially worse. The overhead may be higher but there was an incremental CPU performance with the Pixel 11 which should more than make up for it. However, MTE is unavailable with stable firmware and we're bypassing firmware disabling it for QPR2.

2026-09-02 01:56:45 UTC

- reply

There have been multiple leaks from Google including info published on news sites indicating hardware related to MTE was cut. There have also been leaks indicating it has performance issues and that's why it was initially fully stripped out at a firmware level firmware and is force disabled in QPR2.

2026-09-02 01:50:40 UTC

- reply

Android 17 QPR2 Beta 4 on the Pixel 11 force disables MTE for the OS from the firmware. Using it requires ignoring the arm64.nomte parameter being passed to the kernel. It still isn't clear why they're making the feature unavailable. SVE was also force disabled in Android 17 but not in QPR2 Beta 4.

2026-09-02 01:46:56 UTC

- reply

We've been testing performance of MTE on the Pixel 11 using the Android 17 QPR2 Beta 4 release adding back firmware support for it. MTE in asymmetric mode only has around 5% overhead in the standard benchmarks and other tests we've done. That's more than good enough but we've done limited tests.

2026-09-01 05:38:43 UTC

- reply

Android 17 QPR2 Beta 4 releases for the Pixel 11 series were only uploaded around 10 hours ago rather than with the initial release on August 28th so this hasn't been available for very long. It wasn't missed by us or people who looked into it after our initial thread but rather wasn't out yet.

2026-09-01 05:25:28 UTC

- reply

Google has been increasingly silent in response to our communications since dropping Pixel support from AOSP with Android 16 in June 2025. They could have told us MTE performance was significantly reduced so they disabled it at launch but will add it back to firmware for QPR2. That's still unclear.

2026-09-01 05:19:57 UTC

- reply

If the issue is simply that MTE performance is poor, then we can support the Pixel 11 with the major caveat that it will be a significant performance downgrade. Aside from MTE, Google downgraded the Pixel 11 series GPU compared to the Pixel 10 series in addition to reducing RAM for base Pro models.

2026-09-01 05:15:50 UTC

- reply

We reached out to multiple people at Google asking about the MTE situation on the Pixel 11 prior to making our original thread and didn't receive any responses. We still don't know what's wrong with MTE on the Pixel 11. It isn't clear if there are serious CPU errata or it simply performs very badly.

2026-09-01 05:10:30 UTC

- reply

We expect performance must be quite bad for Google to have decided to entirely strip out support for it in not only the software but also the firmware so that no would could even try to use it before Android 17 QPR2 Beta 4. That's a very strange thing to do. It's at least added back to firmware now.

2026-09-01 05:08:08 UTC

- reply

It's possible to enable reserving the tag memory for MTE via `fastboot oem mte on`, boot a non-stock kernel ignoring arm64.nomte and use MTE. We're in the process of determining whether it's fully functional and the performance characteristics. It's likely disabled due to performance being ruined.

2026-09-01 05:02:34 UTC

- reply

Android 17 QPR2 Beta 4 was released on August 28th. It's the first Beta release with Pixel 11 support. MTE support is still completely disabled in the OS and arm64.nomte is unconditionally passed by the firmware to the kernel. The good news is the firmware itself had MTE support added back to it.

2026-09-01 04:57:14 UTC

We have good news about the Pixel 11. It still has at least bare minimum support for MTE at a hardware level. We think they removed most of the hardware acceleration from the CPU cache to save money. They ruined the performance so it ended up being fully disabled in firmware. It may still be usable.

2026-08-29 15:14:50 UTC

- reply

Compared to the Pixel 11, a Snapdragon 8 Elite Gen 5 has ~40% higher single threaded CPU performance, ~80% higher multi threaded performance, over 100% higher GPU performance and a far better cellular radio. It also finally has MTE. The next gen is what will be in the first Motorola with GrapheneOS.

2026-08-29 15:08:17 UTC

- reply

Pixel 11 series is a lot more expensive for an incremental improvement to the CPU, the same underpowered GPU and reduced RAM for the Pro base models. They finally caught up to the last generation of Qualcomm cellular radio. It's overpriced, the upgrades aren't impressive and losing MTE is appalling.

2026-08-29 14:56:38 UTC

- reply

Pixel 11 does have security improvements including moving to post-quantum secure verified boot (ML-DSA) and replacing Samsung Shannon IMS with AOSP IMS. Titan M3 should significantly improve protection against data extraction in Before First Unlock state. It's too bad they ruined it by cutting MTE.

2026-08-29 14:51:27 UTC

- reply

Neither iOS or Android encourage app developers to opt into MTE and other more aggressive security features used in the base OS. Apple's docs warn developers of performance and stability issues. Even Signal doesn't opt-in. Our approach enables forcing using MTE in the standard allocators regardless.

2026-08-29 14:46:56 UTC

- reply

Apple's MIE and Android 16+ AAPM don't use MTE for user installed apps unless those explicitly opt in. GrapheneOS enables it for more apps automatically and has a toggle for users to opt-in for every user installed app. There's a per-app toggle to opt-out for incompatible apps which is uncommon.

2026-08-29 14:40:34 UTC

- reply

Apple's Memory Integrity Enforcement (MIE) is an always enabled feature on the iPhone 17. It's simply a high quality implementation of MTE using the latest standard extensions. It uses MTE in the most secure mode in the kernel and a large portion of userbase. They did a very good job integrating it.

2026-08-29 14:36:10 UTC

- reply

Pixel 8 launched with hardware MTE support in October 2023. We integrated it into our hardened_malloc project and began using it across the OS later that month. Android and the Pixel OS never started using it by default. Android Advanced Protection Mode in Android 16 enables it for a few processes.

2026-08-29 14:29:34 UTC

- reply

ARM hardware memory tagging (MTE) is used by GrapheneOS across the entire base OS including the kernel and every standard base OS process. It's only temporarily disabled for a few device-specific processes. It greatly improves protection against nearly all remote exploits and many local exploits.

2026-08-29 14:19:30 UTC

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-22 01:26:12 UTC

- 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 00:56:52 UTC

- 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 00:40:21 UTC

- reply

Motorola is doing a large portion of the work of porting GrapheneOS to their devices. They'll provide us with what we need for firmware/drivers in the form we need it and it will be far easier than Pixels. We'll be able to get issues in the firmware and drivers fixed through Motorola and Qualcomm.

2026-08-22 00:38:17 UTC

- 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 00:35:57 UTC

- 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 00:33:43 UTC

- 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 00:30:26 UTC

- 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 00:28:42 UTC

- 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 00:16:06 UTC

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-11 23:03:38 UTC

- 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-11 22:59:50 UTC

- 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-11 22:59:39 UTC

- 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-11 22:59:33 UTC

- 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-11 22:59:15 UTC

- 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-11 22:59:07 UTC

- 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-11 22:58:50 UTC

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 17:31:25 UTC

- 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 15:04:13 UTC

- 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 01:31:38 UTC

- 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 01:16:58 UTC

- 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 01:13:54 UTC

- 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 01:04:37 UTC

- 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 01:00:01 UTC

- 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 00:51:56 UTC

- 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 00:45:33 UTC

- 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 00:39:53 UTC

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 20:47:29 UTC

- 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 19:09:09 UTC

- 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 19:01:46 UTC

- 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 18:54:44 UTC

- 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 18:51:29 UTC

- 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 18:38:45 UTC

- 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 18:22:10 UTC

- 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 18:16:34 UTC

- 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 18:10:48 UTC

- 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 18:07:02 UTC

- 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 17:56:37 UTC

- 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 17:54:51 UTC

- 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 17:48:16 UTC

- 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 17:43:53 UTC

- 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 17:33:33 UTC

- 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 17:32:49 UTC

- 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 17:31:23 UTC

- 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 17:27:33 UTC

- 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 17:20:55 UTC

- 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 17:08:13 UTC

- 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 16:59:34 UTC

- 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 16:41:21 UTC

- 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 16:29:59 UTC

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 12:05:51 UTC

- 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 11:36:49 UTC

- 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 02:44:14 UTC

- 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 02:38:49 UTC

- 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 02:02:00 UTC

- 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-07-31 00:04:11 UTC

- reply

Control over the frame rate is a planned feature in the near term. This release is a maintenance release to catch up on many dependency updates and fix many known issues.
Our Camera app is going to receive a complete user interface overhaul and major new features over the coming months. Our current focus is on a near complete overhaul of the Messaging app and a new Gallery app for GrapheneOS forked from an open source project. Keyboard is also a priority and we'll overhaul the rest too.

2026-07-30 23:46:24 UTC

GrapheneOS Camera app version 91 released:
https://github.com/GrapheneOS/Camera/releases/tag/91
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/40836-grapheneos-camera-app-version-91-released
#GrapheneOS #privacy #security #camera #android