GrapheneOS

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

Public Key

npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5

NIP-05 Address

Profile Code

nprofile1qqs9g69ua6m5ec6ukstnmnyewj7a4j0gjjn5hu75f7w23d64gczunmgpz4mhxue69uhhyetvv9ujuerfw36x7tnsw43qz9thwden5te0wfjkccte9ekk7um5wgh8qatzy4vwt2

Publishing to

Author Public Key

npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5

Show more details

Last Notes

2026-08-01 22:03:22 UTC

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

2026-08-01 16:14:50 UTC

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

2026-07-31 03:32:52 UTC

- reply

@nprofile…n6nv @nprofile…2tz4 It's because we've received a lot of donations and were able to hire 4 additional full time developers to focus on our apps. One of them is also managing keeping track of ongoing app and OS development. It's becoming much more productive.
We also hired 3 part time people who were previous volunteers to work on moderation, handling emails, etc.
We have more than 10 full time developers now. We're going through the applications and interviewing people to further expand the team.

2026-07-31 03:32:46 UTC

- reply

@nprofile…n6nv @nprofile…2tz4 It's because we've received a lot of donations and were able to hire 4 additional full time developers to focus on our apps. One of them is also managing keeping track of ongoing app and OS development. It's becoming much more productive. We also hired 3 part time people who were previous volunteers to work on moderation, handling emails, etc.
We have more than 10 full time developers now. We're going through the applications and interviewing people to further expand the team.

2026-07-31 00:04:11 UTC

- reply

@nprofile…2tz4 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

2026-07-30 23:46:08 UTC

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

2026-07-30 08:11:28 UTC

- reply

@nprofile…lg36 Every production release starts in Alpha, then goes to Beta and then Stable. You can see what's in which channel for each device at https://grapheneos.org/releases#devices. There's an explanation at https://grapheneos.org/releases#about-the-releases. Alpha tends to take 4 to 12 hours and then Beta takes another 6 to 48 hours.

2026-07-30 05:51:51 UTC

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

2026-07-30 01:57:50 UTC

- reply

@nprofile…8ama Desktop mode was moved out of developer options and made into an officially supported feature in Android 17. It's going to get major improvements in each major Android release.
We aren't specifically improving desktop mode ourselves beyond making sure it all works and fixing issues uncovered by our security protections. We're just getting all of the latest and greatest features through keeping up with the OS updates.
We do plan to much more heavily use virtualization than Android.

2026-07-30 01:45:08 UTC

- reply

@nprofile…rh6u See https://grapheneos.social/@GrapheneOS/117006294613630950.

2026-07-30 01:44:57 UTC

- reply

@nprofile…td5t See https://grapheneos.social/@GrapheneOS/117006294613630950.

2026-07-30 01:44:44 UTC

- reply

@nprofile…euug See https://grapheneos.social/@GrapheneOS/117006294613630950.

2026-07-30 01:44:35 UTC

- reply

@nprofile…vj9w See https://grapheneos.social/@GrapheneOS/117006294613630950.

2026-07-30 01:31:07 UTC

- reply

@nprofile…8ama GrapheneOS has been based on Android 17 since shortly after it was released last month. It's a high priority for us since many crucial privacy/security patches and features aren't backported to older releases.
GrapheneOS is a privacy and security hardened OS greatly improving those compared to the Android Open Source Project. It keeps up with the standard updates and provides much better patches. It adds major privacy and security features while keeping all of the standard ones intact.

2026-07-30 01:19:28 UTC

- reply

@nprofile…8ama GrapheneOS does have a desktop mode. It fully supports DisplayPort alternate mode and USB-C audio. The desktop mode can be used an external display along with speakers, mouse, keyboard, game controller and other accessories at the same time.
GrapheneOS also has hardware accelerated virtualization support. It can be used to run applications not ported to Android. The VM management app is still called Terminal for now but it supports graphical applications and opt-in GPU acceleration.

2026-07-29 22:16:49 UTC

- reply

@nprofile…2w6z
> everyone's threat model is different
The context of the proposals is border security with access to forensics software.
> could do the trick for victims of domestic violence
Easy to notice it's running GrapheneOS. Features GrapheneOS provides will be widely known and discussed.
> against muggers who demand that you unlock your phone
People can choose to heavily use Private Spaces which are a very good feature themselves. Android already has a dubious feature for poorly hiding it.

2026-07-29 22:15:43 UTC

- reply

@nprofile…2w6z
> everyone's threat model is different
The context of the proposals is border security with access to forensics software.
> could do the trick for victims of domestic violence
Easy to notice it's running GrapheneOS. Features GrapheneOS provides will be widely known and discussed.
> against muggers who demand that you unlock your phone
People can choose to heavily use Private Spaces which are a good feature. The support for poorly hiding these is not a good feature, but it exists.

2026-07-29 22:12:36 UTC

- reply

@nprofile…2w6z
> But everyone's threat model is different.
The context of the proposals is border security with widespread access to forensic software.
> but it could do the trick for victims of domestic violence
Are they not going to notice that the device is running GrapheneOS, an OS widely known to provide this feature if it did?
> against muggers who demand that you unlock your phone
Why isn't heavily using Private Space enough for this already? Android support it being very poorly hidden.

2026-07-29 22:04:51 UTC

- reply

We make privacy and security tech. Privacy and security involve defending against adversaries actively adapting and improving. Companies developing offensive security tech including remote exploits and data extraction tools are aware of GrapheneOS. It's made with that in mind.

2026-07-29 21:57:22 UTC

- reply

https://reddit.com/r/embeddedlinux/comments/1josb0i/embedded_linux_jobs_monthly_thread_april_2025/ml3schx/
> Company: Magnet Forensics
>
> [...] experience in both embedded Linux, and also FPGA gateware. Deep understanding of the USB protocol and stack is a major differentiator - experience here sets you apart [...]
>
> Technologies: [...] GrapheneOS, [...]

2026-07-29 21:54:32 UTC

- reply

https://training.magnetforensics.com/w/courses/15-gk200-graykey-examinations
> An awareness module focused on anti-forensic operating systems and applications, with particular attention to GrapheneOS — its privacy and security features, supported devices, data-wipe behaviors, and the handling and seizure considerations these devices introduce.

2026-07-29 21:54:20 UTC

- reply

training.magnetforensics.com/w/courses/15-gk200-graykey-examinations
> An awareness module focused on anti-forensic operating systems and applications, with particular attention to GrapheneOS — its privacy and security features, supported devices, data-wipe behaviors, and the handling and seizure considerations these devices introduce.

2026-07-29 21:46:42 UTC

- reply

Cellebrite and other forensic data extraction companies included information on GrapheneOS in their documentation years ago. That includes it being covered in Cellebrite's tables documenting available capabilities:
https://www.androidauthority.com/cellebrite-leak-google-pixel-grapheneos-security-3611794/
The more recent tables are similar.

2026-07-29 21:36:16 UTC

- reply

Forensic extraction software without exploits for locked device is common and not closely guarded. Users these tools only need to follow simple on-screen instructions. Developers of the tools are aware of alternative operating systems. GrapheneOS features have to work when known.

2026-07-29 21:27:33 UTC

- reply

Exploiting the OS becomes drastically easier after being granted access to a profile. USB becomes available, every radio can be turned on and an app can be installed with every permission granted. Developer options and ADB would need to be available to pretend to be Owner...

2026-07-29 21:23:59 UTC

- reply

The decoy profile concept many have suggested for years is far more flawed than this. It wouldn't hide the presence of other profiles and would be trivially identified. Basic forensic software on a laptop would identify it without exploits. It would also make exploits far easier.

2026-07-29 21:18:50 UTC

In response to recent suggestions mentioning it:
> If you need plausible deniability, you must not use VeraCrypt to encrypt any part of (or create encrypted containers on) a device (or file system) that utilizes a wear-leveling mechanism.
https://veracrypt.io/en/Wear-Leveling.html

2026-07-27 18:14:45 UTC

- reply

@nprofile…99hn @nprofile…jjg4 The global toggles for camera, microphone and location control whether the permissions grant access to applications. If you only grant one-time access with the permissions, then it gets automatically revoked 1 minute after the app is no longer being used. You don't benefit much from using the global toggles if you never grant persistent access. The main point is disabling it for apps you granted it persistently.

2026-07-27 16:26:38 UTC

- reply

@nprofile…99hn @nprofile…jjg4 If you leave apps on Ask every time for those 3 permissions and use one-time grants then you can't forget to remove it since it's revoked 1 minute after the apps aren't in use anymore. The global toggles aren't very useful if you don't give out persistent access to more than the bundled Camera app.

2026-07-27 13:54:05 UTC

- reply

@nprofile…3xx2 He likely would have been better off relying on GrapheneOS protecting the data though. US legally protects not turning over a PIN/password to law enforcement which isn't the case in a lot of the world. Duress PIN/password takes recovering any of the data off the table which is very useful but there can be consequences to using it. It did work as intended but likely wasn't necessary in this particular case.
We wrote an overview with important background info:
https://discuss.grapheneos.org/d/40700-grapheneos-protections-against-data-extraction-from-locked-devices

2026-07-27 13:52:15 UTC

- reply

@nprofile…k5zu The way the duress PIN/password works is that it passes it through to be used as a regular PIN/password to trigger all the regular stuff that does and then it checks if it was a duress PIN/password afterwards. If it's the same as the actual PIN/password then it doesn't trigger which is not how anyone should set it up but does make sense to handle it.
SIM PIN is handled by the SIM card externally and it's unclear if it's a good idea to integrate it in the same way we did elsewhere.

2026-07-27 02:06:02 UTC

- reply

@nprofile…jjg4 Unblocking access via the global Camera toggle is a separate thing from the permission. Apps need to request access again each time. Google Camera isn't getting access via the GrapheneOS Camera permission. The global toggle is a separate thing and there's no reason multiple apps would need to ask to enable it. Granting one-time access is unrelated to that. It has to ask for one-time access, not enabling the global toggle.

2026-07-26 22:07:53 UTC

- reply

@nprofile…jjg4 That's only possible if you grant persistent access to the other app. If you grant one-time access to it then it has it taken away 1 minute after it stops being used.
What you're requesting is what the standard option to grant the permissions one time provides. Switch the apps back to Ask every time and use the option to grant access once each time it's needed instead of while in use.

2026-07-26 20:57:04 UTC

- reply

@nprofile…jjg4 There's an existing standard Android feature for granting one-time access to Camera, Microphone or Location. It revokes it 1 minute after the app stops being actively used either directly or via a foreground service started while in use that's explicitly using one or more of those permissions in a way that's visible to the user. We recommend using one-time grants for all 3 permissions in the vast majority of cases. The global toggles aren't particularly useful if you follow this.

2026-07-26 17:47:53 UTC

- reply

@nprofile…ecjg @nprofile…c8pt @nprofile…ppje @nprofile…dey5 GrapheneOS is mobile Linux. No amount of your bad faith claims will change this. Moving drivers into userspace is far better for security. The kernel portion of the drivers are also going to be rewritten in Rust.
Drivers putting far more than needed into the kernel still have plenty of userspace code to go along with it. All of that goes into the vendor image. linux-firmware is just a very incomplete firmware collection which goes into vendor.

2026-07-26 17:43:33 UTC

- reply

@nprofile…ecjg @nprofile…c8pt @nprofile…ppje @nprofile…dey5 GrapheneOS is mobile Linux. No amount of your bad faith claims will change this. Moving drivers into userspace is far better for security. The kernel portion of the drivers are also going to be rewritten in Rust. Putting a huge amount of code into the kernel is a poor security practice and there's still plenty of userspace code to go along with it which would be in Android's vendor image. linux-firmware isn't what you claim but would go there too.

2026-07-26 17:39:35 UTC

- reply

@nprofile…ecjg @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Android works with mainline kernels and doesn't require downstream changes to it. It's not only AOSP-based projects using out-of-tree drivers on devices where those are the only complete drivers available. You arbitrarily claim AOSP-based projects aren't Linux while using different standards for non-AOSP-based projects.
AOSP and GrapheneOS are Linux according to the Linux project. No amount of your disingenuous arguments is going to change this.

2026-07-26 15:54:15 UTC

- reply

@nprofile…ecjg @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Ubuntu 26.04 LTS uses Linux 7.0 which as you can see is end-of-life in https://kernel.org/. Ubuntu 26.04 LTS has standard support until May 2031 and their longest form of support goes until May 2041. Ubuntu 26.04 LTS will go 15 years without merging an upstream release into their fork.
Android ships the LTS revisions and moves to each new LTS branch. Pixel 7 moved from 5.10 to 6.1 and now 6.12 for the upcoming 17 QPR2.

2026-07-26 15:48:18 UTC

- reply

@nprofile…ecjg @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Android and Debian both maintain their own LTS based on following along with the kernel.org LTS releases. They both backport changes to previous LTS revisions and then upgrade the base LTS revision.
Canonical doesn't use the kernel.org LTS most of the time but rather entirely makes their own. They start from stable rather than longterm and simply make their own. Stable is short-lived and gets replaced after the next mainline release is out.

2026-07-26 15:35:23 UTC

- reply

@nprofile…ecjg @nprofile…c8pt @nprofile…ppje @nprofile…dey5 No, that's completely inaccurate. The official upstream kernel releases are split into mainline, stable and longterm. Mainline is the branch maintained by Linus Torvalds including the release candidate and initial major releases tagged on it.
ChromeOS never used mainline. ChromeOS used their own LTS branches and it was merged with Android. Both are directly based on the upstream LTS branches. Debian doesn't directly use the upstream LTS either.

2026-07-26 15:31:53 UTC

- reply

@nprofile…ecjg @nprofile…c8pt @nprofile…ppje @nprofile…dey5 GrapheneOS is a Linux distribution. On a mobile device, it is mobile Linux. It has a desktop mode and isn't only going to be mobile Linux. It will be on laptops and desktops too. It can already be used that way.
Projects are bringing glibc, systemd, GNOME and other projects to mobile rather than Linux. Linux dominates the mobile space. The person who controls the Linux project and trademark has made it clear Android and GrapheneOS are Linux.

2026-07-26 15:25:46 UTC

- reply

@nprofile…ecjg @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Android's vendor partition doesn't contain any out-of-tree kernel code. It's firmware and userspace components. Kernel code is in separate partitions. There's nothing in the vendor partition to replace with upstream Linux kernel drivers.
Linux uses mainline to refer to the main branch and tags made by Linus. For a production device, the longterm branches are what's used in practice. Stable branches are short-lived and not particularly robust.

2026-07-26 13:44:41 UTC

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

- reply

@nprofile…ecjg @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Android has worked with mainline kernels for years. Mainline Linux kernel drivers with proper functionality are drivers Android can use too. Any efforts to improve the upstream Linux kernel directly benefit Android since it's a Linux distribution itself. Android devices now regularly move to new LTS branches throughout their lifetime. Pixel 7 moved from the 5.10 LTS to 6.1 and now to 6.12. Android benefits from upstream improvements to Linux.

2026-07-26 12:26:47 UTC

- reply

@nprofile…ecjg @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Android has worked with mainline kernels for years. Mainline Linux kernel drivers with proper functionality are drivers Android can use too. Any efforts to improve the upstream Linux kernel directly benefit Android since it's a Linux distribution regularly. Android devices now regularly move to new LTS branches throughout their lifetime. Pixel 7 moved from the 5.10 LTS to 6.1 and now to 6.12. Android benefits from upstream improvements to Linux.

2026-07-26 12:24:13 UTC

- reply

@nprofile…ecjg @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Android has a standard desktop mode and modern apps run fine as dynamically sized free form windows on a set of large displays with varying DPI, HDR, etc. ChromeOS is in the process of being replaced with Android. It will be Android which runs on Chromebooks instead of the current ChromeOS. You can confirm that with a bit of research. Android already has the functionality to handle running on a laptop or desktop but it will be refined more first.

2026-07-26 12:22:10 UTC

- reply

@nprofile…ecjg @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Linux being a monolithic kernel written in C is in the process of changing due to the disastrous security situation it has. It's a very slow process but the people at the top including Linus and Greg KH are on board with it.
GrapheneOS is a Linux distribution. Linus Torvalds repeatedly described Android as a Linux distribution many years before all of the kernel features it requires were upstream and it began to fully work with mainline kernel.

2026-07-26 05:10:27 UTC

- reply

@nprofile…v6g6 @nprofile…3kzl Android heavily uses Rust as one of the main programming languages. Apps are encouraged to write the performance critical parts of their code in Rust. Here's an example made by GrapheneOS:
https://github.com/GrapheneOS/platform_packages_apps_NetworkLocation
It's far easier to write user interfaces with garbage collection and it would be extremely impractical to use Rust for all of the application layer code in the OS. It makes a lot of sense to use a higher level language with GC for higher level code.

2026-07-26 04:53:43 UTC

- reply

@nprofile…v6g6 @nprofile…3kzl Java and Kotlin are used as systems programming languages on Android. That doesn't exclude garbage collected languages. It's how they're used.
Android supports ahead-of-time (AOT) compilation for Java and Kotlin in addition to JIT. It uses AOT for core OS code written in it as part of OS builds. GrapheneOS extends the use of AOT compilation.
ART uses generational concurrent GC making dynamic allocation fast, defragmenting the heap and avoiding stop the world pauses.

2026-07-26 04:52:42 UTC

- reply

@nprofile…v6g6 @nprofile…3kzl Java and Kotlin are used as systems programming languages on Android. That doesn't exclude garbage collected languages. It's how they're used.
Android supports ahead-of-time (AOT) compilation for the Java and Kotlin. It uses that for the core OS code written in it as part of OS builds. GrapheneOS extends the use of AOT compilation.
ART has modern generational concurrent GC making dynamic allocation fast, providing heap compaction and avoiding stop the world pauses.

2026-07-26 04:39:04 UTC

- reply

@nprofile…ecjg @nprofile…c8pt @nprofile…ppje @nprofile…dey5 The Linux kernel has no internal isolation or sandboxing for regular kernel code. Each obscure protocol and driver runs with full privileges with access to everything. A typo in an obscure network protocol few people have heard about can be used to take over the whole machine. It doesn't matter that it's not normally used since by default it can simply be auto-loaded and disabling auto-loading is an obscure configuration that's hard to maintain.

2026-07-26 04:37:12 UTC

- reply

@nprofile…ecjg @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Using a minimal kernel configuration with only the required core kernel features, protocols, drivers and other functionality doesn't somehow make it not Linux anymore. It can all be easily enabled in the build configuration.
Traditional desktop distributions enable nearly every available core kernel feature, protocol, driver and other functionality. They support auto-loading the modules from unprivileged users. The attack surface is massive.

2026-07-26 04:27:48 UTC

- reply

@nprofile…ecjg @nprofile…c8pt @nprofile…ppje @nprofile…dey5 That's completely untrue. Android works with a mainline kernel since many years ago. Every kernel feature it requires was landed upstream or replaced with upstream features. A bunch of code was ported to eBPF to avoid needing downstream changes.
Android uses a very minimal kernel configuration, extensive attack surface reduction and many kernel hardening features because it provides reasonable security, unlike those desktop operating systems.

2026-07-26 04:24:26 UTC

- reply

@nprofile…v6g6 @nprofile…3kzl Android replaced C and C++ with Rust for new low-level components and rewrites. Major portions of the OS have been ported to Rust and new low-level components are largely written in Rust unless it's a new external library without a Rust implementation.
Due to the original choice of Java for the application layer and high level systems programming combined with Kotlin and Rust, the majority of new code has been memory safe since Android 13:
https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

2026-07-26 04:21:48 UTC

- reply

@nprofile…v6g6 @nprofile…3kzl Android replaced Java with Kotlin as the officially recommended language for writing applications. It replaced the previous user interface framework with Compose. Java and Views are still fully supported but aren't the focus anymore.
Android using memory safe languages as the language for applications and high level systems programming is a massive security advantage. A large portion of the OS is written in Java and Kotlin. Apps are also largely written in those.

2026-07-26 04:17:48 UTC

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

- reply

@nprofile…3kzl Apps can be installed on GrapheneOS via CLI using the package manager.
It has a desktop mode and can handle a mouse, keyboard, game controller and other accessories alongside USB-C digital audio and DisplayPort output. It is a desktop OS itself in a sense. It will likely eventually run on a small number of laptops meeting the hardware security requirements.
It has hardware-based virtualization including opt-in GPU acceleration via gfxstream. It can run a desktop OS as a VM guest.

2026-07-25 19:35:35 UTC

- reply

@nprofile…3wl0 To clarify something, we do not have an active conflict with PostmarketOS itself. A couple people involved in the project made posts linking to harassment content and with personal insults which were later taken down and it was eventually settled this year. We considered it essentially closed but people keep attacking us who support it and there's a GNOME project member who keeps bringing it up referencing it as if it's an active conflict claiming we're doing stuff we never have.

2026-07-25 19:31:59 UTC

- reply

@nprofile…3wl0 The 2nd link above was meant to be https://eattherich.club/@kiefac/116976545439189720.
This is a core GNOME project member:
https://mastodon.com.pl/@tragivictoria/116834713496471432
She has been posting attacks on us for at least a couple weeks including on Reddit repeatedly claiming we're insane and delusional along with false claims about us. That includes extraordinarily false claims that we're the ones engaging in harassment with no basis, spinning us saying we're being targeted into being doing it:
https://mastodon.com.pl/@tragivictoria/116837805200349592

2026-07-25 19:28:21 UTC

- reply

@nprofile…3wl0 Those aren't nearly as bad as many of the things said about us in the past several weeks including from a couple GNOME project members. The norm is claiming we're insane, delusional and schizophrenic with those words. There's ongoing harassment from Kiwi Farms and a prominent influencer who uses it. Many people who are part of open source projects and communities engage in it. From our perspective what makes those 2 posts above awful is that they are nearly certainly aware of all this.

2026-07-25 19:21:51 UTC

- reply

@nprofile…3wl0 Our community members aren't posting personal attacks and false claims about projects/people opposed to us in this thread. We aren't doing it either. It's only your projects and communities doing it towards us, as is nearly always the case. We're falsely accused of things we've never done and which our community never does but which are ongoing on a daily basis from your projects and communities towards us. If we hadn't blocked several people doing it they'd have done more of it here.

2026-07-25 19:20:27 UTC

- reply

@nprofile…3wl0
> Also, on the attacks thing. Every time I ever respond to anything to do with GrapheneOS, even if it isn't a debate, I get hit with that. Why? What have I done to deserve that?
This thread has a bunch of it. Here are 2 examples:
https://eattherich.club/@kiefac/116976391060397637
https://eattherich.club/@kiefac/116976
Multiple of the accounts doing it including that one moved on to making top-level posts attacking us with false claims about what we said and did.
It is ongoing and relevant to any discussion here.

2026-07-25 19:17:12 UTC

- reply

@nprofile…3wl0 GrapheneOS was started as a mobile Linux hardening project. We've contributed to upstream Linux kernel privacy and security.
We stopped making substantial upstream contributions due to attacks on the project from people using our upstream code. Each of these threads where people claim we aren't working on what we are, making disingenuous arguments and false claims about our project/team including personal attacks further discourage going back to doing more of it again.

2026-07-25 19:14:16 UTC

- reply

@nprofile…3wl0 Android is an operating systems rather than a Linux distribution. AOSP is the reference implementation of Android and the upstream open source project for the overall operating systems family.
GrapheneOS is a Linux distribution. It can be called an AOSP-based OS or an Android-based OS too. It's Android-based rather than Android itself because we do not follow the official Android definition. OEM forks of AOSP including Google Play supposedly follow the official Android definition.

2026-07-25 19:03:50 UTC

- reply

@nprofile…3wl0 GrapheneOS is objectively a Linux distribution. It is your projects and communities attacking us with false claims and personal attacks for making an accurate statement. It isn't us claiming your projects aren't Linux and don't have a right to use the term.
The project and community you list yourself as being involved in has a long history of attacks on the GrapheneOS project including personal attacks visible throughout the other threads branching from the post mentioning us above.

2026-07-25 18:54:08 UTC

- reply

@nprofile…3wl0 Claiming Android isn't Linux is a revisionist claim for marketing purposes. The amount of people buying into it in these echo chambers does not reflect a broad consensus as you're implying.
Linus Torvalds, the Linux project and the Linux Foundation have been saying Android is Linux from early on. There's a broad consensus among people without vested interest in promoting certain products and projects that it's Linux. It was quite uncontroversial that it was Linux until more recently.

2026-07-25 18:52:55 UTC

- reply

@nprofile…3wl0 It is you who holds the fringe position despite trying to portray it the other way around. You shouldn't mistake the echo chamber you're posting in for a broad consensus beyond it.
Linus Torvalds, the Linux project and the Linux Foundation have been saying Android is Linux from early on. There's a broad consensus among people without vested interest in promoting certain products and projects that it's Linux. It was quite uncontroversial that it was Linux until more recently.

2026-07-25 18:50:17 UTC

- reply

@nprofile…3wl0 Android was mobile Linux before these products and projects began claiming exclusive rights the term. What's convenient to them for marketing their products is not the same thing as what is reality or consensus. They're very niche products and the extensive promotion of those including by attacking the GrapheneOS project on the fediverse is not representative of a broader consensus. The hostility towards GrapheneOS and level of false claims about it on this platform is highly unusual.

2026-07-25 18:47:20 UTC

- reply

@nprofile…3wl0 In practice, every Linux distribution uses a fork of the Linux kernel in production. Android works with a mainline kernel similarly to Debian working with a mainline kernel. Neither uses a mainline kernel without patches in in production in practice, but neither requires those changes.
These companies, projects and their supporters do not speak for the Linux kernel project or the broader public. The consensus you and others claim exist does not exist. It is a marketing approach.

2026-07-25 18:45:57 UTC

- reply

@nprofile…3wl0 @nprofile…c8pt @nprofile…dey5 Android was mobile Linux and broadly accepted as such long before those products existed.
Arbitrarily claiming Android isn't Linux is very convenient to them for marketing reasons because Linux phone sounds better than the alternatives. However, they do not own or define the term Linux.
Linus Torvalds has repeatedly clearly said Android is Linux long before it could work with mainline kernels as it can today. It's not up to Pine64 and their fans if it is.

2026-07-25 18:41:54 UTC

- reply

@nprofile…3wl0 @nprofile…c8pt @nprofile…dey5 Android does not require a fork of the Linux kernel. It has worked with regular mainline, stable and longterm kernels for many years. All of the Android kernel features required to run it have been included upstream. Android replaced the features which weren't included upstream with standard ones including reimplementation features with eBPF. It does not require a single Linux kernel change to function. What you're saying is a misconception since years ago.

2026-07-25 18:41:02 UTC

- reply

2026-07-25 18:37:20 UTC

- reply

@nprofile…nltl @nprofile…c8pt @nprofile…dey5 @nprofile…ppje @nprofile…gun3 Android is Linux according to Linus Torvalds, Greg KH, the Linux Foundation and broad consensus.
Android doesn't stop being Linux because companies and projects want to market phones with glibc, systemd and GNOME as being Linux as opposed to the mainstream mobile Linux.
There are products listed above which do not have a typical desktop Linux environment including SailfishOS with their own closed source UI and application layer.

2026-07-25 18:35:30 UTC

- reply

@nprofile…glgc @nprofile…c8pt @nprofile…ppje @nprofile…dey5 We're using the Linux name in the same way it has been used for years including by Linus Torvalds and the Linux Foundation. Linux does not mean what is currently convenient to you based on which Linux userspace approach you want to be successful. Android is not arbitrarily excluded from being Linux because you prefer a different userspace approach. You don't own the term Linux and it's not up to you what it means. Linus Torvalds says Android is Linux.

2026-07-25 18:30:19 UTC

- reply

@nprofile…glgc @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Android is objectively Linux. Linus Torvalds, Greg KH and other core members of the Linux project regularly confirm Android is Linux.
Android is Linux and has been called Linux since long before the products you're claiming have exclusive rights to the term Linux Phone existed.
Linux doesn't mean systemd, GNU and XDG desktop standards. It doesn't mean using GNOME or KDE. Server and embedded Linux is Linux, as is another kind of desktop userspace.

2026-07-25 18:18:33 UTC

- reply

@nprofile…3kzl You listed one privacy and security hardened OS with major privacy improvements on top of preserving the standard privacy and security.
LineageOS and iodéOS do not keep up with the standard privacy and security patches or protections. Those are greatly reducing privacy compared to AOSP which is the opposite direction from GrapheneOS.
https://eylenburg.github.io/android_comparison.htm is an informative third party comparison and the author accepts corrections if you think anything there is inaccurate.

2026-07-25 18:14:22 UTC

- reply

@nprofile…3kzl The claim that it's more focused on security rather than privacy is complete nonsense. It provides major privacy improvements completely unavailable in any of those other operating systems. None of those keeps up with standard privacy patches or improvements, let alone providing major improvements such as Contact Scopes. Privacy depends on security which is the sole reason we work on security too.
You aren't informed about GrapheneOS and don't know what it provides or prioritizes.

2026-07-25 18:12:58 UTC

- reply

@nprofile…3kzl The claim that it's more focused on security rather than privacy is complete nonsense. It provides major privacy improvements completely unavailable in any of those other operating systems. None of those keeps up with standard privacy patches or improvements, let alone providing major improvements such as Contact Scopes. Privacy depends on security which is the sole reason we work on security too.
You don't know what GrapheneOS provides regardless of whether you've tried it a bit.

2026-07-25 04:22:07 UTC

Vanadium version 151.0.7922.47.1 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/151.0.7922.47.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/40679-vanadium-version-15107922471-released
#GrapheneOS #privacy #security #browser

2026-07-25 04:10:09 UTC

- reply

@nprofile…fupw @nprofile…re8h Pixels are initially going to remain the budget option for countries where those are available. Pixel 'a' series devices get the regular 7 years of support from launch and end up being an extremely good deal as used devices after a couple years. It's not easy to compete with that, but Pixels aren't sold everywhere and they're very expensive in a lot of countries where they're not sold. The initial Motorola flagships will be expensive too but there will be more.

2026-07-25 04:08:18 UTC

- reply

@nprofile…fupw @nprofile…re8h 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 01:34:16 UTC

- reply

@nprofile…re8h 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 00:27:16 UTC

- reply

@nprofile…re8h 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 00:25:37 UTC

- reply

@nprofile…re8h 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-24 23:46:51 UTC

- reply

@nprofile…z3n8
> If Google moves Android behind contracts, everybody will happily sign.
Many Android OEMs are already very unhappy with Google's oppressive behavior towards them. South Korea determined it was illegal and Samsung is now largely freed from the same constraints placed on other OEMs. Most Android OEMs clearly want to have the same freedom. Android OEMs do care about AOSP being open source and didn't sign up for how Google seized control and walked back promises to OEMs.

2026-07-24 23:45:42 UTC

- reply

@nprofile…z3n8
> If Google moves Android behind contracts, everybody will happily sign.
Many Android OEMs are already very unhappy with Google's oppressive behavior towards them and several have filed lawsuits against them. South Korea determined it was illegal and Samsung is now largely freed from the same constraints placed on other OEMs. They want to have the same freedom. Android OEMs care about AOSP and didn't sign up for what Google gradually ended up doing with GMS, etc.

2026-07-24 23:26:29 UTC

- reply

@nprofile…75s8 @nprofile…gun3 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 The expectations for an ultra niche hobbyist project are completely different. Partially supporting hardware years after launch without ever getting it mostly working is not the same thing.
Android is mobile Linux, as is GrapheneOS. Linux has heavily benefited from upstream improvements from Android and even a decent amount of GrapheneOS. You gatekeep what it means to be Linux but have you contributed anything to it yourself?

2026-07-24 23:19:47 UTC

- reply

@nprofile…75s8 @nprofile…gun3 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 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-24 23:11:55 UTC

- reply

@nprofile…75s8 @nprofile…gun3 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Android also works fine with a mainline kernel.

2026-07-24 23:09:23 UTC

- reply

@nprofile…75s8 @nprofile…gun3 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 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-24 23:08:38 UTC

- reply

@nprofile…75s8 @nprofile…gun3 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 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 make the same kinds of improvements, but also lacks backwards compatibility.

2026-07-24 23:03:38 UTC

- reply

@nprofile…75s8 @nprofile…gun3 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 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.

2026-07-24 23:01:27 UTC

- reply

@nprofile…75s8 @nprofile…gun3 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Linux breaks the userspace ABI all the time and the actual rule is it not being noticed in a way the upstream project cares about. That has nothing to do with Android's userspace HAL where the userspace part of the drivers are implemented.
Android provides a stable API/ABI for userspace applications and for the hardware abstraction layer (Treble) so your claim is completely backwards as desktop Linux doesn't do either of those.

2026-07-24 22:58:34 UTC

- reply

@nprofile…75s8 @nprofile…gun3 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 It's completely arbitrary. You want to claim Android isn't Linux and are working backwards from it making standards which you don't apply consistently elsewhere. Ubuntu does not have a small amount of patches but rather entirely maintains their own LTS kernels with whatever they want to backport including arbitrary features. Android is closer to using a standard LTS in production than Ubuntu, so is Ubuntu not Linux?

2026-07-24 22:57:21 UTC

- reply

@nprofile…75s8 @nprofile…gun3 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 No common definition of Linux distribution implies not having a downstream LTS as Ubuntu does, not having out-of-tree patches as essentially every distribution does or not having out-of-tree drivers which most make available. A distribution using ZFS and hardware that's out-of-tree is not commonly claimed to not be Linux. You're working backwards from what you want to say and aren't applying what you come up with consistently.

2026-07-24 22:55:37 UTC

- reply

@nprofile…75s8 @nprofile…gun3 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 You aren't being pedantic. You're repeatedly making inaccurate claims and applying standards you come up with for what qualifies as Linux incredibly inconsistently. It's clear you are working backwards from claiming Android isn't Linux, and you're wrong. You'll just shift your definitions and standards around as needed. You started with the misconception that Android can't simply boot with a mainline or LTS kernel, but it can.

2026-07-24 22:53:32 UTC

- reply

@nprofile…75s8 @nprofile…gun3 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Android is a Linux distribution and works with mainline kernels. Every major distribution has out-of-tree kernel patches and has out-of-tree drivers available. Ubuntu entirely makes their own LTS kernels rather than using the upstream LTS branches as Android does, so is Ubuntu not Linux? You're arbitrarily defining Android as not Linux and are working backwards from there justifying it with inconsistent standards you create.

2026-07-24 22:51:35 UTC

- reply

@nprofile…75s8 @nprofile…gun3 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 If only the kernel.org releases with no out-of-tree drivers are Linux then it's not an OS with any significant usage in practice. Every mainstream distribution has various downstream patches to the kernel and many have out-of-tree drivers available. Most common laptop, desktop and server hardware can at least be partially used with in-tree drivers but that doesn't mean everything is often fully functional or working properly.

2026-07-24 22:48:54 UTC

- reply

@nprofile…75s8 @nprofile…gun3 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 You're arbitrarily and incorrectly defining AOSP as not being a Linux distribution. You're then trying to come up with arguments starting from that point. Claiming out-of-tree drivers not specific to Android make it not Linux isn't at all consistent. Ubuntu Touch and other non-AOSP operating systems use out-of-date versions of the same code to run on the hardware. You're supporting that being called Linux. Not a valid argument.