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-04-14 19:17:04 CEST

- reply

When are they going to correct their claims that GrapheneOS isn't a privacy project, doesn't do much for privacy, isn't intended for regular people, isn't usable by regular people and much more? Why do they support a company and project which repeatedly claim providing decent privacy and security protections primarily helps criminals and spies? What kind of privacy advocates support that and stand behind those egregious inaccuracies about GrapheneOS?

2026-04-14 11:33:38 CEST

- reply

We have a lot of experience with our users asking about this and needing to have their misconceptions addressed. Many people are using this as a major factor in how they choose apps where they believe apps being listed as having 0 trackers means those apps aren't privacy invasive. Similarly, people are interpreting the permission count as meaning something it doesn't. An app which doesn't require granting anything invasive to use it is often shown as very invasive there.

2026-04-14 11:27:05 CEST

- reply

Ads, analytics, telemetry, crash reporting and similar things done on the client side with connections to dedicated domains are not the most privacy invasive behavior done by apps. There are certain types of client side SDKs which are quite invasive but those things are nowhere close. This definition of trackers and interpretation of what matters is something we've been educating our users about for years. A large portion of people exposed to this are misled by it.

2026-04-10 21:35:10 CEST

- reply

Here's Gaël Duval linking to harassment content on a neo-nazi conspiracy website targeting our founder with fabricated stories:
https://archive.is/SWXPJ
https://archive.is/n4yTO
This content is based around existing harassment content from another company attacking us (Copperhead). Copperhead lost their war on GrapheneOS and we're wrapping up their legal defeat, but the lies and harassment they started is still ongoing and Duval engages in it.

2026-04-10 20:01:17 CEST

- reply

The only way you're going to convince us to post less about it is putting in work to address it yourself and getting others to do that too. The only thing you'll achieve posting replies saying we shouldn't respond to these attempts to mislead people about GrapheneOS is us posting more about it as we're doing right here. You aren't going to get the result you want this way. There's a way for you to get the result you want by helping so we don't have to do as much.

2026-04-10 19:59:34 CEST

- reply

GrapheneOS will succeed based on merit. Our focus is making GrapheneOS better as it has always been. If we were left alone to do our work in peace then we wouldn't post threads debunking the attacks and would post more about other things including a lot more posts about our ongoing work. If people want that then they can help debunk the attacks so we feel much less need to do it because it's already being heavily done by others. Otherwise, we'll continue doing it.

2026-04-10 19:49:30 CEST

- reply

GrapheneOS has been enormously harmed by years of companies misleading people about it. There's a concerted effort by /e/, Murena and their supporters to mislead people into believing GrapheneOS isn't a privacy project and that they wouldn't benefit from the major privacy and security improvements it provides. @npub15r7…62av is directly peddling talking points from Gaël Duval aimed at steering people away from GrapheneOS to insecure Murena products. This isn't a minor issue.

2026-04-10 19:35:47 CEST

- reply

We aren't finished responding to it with this thread. We're going to be posting it on our forum and other social media platforms too. We're going to be responding beyond what we're already posted. We've been actively finding and archiving more cases of /e/, Murena and Gaël Duval attacking GrapheneOS by claiming it's only useful to criminals and spies which they've said directly multiple times along with often alluding to it. We have a lot more than that one video clip to use.

2026-04-10 19:30:26 CEST

- reply

You've likely already read our previous thread where we directly addressed these inaccurate claims. Here's the relevant part of the thread:
https://grapheneos.social/@GrapheneOS/116354014750484314
We're repeatedly published content addressing people inaccurately claiming GrapheneOS is a security project rather than a privacy project. He has read multiple of these threads and knows what we've said. He's saying what he did in the interview despite that. This isn't about getting any technical details wrong.
#note1ws9…4x6l

2026-04-10 19:27:28 CEST

- reply

He directly responded to the thread we published 4 days ago addressing Murena once again claiming the kind of privacy and security hardening work done by GrapheneOS and iPhones is only useful to criminals and spies. In that thread, we directly addressed these repeated inaccurate claims about the purpose, goals and approach of GrapheneOS which wrongly portray it as a security project rather than a privacy project. His claims in the interview are more than egregiously inaccurate.

2026-04-10 16:27:42 CEST

- reply

Exodus Privacy uses a very similar approach to label apps as having trackers based on whether they include a library from a small list they've decided as trackers. Many of those decisions are dubious and it misses that the most privacy invasive behavior by apps isn't done that way. It also has extremely inaccurate labelling of permissions misleading users about how that works. Here's a great example of both with Facebook Lite:
https://reports.exodus-privacy.eu.org/en/reports/com.facebook.lite/latest/

2026-04-10 16:26:20 CEST

The claims made about GrapheneOS in this interview are extremely inaccurate. It heavily misrepresents the purpose of GrapheneOS and what we've worked on for years. The claim GrapheneOS is a security project rather than a privacy project is misinformation. Contacts are specifically brought up and yet our Contact Scopes feature is ignored. @fla knows GrapheneOS is a privacy project. He replied to a thread with our response to this misinformation only 4 days ago...
https://piaille.fr/@projetslibres_podcast/116379561169492214
#note1dg3…tqhl

2026-04-10 15:39:05 CEST

- reply

The claims made about GrapheneOS in this interview are extremely inaccurate. It heavily misrepresents the purpose of GrapheneOS and what we've worked on for years. The claim GrapheneOS is a security project rather than a privacy project is misinformation. Contacts are specifically brought up and yet our Contact Scopes feature is ignored. @npub15r7…62av knows GrapheneOS is a privacy project. He replied to a thread with our response to this misinformation only 4 days ago...

2026-04-09 19:09:57 CEST

- reply

GrapheneOS doesn't have a centralized push notification service integrated into the OS. If you install Signal in a profile where you haven't installed sandboxed Google Play, it will only use Signal's own servers for push.
Signal's push implementation isn't power efficient and will drain a lot more power than Google's Firebase Cloud Messaging. However, there's a fork of Signal called Molly supporting using an arbitrary push provider with efficient implementations available.

2026-03-09 23:42:36 CET

- reply

That's an outrageously inaccurate story. Rossmann engaged in months of bullying towards the founder of GrapheneOS both privately and publicly. He also supported Henry Fisher's public bullying campaign based around fabrications. There's nothing polite about the toxicity he engaged in towards us. After swatting attacks from Henry Fisher's community targeting the founder of GrapheneOS, Rossmann live streamed himself trolling him and then followed it up making a video out of it.

2026-03-06 22:52:08 CET

- reply

Yes, but patches were already included before the 145 branch too.

2026-03-06 22:40:08 CET

Vanadium version 146.0.7680.65.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/146.0.7680.65.0
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/32825-vanadium-version-14607680650-released
#GrapheneOS #privacy #security #browser

2026-03-03 18:15:30 CET

- reply

For network-based location, enabling "Wi-Fi scanning" is recommended since otherwise it has to fall back to only using cell towers when Wi-Fi is disabled and can't function if cellular is disabled. Wi-Fi scanning changes the meaning of the Wi-Fi toggle to allow scans when off.

2026-02-20 16:46:06 CET

- reply

Android is mobile Linux. Linux doesn't mean glibc, systemd and GNOME. The desktop Linux software stack has atrocious privacy and security compared to the Android Open Source Project. There's a large and far better open source mobile app ecosystem for AOSP alongside the rest of the Android app ecosystem. Google's announced changes don't have any direct impact on an AOSP-based OS that's not licensing Google Mobile Services. The changes only amount to added UI friction for a GMS OS.

2026-02-12 17:21:47 CET

We need more 10Gbps or higher dedicated servers for hosting our OS and app updates. We have North America covered well enough via sponsored servers from ReliableSite in both Miami and Los Angeles and a sponsored server from Xenyth in Toronto but no longer have any left in Europe.

2026-01-29 22:54:34 CET

We've built our own text-to-speech system with an initial English language model we trained ourselves with fully open source data. It will be added to our App Store soon and then included in GrapheneOS as a default enabled TTS backend once some more improvements are made to it.

2026-01-22 08:03:45 CET

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

2026-01-04 01:42:42 CET

- reply

Here's your own timelime:
https://mastodon.social/@giorgiopasqualini
One of the two posts is boosting a serial harasser who targeted both DivestOS and GrapheneOS with fabricated stories and direct harassment including vile personal attacks. We showed an example here of him linking to harassment content on a neo-nazi conspiracy site and we can show a lot more.
https://archive.is/SWXPJ
https://archive.is/n4yTO
He's a scammer harming privacy projects.

2026-01-04 01:41:15 CET

- reply

You've made it very clear in this thread that you're an authoritarian who doesn't believe in privacy or security but rather you want the government to have access to people's devices and engage in mass surveillance. It makes sense that you use and support /e/ because it's perfectly aligned with all of that. Governments support "data sovereignty" so they can enforce providing them access to people's data and backdoors in encryption.

2026-01-04 01:39:28 CET

- reply

GrapheneOS is not in remotely the same space as other alternate mobile operating systems. None of those is a privacy or security hardened OS. They're only alternatives to the mainstream options with significantly worse privacy and dramatically worse security than an iPhone. You promote scam products from Murena, a company which has engaged in many years of attacks on real privacy/security options including harassing the developers.

2025-12-08 01:46:50 CET

Android 16 QPR2 experimental releases will be available soon. We're dealing with a lot of attacks on the project branching off from the smear campaign in France. We'd appreciate if our community would debunk this nonsense across platforms for us so we can focus on QPR2. Thanks.

2025-11-25 19:40:30 CET

- reply

It's absolutely not a single story. Law enforcement did interviews with dozens of news publications. It's trivial for anyone to debunk your incredibly false claim by doing basic research. Blaming this on a specific newspaper is utter nonsense. How do you explain the multiple French state-funded news agencies which covered it and posted similar content with extreme inaccuracy and bias? Why are you ignoring all the direct quotes from French law enforcement about it?

2025-11-24 20:24:16 CET

- reply

France won't tolerate devices with a reasonable level of security where they can't use widely available off-the-shelf tools to extract data from them. GrapheneOS has massive privacy and security improvements planned.
France's law enforcement sent out memos to all their police telling them to suspect Pixel phones and to give those special treatment due to GrapheneOS existing. Most of what they're talking about is clearly not even GrapheneOS but closed source forks...

2025-10-25 00:15:46 CEST

Pixel Camera recently added a hard dependency on Google Play services. It still works on GrapheneOS, but started requiring sandboxed Google Play services.
GmsCompatLib version 100 for GrapheneOS 2025102300 or later restores support for Pixel Camera without Play services:
https://grapheneos.social/@GrapheneOS/115431369734974446

2025-10-12 08:07:19 CEST

- reply

Our discussion forum, Reddit and X allow very long responses compared to having the standard 500 character limit from Mastodon here so it's harder to give detailed replies here. We should probably patch Mastodon to raise the limit as many instances do but would greatly prefer if they just made it configurable upstream.

2025-10-07 03:31:41 CEST

- reply

Possibly a glitch with the hardware-level sensor hub which implements this. Not really clear. It might have just gotten into a weird state. A reboot generally fixes those rare issues. Some hardware isn't fully reset on reboot and turning off completely + turning on again can work around those glitches. These issues are rare but they do happen and we have a lot of users so we regularly encounter people running into rare issues like this where we haven't heard of it ever before.

2025-09-27 19:29:11 CEST

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

2025-09-26 21:34:47 CEST

Vanadium version 141.0.7390.43.1 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/141.0.7390.43.1
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/26856-vanadium-version-14107390431-released
#GrapheneOS #privacy #security #browser

2025-08-27 21:52:50 CEST

We've received the Pixel 10 we ordered and have confirmed it supports unlocking, flashing another verified boot key and locking again.
Our Pixel 10 support will likely only be possible to complete after we finish porting to Android 16 QPR1 which is being released in September.

2025-08-09 18:44:37 CEST

- reply

GrapheneOS has a toggle for users to control MTE on a per-app basis and has a global toggle for making it enabled by default for all user installed apps, which we recommend people enable if they understand how to deal with incompatible apps with bugs found by MTE during regular use. We show special notifications for it with the crash log and users can disable it for just the app with the issue instead of turning it off for their other apps.

2025-08-08 18:26:44 CEST

- reply

https://www.sec.gov/Archives/edgar/data/2009536/000200953624000001/xslFormDX01/primary_doc.xml is the SEC filing for shares issued in February 2024 by a for-profit telecommunications company founded in 2019. The owners of the company are Nicolas Merrill, Louis Rossmann and Steve Gerber. This raises a lot of questions, as does other publicly available information.

2025-07-22 16:12:24 CEST

- reply

Here's information from the founder of DivestOS:
Issues with /e/OS: https://codeberg.org/divested-mobile/divestos-website/raw/commit/c7447de50bc8fadd20a30d4cbf1dcd8cf14805a0/static/misc/e.txt
ASB update history: https://web.archive.org/web/20241231003546/https://divestos.org/pages/patch_history
Chromium update history: https://web.archive.org/web/20250119212018/https://divestos.org/misc/ch-dates.txt
Chromium update summary: https://infosec.exchange/@divested/112
Here's an article from a privacy and security expert (Mike Kuketz) which touches on various issues including severely delayed patches, user tracking in the update client and privacy invasive default connections:
https://kuketz-blog.de/e-datenschutzfr

2025-07-20 18:55:10 CEST

- reply

Governments shouldn't fund building products for companies to sell for profit. We wouldn't want to be beholden to governments, particularly ones moving towards making end-to-end encryption and secure devices illegal.
/e/OS and Murena are not colleagues or competitors. /e/OS massively rolls back privacy and security rather than improving them. They heavily misrepresent what they're providing and through that are scamming people. /e/OS is nearly the direct opposite of GrapheneOS.

2025-07-19 18:48:35 CEST

- reply

Murena is a for-profit company and /e/OS is very clearly built and managed for the benefit of Murena. Despite this, /e/OS receives a huge amount of EU government funding. If you're an EU taxpayer, your money is being used to build this extraordinarily insecure and non-private OS.

2025-07-18 21:36:01 CEST

- reply

/e/OS is an extraordinarily insecure and non-private OS. If people avoid it and use an iPhone instead, they'll have far better privacy and security.
The information we've provided in this thread and on our forum is accurate and verifiable. We've included a link to a post by Mike Kuketz, a neutral third party privacy/security researcher, where he covers many of the issues with /e/OS. We can include additional third party sources about it.
/e/OS is not safe and SHOULD be avoided.

2025-07-18 19:53:58 CEST

We published this response to a recent article promoting insecure devices with /e/OS with inaccurate claims, including inaccurate comparisons to GrapheneOS:
https://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private
The founder of /e/OS has responded with misinformation promoting /e/OS and attacking GrapheneOS.

2025-07-10 21:19:24 CEST

- reply

> But not sure what you mean by "sock puppet" accounts, the implication here is that we are creating some accounts that would undermine GrapheneOS? If so, this is ridiculously untrue - all statements we make, we make under our own name.
We didn't accuse you of doing anything. We said someone malicious is making accounts on SimpleX to attack the GrapheneOS project which is not your fault and we don't expect you to do anything. They're an obsessive stalker targeting GrapheneOS.

2025-06-30 18:27:41 CEST

- reply

GrapheneOS fully supports device management. It's seamless to set it up for a work profile. For setting it up for the whole device to make it owned by a company, which should never be done with a personal device, it requires using ADB because we don't yet have setup wizard integration for it. For a work profile, everything needed is provided. There are some management apps which can't handle not having Google Play preinstalled in the work profile which is a separate issue.

2025-06-17 00:02:26 CEST

- reply

No, these issues were never present on the stock OS or in the Android Open Source Project. Murena does lag incredibly far behind on shipping updates. You'll be months behind on getting critical privacy/security patches including multiple issues found being exploited in the wild. The instability and basic functionality being broken is not due to missing updates but rather the problems they introduce to their low quality LineageOS fork. The stock OS or AOSP were never unusable.

2025-06-16 17:16:55 CEST

- reply

We do all production builds on 3 local GrapheneOS Foundation machines and each OS developer has at least one powerful local workstation. However, we need a lot more computing power than usual due to the way we're adding back device support to AOSP requiring many clean builds.

2025-06-11 19:42:01 CEST

- reply

Yes, it will be supported as part of our regular Android 16 releases when the port is done. Support for it and the other devices is going to be much harder than expected to implement for Android 16. We can get it done, but it will take more time and effort than usual. We'll be spending more work on device support than the main port to Android 16.

2025-05-27 01:20:51 CEST

Vanadium version 137.0.7151.44.1 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/137.0.7151.44.1
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/22743-vanadium-version-13707151441-released
#GrapheneOS #privacy #security #browser

2025-05-17 16:04:56 CEST

- reply

Chrome / Chromium provides a very misleading "V8 Optimizer" toggle which contrary to popular belief does not disable the Just-In-Time compiler and therefore cannot block dynamic code generation. It's not a default JIT disable like iOS lockdown mode or default GrapheneOS.

2025-05-06 22:43:38 CEST

- reply

GrapheneOS Foundation can sign an NDA for this. We can act as a contractor for an Android OEM or one of their contractors. We need this early access so that we can start early due to the developer who usually does most of it being unavailable. If you can get us this, please help.

2025-05-06 18:23:42 CEST

We need an Android OEM or someone working at one to provide us with early access to the Android 16 sources in order to have a smooth port this year. We need this before June. We requested it to help with this very difficult situation (see the linked thread) and still need it.
https://grapheneos.social/@GrapheneOS/114359660453627718

2025-05-05 04:23:53 CEST

- reply

OCSP stapling with Must-Staple was the best path forward for working certificate revocation checks but had poor adoption. OCSP responses with signed revocation data for a certificate from the Certificate Authority generally had several days of validity. 6 day validity certificates sidestep all this.

2025-05-05 04:23:51 CEST

- reply

The `tlsserver` profile drops support for OCSP early along with various legacy features. The upcoming `shortlived` profile is based on the `tlsserver` profile with validity reduced from 90 days to 6 days, so we can now smoothly migrate to `shortlived` as soon as it's made available for us to use.

2025-05-05 04:23:46 CEST

In anticipation of Let's Encrypt dropping Must-Staple support on May 7th and OCSP 3 months later, our services previously using OCSP stapling and Must-Staple have been moved to the Let's Encrypt `tlsserver` profile made publicly usable a couple weeks ago.
https://community.letsencrypt.org/t/removing-ocsp-urls-from-certificates/236699

2025-05-04 21:10:05 CEST

- reply

If you're curious about the configurations we use on our servers, most of that is available in these 2 repositories:
https://github.com/GrapheneOS/ns1.grapheneos.org
https://github.com/GrapheneOS/infrastructure
Our bird.conf for announcing our anycast IPs via BGP to Rage4 and a routing setup script aren't published yet.

2025-05-04 21:06:06 CEST

- reply

Several large public resolvers including Google Public DNS and several European ISPs have adopted opportunistic ADoT (Authoritative DNS-over-TLS) and use it with our servers. There's no way to ENFORCE using ADoT yet but we're keeping an eye on it. We have valid WebPKI certs + DANE TLSA for it.

2025-05-04 20:55:39 CEST

- reply

One of the side benefits of hosting our own authoritative DNS is that we're among an incredibly tiny subset of services supporting DNS-over-TLS (DoT) for our nameservers. There are widely used DNS resolver servers including Google Public DNS opportunistically using DoT to query authoritative DNS.

2025-05-04 18:41:43 CEST

- reply

We also plan to make a small upgrade for ns2.grapheneos.org by adding the optional Miami location via BGP once BuyVM has stock available. BuyVM will hopefully add a Singapore location and IPv6 support in the future, which are the main weaknesses other than lack of failover beyond Miami going to NY.

2025-05-04 18:39:24 CEST

- reply

We plan to replace the Beauharnois VPS with New York to have it near a Rage4 New York node. Our new Frankfurt VPS is already right near the Rage4 Frankfurt node. We also plan to add Seattle and Singapore soon. Adding more can be done alongside new website and network server instances in the future.

2025-05-03 17:25:12 CEST

- reply

They saved time not porting either to the QPR2 release prior to launch. It wasn't as noticeable for the Pixel 8a since Android 14 QPR3 was launched weeks later and provided mainline Android support for it. It's more noticeable for the Pixel 9a since it launched in April instead of late May.
Android 16 is coming out this year in June instead of that being the QPR3 release as usual. We aren't sure why. It's possible they decided to move the month yearly releases come out going forward.

2025-05-03 17:22:18 CEST

- reply

You can see from https://grapheneos.org/releases#tegu that it's not on the same version of GrapheneOS as the other devices.
It's normal for new devices to launch with a device branch. Pixel 8a and Pixel 9a are the first non-flagship devices launched after trunk-based quarterly releases started with Android 14 QPR2.
Pixel 8a launched with Android 14 QPR1 in May 2024 instead of QPR2 from March 2024. Android 14 QPR3 was released weeks later in June, merging it into mainline Android. This is similar.

2025-05-03 17:18:36 CEST

- reply

Pixel 9a is a newly launched device which is not supported by mainline Android. It still has Android 15 QPR1 with the stock Pixel OS instead of Android 15 QPR2 and it's the same with GrapheneOS. It does not receive the regular releases of GrapheneOS yet and does not have the full Android or GrapheneOS feature set. It will have mainline Android with the launch of Android 16 in June. Until then, it has special releases using a Pixel 9a device branch based on the upstream branch for it.

2025-05-03 16:54:23 CEST

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

2025-05-01 15:17:31 CEST

Secure PDF Viewer app version 30 released:
https://github.com/GrapheneOS/PdfViewer/releases/tag/30
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/22146-secure-pdf-viewer-app-version-30-released
#GrapheneOS #privacy #security #pdf #android

2025-04-29 03:31:34 CEST

Secure PDF Viewer app version 29 released:
https://github.com/GrapheneOS/PdfViewer/releases/tag/29
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/22078-secure-pdf-viewer-app-version-29-released
#GrapheneOS #privacy #security #pdf #android

2025-04-16 20:27:34 CEST

- reply

GrapheneOS enables support for blocking numbers which aren't in your contacts and you can also block all unknown numbers but it could be a bad idea to do that in case you get an important call which happens that way.

2025-04-16 00:48:54 CEST

Vanadium version 135.0.7049.100.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/135.0.7049.100.0
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/21751-vanadium-version-135070491000-released
#GrapheneOS #privacy #security #browser

2025-04-15 22:12:38 CEST

- reply

GrapheneOS for the Pixel 9a support is no longer considered experimental. Since it's still based on Android 15 QPR2 upstream, it's missing some recent improvements in Android and GrapheneOS but we backported most post-QPR2 GrapheneOS changes and it'll be on mainline Android soon.

2025-04-15 21:11:21 CEST

- reply

They're essentially not supported anymore. We haven't unlisted them from our site as insecure end-of-life legacy extended support devices because we know people will start bothering us about it. We do bare minimum updates to fix something breaking with a service, etc. so people don't bother us about it. If people are determined to use insecure devices, it's also better if they use an OS that's being honest with them about that rather than one misleading them.

2025-04-15 21:08:56 CEST

- reply

It's very clearly marked as being insecure including a notification shown on each boot. We also don't set an inaccurate Android security patch level based on only having AOSP patches as LineageOS and most other non-stock operating systems do. There's no false sense of security provided by us. We did decide to permit people to disable the at-boot notification but doing so requires them to explicitly do that via disabling the notification channel.

2025-04-13 06:35:44 CEST

- reply

All of the standard Android and GrapheneOS functionality should already be working on the Pixel 9a including our hardware-based USB-C port control feature, hardware memory tagging, etc.
Main work was dealing with the temporary QPR1-based device branch (https://grapheneos.social/@GrapheneOS/114320149441258698).

2025-03-31 22:40:37 CEST

- reply

Metered bandwidth is a problem. The only way we could use it is if they waived that requirement as a special case for us.

2025-03-31 22:29:26 CEST

We currently have 16Gbps total bandwidth for our update servers and that's not nearly enough for major releases anymore. Rather than further scaling up our current 2Gbps unmetered VPS approach, we're currently looking into other options. OVH lacks cost effective 10Gbps servers.

2025-03-28 14:03:16 CET

- reply

iPhones and Pixels have the most secure hardware. Pixels are very competitive with iPhones.

2025-03-27 17:57:49 CET

- reply

Here's another on X:
https://xcancel.com/gael_duval/status/1887528529694273590
Gaël Duval consistently misleads people about the ease of obtaining GrapheneOS, app compatibility, usability and privacy. These desperate posts on X, Mastodon and elsewhere are a small fraction of it. It's Murena's company policy.

2025-03-27 17:53:40 CET

- reply

Here's another example of the CEO of Murena replying to a post about GrapheneOS trying to mislead people about it and promote their products:
https://xcancel.com/gael_duval/status/1904097790977810458
Here's a high quality third party comparison between Android-based operating systems:
https://eylenburg.github.io/android_comparison.htm

2025-03-27 02:54:30 CET

- reply

You can enable this feature via the toggle we added at Settings > Location > Location services > Network location. You can optionally enable the standard Wi-Fi scanning toggle in the Location services menu to allow Wi-Fi scans when Wi-Fi is otherwise disabled to keep network-based location working.

2025-03-27 02:54:26 CET

Our latest 2025032500 release greatly improved our built-in network-based location. It's usually better than Google's network-based location in urban areas where Apple has competitive data. Unlike Google's service, position estimation is done locally by fetching location data for nearby networks.

2025-03-26 04:16:48 CET

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

2025-03-25 18:48:00 CET

- reply

Our Auditor app generates a hardware backed attest purpose key for each pairing with attestation enabled via the root-based attestation system. It then generates a regular hardware backed signing key with attestation enabled with the attest key it generated as the attestation signing key. It signs the overall messages it sends with that signing key. On subsequent attestations, it makes a temporary unused key with the same attest key for signing it to get fresh attestation data.

2025-03-25 18:46:16 CET

- reply

Yes, but provisioned attestation signing keys are also per-app so they can't be used to identify a device across apps either. They are not per-pairing but rather per-app so an app only triggers provisioning when generating a key with attestation enabled. Apps can also generate their own attest purpose keys usable to sign attestations instead of this. It can also reuse it for a while before it has to rotate it. They have short expiry and generating a new key can trigger rotation.

2025-03-25 17:20:57 CET

- reply

/e/OS is much more insecure than CalyxOS but CalyxOS still lags significantly behind on privacy/security patches and still somewhat rolls back the security model compared to AOSP while creating new privacy issues. They're both in a much different space from GrapheneOS.
We can't support the Fairphone 4 because it doesn't have a secure element, proper driver/firmware patches, has insecure broken verified boot and is missing important security features we use.

2025-03-25 17:09:37 CET

- reply

https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point. Highly recommend looking at that as a starting point to understand how extremely different they are from each other. CalyxOS is in the same space as other non-hardened OSes like LineageOS, /e/OS and iodéOS. It's a common misconception that it's similar to GrapheneOS.

2025-03-25 17:08:38 CET

- reply

https://grapheneos.social/@GrapheneOS/113459782313987260 is a recent thread explaining why we use our sandboxed Google Play compatibility layer approach instead. We still reimplement Google Play functionality ourselves, but we implement it in a way that's not tied to Google Play and then expand the compatibility layer to optionally or always reroute requests to it from apps if that's needed. We have much higher standards including privacy and security for the code we're adding.

2025-03-25 17:06:51 CET

- reply

No, that's not the case. CalyxOS has far less app compatibility than GrapheneOS and not all app functionality will work properly. CalyxOS also isn't a hardened OS and lacks remotely comparable privacy and security. Similar to /e/OS and LineageOS, it reduces privacy and security compared to AOSP, just not as much as /e/OS does. As an example, it's missing the full March 2025 Android and Pixel security patches. Weeks or even months of patch delays isn't safe.

2025-03-24 19:01:59 CET

- reply

A lot of the people saying it's better or saying it's worse are probably just guessing inaccurately. However, at least some part of it is likely based on reality. It is very easy to make battery life terrible by doing something like using 6 apps with very inefficient non-FCM push rather than FCM or UnifiedPush. Some people use a ton of apps and it's hard for them to figure out what's draining battery. Battery stats help but are far from perfect at figuring it out.

2025-03-24 18:59:45 CET

- reply

Pixels moved to a more efficient cellular radio with 7th gen and then an even more efficient one with 9th gen, but the Pixel 9a will apparently have the older 7th/8th gen era radio again as part of how it cuts costs down to a less high end device.
There are so many ways to make battery life worse or better and GrapheneOS users are more likely to make some of both kinds of choices. That's why most of our users say it's better, but some say it's worse.

2025-03-24 18:08:45 CET

- reply

> It's a bit janky but also doesn't keep trying to upsell me cloud services, so big net win.
What are you referring to?

2025-03-23 19:30:13 CET

- reply

GNSS (satellite-based location) uses more power than network-based location. GrapheneOS has network-based location off by default and for compatibility we emulate it via GNSS for apps using the Google Play location API which is rerouted to the OS API by default. This means if you have something like an app requesting low power location frequently, it could drain a lot more power from using GNSS instead of network location. If it requests high power location, it likely wouldn't help.

2025-03-23 19:28:55 CET

- reply

It's very hard for us to give people advice on improving battery life since it's typically a combination of apps and other factors resulting in worse battery life than people expect. GrapheneOS starts off better and is still a bit better with just sandboxed Google Play installed, but it's easy to make it worse because people are often getting non-Play variants of apps using non-FCM push, etc. Also, if you regularly use location, enabling Network location + Wi-Fi scanning will save power.

2025-03-23 19:27:39 CET

- reply

The example of Signal draining battery with non-FCM push is the most common we see. Having a Wi-Fi or cellular network with a poor connection will also drain power. Using "4G" (4G and below) instead of the default "5G" will typically save power. Using our added "4G only" may save power if you always have a strong 4G connection, but note it requires VoLTE for phone calls to work so you should test if that works before just enabling it permanently. There are many other factors involved.

2025-03-23 19:14:00 CET

- reply

The only case it would increase power consumption in practice is if you do something like a 2 hour video encode using poorly optimized software which runs less efficiently due to hardened_malloc, hardware memory tagging, etc. which have per-app toggles available.
Our use of full ahead-of-time compilation for apps with the usual just-in-time compilation disabled decreases runtime battery usage at runtime while needing more power after an update for recompilation (optimizing apps).

2025-03-23 19:12:43 CET

- reply

It's hard to make proper comparisons. GrapheneOS uses less power by default because it doesn't have nearly as much stuff included. If you add sandboxed Google Play and dozens of Google apps to reach roughly what's included in the stock OS, battery life should be quite similar. There can be differences due to our hardening features (both positive and negative) but it's insignificant overall.
People do often set up inefficient setups with a bunch of different push connections, etc.

2025-03-23 16:40:52 CET

- reply

Using only 1 profile on the stock OS with a dozen apps installed will drain more power than using the same dozen apps on GrapheneOS with sandboxed Google Play in 1 profile. If you compare apples to apples, GrapheneOS saves power.
If you compare apples to oranges such as Signal with FCM vs. incredibly inefficient non-FCM Signal push (the Molly fork makes it far less bad) along with multiple profiles, then it can drain more power because you've configured it in a less efficient way.

2025-03-23 16:37:52 CET

- reply

UnifiedPush is an alternative to Firebase Cloud Messaging able to reuse a single push messaging connection in a similar way. The issue is that only a few apps such as Molly and Element currently support it. Since UnifiedPush is not a specific implementation but rather a compatible interface with multiple apps and services, efficiency and robustness will vary.
Running a dozen push connections for separate apps especially very non-optimized ones like Signal's own push will drain power.

2025-03-23 15:53:42 CET

- reply

Battery consumption is much lower in a fresh install of GrapheneOS than the stock OS.
Google Play services Firebase Cloud Messaging is an efficient push messaging system and using multiple less efficient push messaging systems at the same time will consume more power than it. This is a choice about how you set things up. You can use FCM on GrapheneOS.
If you use multiple profiles that will be more heavyweight than using a single profile whether it's the stock OS or GrapheneOS.

2025-03-20 00:38:47 CET

Latest release of Vanadium has support for passkeys without Google Play services via the Android 15 credential manager:
https://grapheneos.social/@GrapheneOS/114186195115859187
Proton Pass is an example of an app providing passkeys without Play services. Bitwarden appears to require Play services for this.

2025-03-14 03:44:53 CET

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

2025-03-14 03:43:44 CET

- reply

The cable can be connected to a USB-C hub with DisplayPort alternate mode support to provide charging and USB-C ports for a wired mouse and keyboard if desired instead of only being able to use Bluetooth ones. It's very practical if you make a proper setup for it.
These are hardware accelerated virtual machines so the overhead for CPU tasks is very low and the overhead for GPU tasks is quite reasonable when GPU acceleration is enabled. It's similar to WebGL in Chromium.

2025-03-12 14:31:12 CET

- reply

GrapheneOS is already mobile Linux. It's far more private, secure and functional than desktop Linux distributions. A variant of GrapheneOS built with the rest of the OS is what will be used for mobile usage to seamlessly isolate apps/profiles better.
The intended usage of virtual machines in future GrapheneOS is for isolating low level app and OS components via the GrapheneOS microdroid variant, running apps and profiles in a VM as a better sandbox and Windows / desktop Linux app compat.

2025-03-11 06:33:10 CET

- reply

Running an up-to-date OpenSSH version in a terminal doesn't require a non-native userspace. It can simply be the latest OpenSSH built for Android and run in a terminal emulator with the native Android command-line environment available to apps.
Termux is a legacy approach built upon many awful hacks. They essentially ported a userspace CLI environment from another OS to Android without using namespaces or virtualization. It doesn't follow how things are meant to be on Android.