Final

Operations staff @ GrapheneOS Foundation.

Posts my own and not endorsed by my employer. AI slop and Nostr DMs ignored.

Email: final@grapheneos.org
Matrix: f1nal:grapheneos.org

Public Key

npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y

NIP-05 Address

final@zeuspay.com

Profile Code

nprofile1qqstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsr8ed5e

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y

Show more details

Last Notes

2026-08-29 18:56:31 UTC

We are advising people to NOT buy the 11th Generation Pixels due to removal of hardware memory tagging (MTE), a crucial security feature used in GrapheneOS since their introduction on the Pixel 8. Either use a previous generation or wait for the first Motorola devices with GrapheneOS. We have not determined what to do about this.
#nevent1q…c5hy

2026-08-22 16:29:16 UTC

- reply

The latter.

2026-08-20 22:47:03 UTC

- reply

Would check out. Appears to be invite-only.

2026-08-16 15:28:06 UTC

- reply

People have been saying these things about unsafe languages like C for decades. We've been vocal about the issues for about as long too. Check out these posts about C and the poor security culture behind Linux
https://xcancel.com/GrapheneOS/status/1704621518309798067
https://xcancel.om/GrapheneOS/status/1416943878733770754

2026-08-16 12:50:59 UTC

Vanacy from Proton:
> You have hands-on experience building or maintaining a Chromium-based browser
🤔💭
https://job-boards.eu.greenhouse.io/proton/jobs/4941344101

2026-08-16 12:26:17 UTC

- reply

We can get away with this in GrapheneOS to some extent. Linux kernel is mostly C while Android userspace is overwhelmingly Java and Kotlin (interoperable). The best apps for the platform are made with Kotlin, they almost never break with GrapheneOS' protections. For replacing the preinstalled apps they're being converted to Kotlin too.

2026-08-16 12:09:43 UTC

- reply

in another language where the protection is not present*

2026-08-16 12:09:03 UTC

- reply

The majority of Linux Rust work is in individual drivers, there is almost no work for it in the Kernel itself.
Mixed languages on their own are a problem too. You can exploit a bug that would usually be covered by an exploit protection in one language (i.e. CFI for C), by taking advantage of another binary in another language (like Rust).
https://www.cs.ucy.ac.cy/~eliasathan/papers/tops20.pdf

2026-08-16 11:37:04 UTC

848 Linux kernel CVEs published yesterday BTW
https://app.opencve.io/cve/?q=vendor%3Alinux+AND+product%3Alinux_kernel+AND+created%3D2026-08-15
#nevent1q…huw8

2026-08-15 12:19:25 UTC

- reply

Very slightly. Mirrors the standard VS a bit now where each section is like within a floating box. Tabs are also more subtle.

2026-08-15 12:03:41 UTC

New VS Code UI is nice

2026-08-12 23:23:59 UTC

- reply

The Xous distro that the Passport Prime uses has the right idea from a design standpoint. Microkernel, memory safe languages used throughout, mandatory sandboxing for apps. Xous is mostly designed for embedded systems. Obviously implementation is a different thing to rate compared to just the design. I also haven't looked into the hardware as much. I would take it as one of the better offerings the HWW market has right now.
Secureblue has a server distro, hardened CoreOS. I would assume a lot of these bitcoin one-click server dashboard distros aren't as hardened to such an extent. Perhaps it's a room for improvement for these projects.
A lot of defence corps sell their own OSes with the above as marketing, 'STOP OS' by BAE Systems comes to mind. Good luck being able to copy of it yourself though.

2026-08-12 02:15:25 UTC

- reply

I'll get heat for this but I don't believe in the David vs. Goliath narrative people have for Linux as some sort of bastion against 'big tech'. It's one of the most used OS/kernels in the world, mostly by big tech and their employees motivate most of its development. It's only because it's open source.
I think if people cared enough about competition they'd invest it into improving things like Qubes OS, Secureblue (a novel hardened Linux distribution) or a jump to newer OSes like making Redox OS more available to people.

2026-08-12 02:10:49 UTC

- reply

The hardware macOS runs on is far more secure than other laptop/desktop platforms and macOS is the only OS available for it which uses most of the hardware-based security features. The issue is you're completely hard locked on Apple then. Choosing a desktop OS today is a losing battle.
Desktop OSes in general fall behind on adding security design / features that have been researched for decades. Linux distributions are incredibly behind on this and no one should be expected to configure things like SELinux to make it comfortable. Linux is a gigantic monolithic kernel written almost entirely in a memory unsafe language. It's good to have many vulns but having hundreds discovered over days will become unsustainable.
A lot of the mobile OSes started development decades after the desktop, there was far more research on secure OS design by that point and so a better foundation to run on.

2026-08-11 19:51:34 UTC

347 Linux kernel CVEs published yesterday BTW

2026-08-09 21:27:38 UTC

- reply

Seen this actually, this is good! But it's about half of what I want. I'd have to cut out a lot of the test / recommendation fluff. Id want a search result to go straight to a visual map than a big grading system and recommendations list. Big sidebar on the right for the wallet/tx info.
I want to easily make many different types of visualisations and maps for transactions and wallets, have them exportable for documents and other media. I've been ripping off of Chainalysis' own coverage and mempool for inspo.
https://www.chainalysis.com/blog/violent-crypto-wrench-attacks-2026/

2026-08-09 21:08:38 UTC

Amazing we don't have a major open competitor to Chainalysis reactor. We have explorers, but nothing to such a level. When it comes to visualisation it seems top notch, and you need excellent visuals when doing incident reviews. Id love to have an explorer that also was bundled with aliases, (public) identifiers for addresses and so on.

2026-08-09 20:26:18 UTC

What content from me would you want to see?
Some of us are GrapheneOS are working on longer form content, akin to a blog. You'll find more deeper dives about Android, Mobile security and GrapheneOS there... but what would you want to see from me separate to it?

2026-08-09 20:04:44 UTC

- reply

When building something I also do give it the same one quick check. If you build a threat model (architecture diagram and a list of threats and countermeasures you implemented against them) it can provide some excellent detail. Even if someone isn't security conscious, the more it knows about your software the better.

2026-08-09 20:00:25 UTC

I think Bitcoin Design doesn't get enough attention, so I want to give it some, as I am using it for reference myself.
https://bitcoin.design/

2026-08-09 19:55:04 UTC

- reply

I am not into podcasts but this one was really good. The Mempool Research coverage on this was excellent.

2026-08-07 19:33:43 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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
computer.org/csdl/proceedings-article/euros-p/2026/107400b376/2ixHNEzWcYE
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.
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.
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.
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-06 20:19:32 UTC

For those curious and for added context, we were able to get multiple accounts granted cyber verified access from Anthropic. In the future, it would be good to obtain sponsorships from companies to provide current or future security researchers with more tokens.
#nevent1q…pn7e

2026-08-06 20:05:17 UTC

- reply

With COLDCARD there's a ton of hype around how someone found the major vuln by scanning the codebase with an AI agent after the incident, but AI agents have been publicly available for years and people did post they saw it before, just no one exploited it. Maybe they did not know how to.
Also according to their statements Coinkite used frontier models and supposedly could not find it... all about the user.

2026-08-06 20:01:57 UTC

- reply

This won't entirely replace human reviews yet. The high point of an AI agent's capabilities is only slightly over the capability of it's user. Actual research orgs have vulnerability disclosures exponentially increase with AI while an average dev will mostly just close out simple security deficiencies. Creating a PoC for exploiting a vuln is also resourceful.
Serious vulnerabilities held under embargo on Android have increased massively. You can see our changelog on the security preview patches per release and see how the list gets bigger even when some vulnerabilities get removed from the list as they become part of AOSP.

2026-08-04 03:38:30 UTC

- reply

Android / GrapheneOS have a cryptographically secure pseudorandom number generator which apps can use: https://developer.android.com/reference/java/security/SecureRandom
You would use this to help create entropy.

2026-08-04 03:27:14 UTC

Met someone who had their coldcard cracked in the first wave, they were late to realise it. A seriously awful situation.
My funds are safe as I do not use one, but feels different actually seeing it in the action.

2026-08-01 22:10:36 UTC

Contrary to popculture and internet trend narratives, the majority of cyber attacks are not sophisticated. Behind some of the worst cyber attacks are what an industry worker would refer to as a common security deficiency.
These are flaws that are very common and are regularly discussed. These things could be:
- Delayed or no security patching
- Missing second factor authentication
- A misconfiguration or using a insecure configuration, whether it be crypto, application settings, etc.
- Insufficient or lack of access control
- Lack of due diligence or awareness from the victim
- Insufficient logging or monitoring
- Lack of transit or at-rest encryption
Equifax, one of the worst data breaches in modern times, was thanks to them not performing security patching on Apache Struts which allowed a threat actor to exploit a known vulnerability. GTA 6 was leaked from a staff member being socially engineered. Snowden perhaps could not have done his whistleblowing if the NSA has stricter access control.
The best threat actors use the easiest way in to get what they want. The big letter agencies do not jump through hoops and set up big conspiracies rather they exploit software the same way a professional researcher would try to. This also makes an operation far less attributable, because a common security deficiency could be exploited by anybody.
When you regularly see coverage about North Korea ('Lazarus') compromising cryptocurrency companies or users, they are often exploiting these same easily explained weaknesses. If something is too secure, many will easily decide to find a victim that is easier to compromise. What makes them so dangerous isn't their technical capabilities rather than they have far more time and resources because they are state sponsored. They will *never* be held accountable.
When you cover all of these deficiencies and more, your tech is probably more secure than 99.9% of people. Now you go from being a victim of a common attack, to something that would need to be bespoke and targeted.
When working on security or privacy focused software, think long and hard about the quality of the implementation of your functions. You could have many features, but they may not be helpful if their implementation is poor. A poor implementation of a feature may introduce weaknesses compared to not having the feature introduced at all. Less can truly be more.

2026-08-01 21:37:09 UTC

- reply

Really sad to see this is caused by a common security deficiency, either a missing or incorrect configuration. Sensitive crypto operations should not be allowing a fail open.

2026-08-01 21:32:14 UTC

- reply

People 'verify' source code far less than people actually believe. The audience of people who actually can are less than people think too. The entropy code was likely read by many people, many times. It means most did not actually understand what was written. Larger projects pay for AppSec teams to do assurance testing / 'audits' because just having visible source code isn't equal to an audit.
Suspected and known malware get a more documented, deep analysis by security firms compared to most open source projects.

2026-07-30 23:08:47 UTC

- reply

An HDD, they don't have wear levelling. Some SSDs may disable wear levelling at the significant cost of drive lifespan.

2026-07-29 21:28:39 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
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-26 11:25:49 UTC

#GrapheneOS has strong defenses against data extraction. It heavily builds upon the standard security features provided by Android 17 and the most secure hardware available for Android. Currently, only Pixels provide the hardware security features and updates required by GrapheneOS. That's going to change in 2027 thanks to our partnership with Motorola Mobility and progress being made by Qualcomm.
Disk encryption provides strong protection for data. Even the most sophisticated attackers aren't going to be directly breaking it. They either need to exploit the OS while in After First Unlock state or brute force the PIN/password.
Android 16 QPR2 calls for a secure element implementing rate limiting ramping up delays. It's 4 hours after 10 and 41 days after 15. Only 20 attempts are allowed. For usability, It rejects the most recent 5 unique failed attempts early to avoid wasting attempts on repeated errors. GrapheneOS only supports devices implementing the latest generation secure element rate limiting.
https://source.android.com/docs/security/features/authentication/rate-limiting
The secure element on the supported devices also has insider attack resistance. That's implemented by requiring the Owner user to successfully authenticate before the secure element firmware can be updated. A valid signing key and greater version number aren't enough alone. The purpose of this is preventing any government from bypassing the rate limiting by coercing the creation of a firmware update removing the rate limit.
Pixels have used a secure element with an internal timer implementing rate limiting and insider attack resistance since the Pixel 2 launched near the end of 2017. Here's a post about this from back in 2018:
https://android-developers.googleblog.com/2018/05/insider-attack-resistance.html
The secure element and integration into the OS has become far better since then, but it shows this goes back a long way and isn't a new feature.
GrapheneOS also raises the character limit for passwords from 16 to 128. This enables using high entropy diceware passphrases not depending on the secure element rate limiting.
To make a strong passphrase convenient to use without ruining it with biometric unlock, GrapheneOS adds an optional 2nd factor fingerprint PIN. We reduce the allowed fingerprint attempts from 20 to 5 and failure to enter the correct 2nd factor PIN counts towards it. This enables using 6-8 random diceware words as the main unlock method required in Before First Unlock and fingerprint+PIN using a short PIN for convenience. Using a valid fingerprint prompts to enter the 2nd factor PIN which is needed to complete unlocking the screen and hardware keystore.
GrapheneOS greatly improves the exploit protections for the OS with hardened memory allocators and other features. It heavily uses hardware-based security features including hardware memory tagging (MTE) to protect against exploits. A partial overview of those protections is here:
https://grapheneos.org/features#exploit-protection
GrapheneOS adds specialized protection against attacks with physical access too. For example, it blocks new USB connections at a software and hardware level by default while locked and disables USB data as soon as there are no active USB connections.
GrapheneOS shipped a locked device auto-reboot timer back in June 2021. It can be set between 10 minutes and 72 hours. We enabled it by default using 72 hours and then lowered it 18 hours. It automatically returns the device to Before First Unlock state due to our memory zeroing as part of tearing down the OS and booting. We got Pixels to add memory zeroing for booting the firmware fastboot mode in April 2024. Apple and Google added a locked device auto-reboot timer in iOS 18.1 and Android 16. For Android, it can be enabled with the Android Advanced Protection Mode. Our implementation is better for multiple reasons but it's a useful feature regardless.
Android uses separate encryption keys for each secondary user and Private Space. GrapheneOS adds support for putting both back into Before First Unlock state without a reboot via end session for secondary users or toggles for either to do it by default. It's still much better for the device to be rebooted to get the main user back at rest, completely clear leftover data from RAM and block secure element updates.
Our duress PIN/password feature is a minor feature fitting into the bigger picture. It wipes the device when it's entered in any OS prompt for the current profile's PIN or password. It will wipe the device when entered into the authentication prompt for changing a sensitive setting or anything else requiring it, not only the lockscreen. It works across every profile including secondary users and Private Spaces, not only the main user.
There are multiple ways to use the duress PIN/password feature including writing it down on a phone case or a paper kept in a wallet. People should carefully consider how to use it in an actual duress situation where there can be physical or legal consequences for wiping the device. GrapheneOS doesn't require it to protect data from being extracted from the device, but it takes recovering it completely off the table even with the PIN/password for each profile on the device.
GrapheneOS doesn't depend on the duress PIN/password to protect user data. It's one of the tools it provides among the major privacy and security improvements it offers as a whole. Our features page provides an overview of what GrapheneOS offers compared to standard Android 17. It covers most of the major features we provide and many of the minor ones but there's also a lot more beyond it. Our release notes are a lot more exhaustive since we make sure to cover everything when it's added, changed or removed.
https://grapheneos.org/features
https://grapheneos.org/releases#changelog

2026-07-23 18:10:33 UTC

- reply

Relevant
#nevent1q…acc6

2026-07-23 18:06:33 UTC

432 Linux vulnerabilities in 24 hours (2026-07-09)
https://lore.kernel.org/linux-cve-announce

2026-07-08 19:03:57 UTC

New #GrapheneOS PDF viewer update with swipe gestures for pages and also a full migration to Kotlin.
#nevent1q…4xrh

2026-06-27 13:45:13 UTC

- reply

It's a known issue because the AOSP apps are old. When they get replaced with new ones having the latest VCF spec will be on there.

2026-06-23 21:04:21 UTC

- reply

(My client is very slow right now and so is internet so apologies if I send this multiple times)
The Owner user currently must be unlocked at startup first because that profile has critical OS functionalities running there. Sorry about that.
I would follow the same advices in the comments about how to get it serviced without needing them to unlock the device.

2026-06-06 19:27:53 UTC

- reply

Molly (hardened Signal client) is building a Signal server software called Flatline. This will allow creating Signal deployments with servers that aren't Signal's. They'll also be working on features such as supporting accounts without phone numbers.
#nevent1q…w4tr

2026-06-06 13:42:00 UTC

- reply

The big issue that the post is trying to address is that AOSP and therefore derivatives like LineageOS are also missing these patches for up to 6 months. When OEMs get security preview patches, they may only push ~10% of them earlier than their assigned date too. When switching you could be *less* patched, and it is the upstream's fault.
GrapheneOS on the security preview channel is the ONLY Android distribution delivering all available patches on a regular basis. Despite the embargo preventing releasing the sources, it is easy to use reverse engineering tools to compare differences between standard and security preview builds to find the vulnerability AND the embargo doesn't protect against a resourceful threat actor somehow getting that access.

2026-06-02 18:28:14 UTC

June 2026 Android Security Bulletin notes CVE-2025-48595 is being exploited in the wild. It's being widely misreported in tech media as a 0-day vulnerability being exploited. That's a major misunderstanding of Android Security Bulletins and how poorly OEMs keep up with patches.
Google disclosed CVE-2025-48595 to OEMs in a security preview release near the end of September 2025. Those patches are allowed to be shipped right away, so it was included in our 2025092501 release. We noted it was already publicly fixed so it was added to our regular releases too in 2025100300.
We quickly shipped the patch after it was disclosed to OEMs by Google but we plan to do better in the future. SQLite 3.44.5 was released with this backport on 2025-07-24. We weren't previously aware SQLite maintained upstream LTS branches for Android but our plan is to closely follow those now.
In this case, Google slipped up and took 2 months to add the patch to the security preview releases. We plan to avoid that in the future by handling this ourselves because this happens too often. It's also a nice example of how Android Security Bulletins are set extremely low expectations for OEMs.
#GrapheneOS quickly ships all security preview patches. Every AOSP patch included in the Android Security Bulletins was already available in GrapheneOS for over a month. We end up shipping patches 2-3 months earlier. Google having such low expectations for OEMs and even themselves is ridiculous.
Android's security patch system doesn't make any sense and is completely at odds with how quickly people can discover and exploit vulnerabilities with the help of LLMs. The security preview release system would be far more reasonable if the embargo for sources and details was no more than 48 hours.
Google's embargo system harms security for nearly all Android users by setting the expectation of patches taking 2 to 6 months for OEMs to ship after disclosure. Patches are available to sophisticated attackers as soon as Google discloses them to OEMs. A partial embargo for months makes no sense.

2026-05-24 13:16:21 UTC

If you downloaded Telegram from a site called APKPure recently, congrats: You downloaded an infostealer and all of your conversations were being logged to some guy's server.
https://blossom.primal.net/f85586093e58060fcfff4462cb6a35f4661b295874f8ec2704264d7c3e7108cb.jpg
C2: 38[.]190[.]225[.]166
SHA256: 7d44e0009d251ae4983f5bf29f7d8aa9af668df88dba05a17a7a314f6780ceff
https://bazaar.abuse.ch/sample/7d44e0009d251ae4983f5bf29f7d8aa9af668df88dba05a17a7a314f6780ceff

2026-05-20 22:29:51 UTC

- reply

We don't distribute on F-Droid, but this can be used in other operating systems. Best bet is to get the GrapheneOS App Store app so you can get automatic, verified updates for it.

2026-05-20 19:08:07 UTC

- reply

Yes. The data is the public domain LJ Speech dataset. LJ Speech uses user-submitted public domain recordings of audiobooks. LibriVox (audiobook platform) requires all recordings made for them to be in public domain.

2026-05-20 18:45:06 UTC

- reply

We already have forward and reverse geocoding! Check location services -> Geocoder

2026-05-20 18:32:37 UTC

- reply

That is speech to text, not text to speech. Speech to text will be worked on in the future.

2026-05-20 18:23:03 UTC

#GrapheneOS Speech Services, a high quality on-device text to speech engine built with open source models and training data is now available in the GrapheneOS App Store.
https://blossom.primal.net/d291141699f1061444044e52af6197c24c12adc6ba01c9c9a48134897b36da81.jpg

2026-05-18 21:02:21 UTC

I think this is probably considered a hot take here but the quality of feature implementation matters far more than the implementation of a feature itself.

2026-05-17 17:17:01 UTC

- reply

Because it's one of the only
production wallets with full send/receive, I just set up a Cake Wallet for that. The other two I know of are so new or considered Alpha software so it's more about which is least worst. I don't think you can properly decide at this point, which is why I commented more wallets should be introducing it and then it can be better decided.
If you wanted PayNyms you are also stuck on using Sparrow or Ashigaru and the latter has barely been updated.
Once Sparrow Wallet supports SP fully, I will set up my own way with that since it should also support external signers with BIP375/376. Possibly able to accept them for GrapheneOS donations like we had for PayNyms.

2026-05-17 16:19:54 UTC

I have no comment on on-chain zaps. Likely won't use them or they just go sweep to the GrapheneOS Foundation.
You can use Silent Payments for me though:
sp1qqtdguesl4e507rt9m0pwfxvwxh2wf9c74pk9v4dclnf8agxe5vwq6qml9d4h6gz0vwf3dhgvznmvpu4z0gnfr33mr5wzmlcuxpqnturehvypr803

2026-05-17 11:59:26 UTC

- reply

Keep in mind we don't support any device older than 6th generation because they are end of life. Moment they become end of life, the firmware no longer recieves patches. It would be misleading to claim security on a device that recieves incomplete patches.

2026-05-17 11:56:51 UTC

"Google Pixel with GrapheneOS: resistant to both BFU and AFU attacks on recent models (6[a] and newer). This is the strongest protection available on any Android device."
#nevent1q…2ez7

2026-05-17 11:51:48 UTC

Another great article by Osservatorio Nessuno explaining the tech and methods behind phone unlocking tools, notably Cellebrite used by law enforcement and governments.
https://osservatorionessuno.org/blog/2026/05/demystifying-phone-unlocking-tools-a-technical-overview/

2026-05-14 01:03:26 UTC

GrapheneOS releases for Pixel 10a are mo longer experimental. Feel free to use Pixel 10a with it.

2026-05-10 17:20:40 UTC

- reply

It will be the 2027 flagships, it won't be for a while if that changes anything.

2026-05-10 16:04:37 UTC

Apple and Google are gradually expanding their use of hardware-based attestation. They're convincing a growing number of services to adopt it. Google's Play Integrity API and Apple's App Attest API are very similar. Apple brought it to the web via Privacy Pass, which Google intends on doing too.
Google's Play Integrity API requires hardware attestation for the strong integrity level and is gradually phasing in requiring it for the more commonly used device integrity level. Apple already has it as a requirement. Over the long term, this will increasingly lock out hardware and OS competition.
The purpose of these systems is disallowing people from using hardware and software not approved by Apple or Google. This is wrongly presented as being a security feature. Banks and government services are the main ones adopting it but Apple and Google are encouraging every service to use it.
Apple's Privacy Pass brought hardware attestation to the web to help with passing captchas on their own hardware. Many people saw that as harmless since few sites would be willing to lock out non-Apple-hardware users. Apple and Google are both likely to bring broader hardware attestation to the web.
Google's reCAPTCHA is planning an approach where they use Privacy Pass on Apple hardware, their own approach on Google Mobile Services Android devices and a QR code scanning system to require an iOS or Google certified Android device for Windows and other systems:
https://support.google.com/recaptcha/answer/16609652
Banking and government services increasingly require using a mobile app where they can use attestation to force using an Apple or Google approved device and OS. Apple's privacy pass, Google's 'cancelled' Web Environment Integrity and now reCAPTCHA Mobile Verification are bringing this to the web.
Current media coverage for reCAPTCHA Mobile Verification misunderstands it and the impact of it. They're bringing a hardware attestation requirement to Windows, desktop Linux, OpenBSD, etc. by requiring a QR scan from a certified smartphone to pass reCAPTCHA in some cases. They could expand it more.
Control over reCAPTCHA puts Google in a position where they can require having either iOS or a certified Android device to use an enormous amount of the web. Google defines certification requirements for Android which includes forcing bundling Google Chrome, etc. It's enormously anti-competitive.
Google's Play Integrity API bans using GrapheneOS despite it being far more secure than anything they permit. It also bans using any other alternative. This isn't somehow specific to an AOSP-based OS. You can't avoid this by using a mobile OS based on Linux or FreeBSD instead. You'll just be more locked out.
Google's Play Integrity API permits devices with no security patches for 10 years. The device integrity level can be bypassed via spoofing but they can detect it quite well and block it once it starts being done at scale. The strong integrity level requires leaked keys from TEEs/SEs to bypass it.
It doesn't provide a useful security feature, but it does lock out competition very well. Services requiring Apple App Attest or Google Play Integrity are primarily helping to lock in Apple and Google having a duopoly for mobile devices. Play Integrity is more relevant due to AOSP being open source.
Governments are increasingly mandating using Apple's App Attest and Google's Play Integrity for not only their own services but also commercial services. The EU is leading the charge of making these requirements for digital payments, ID, age verification, etc. Many EU government apps require them.
Instead of governments stopping Apple and Google from engaging in egregiously anti-competitive behavior, they're directly participating in locking out competition via their own services. Requiring people to have an Apple device or Google-certified Android device is anti-competition, not security.
reCAPTCHA Mobile Verification will currently work with sandboxed Google Play on GrapheneOS but it clearly exists to provide a way for them to start using hardware attestation on systems without it. People without an iOS or Android device will be locked out when this is required even without that.
This isn't about security or any missing functionality. GrapheneOS can be verified via hardware attestation. Google bans using GrapheneOS for Play Integrity because we don't license Google Mobile Services and conform to anti-competitive rules already found to be illegal in South Korea and elsewhere.

2026-05-10 11:21:07 UTC

- reply

We officially announced it was Motorola Mobility, the Lenovo brand.

2026-05-10 00:40:14 UTC

This week, we patched a VPN leak in Android that was reported to Google but was ignored. Here is some coverage about that:
https://cyberinsider.com/grapheneos-fixes-android-vpn-leak-google-refused-to-patch
Here is the original vulnerability report:
https://lowlevel.fun/posts/tiny-udp-cannon-android-vpn-bypass/

2026-05-08 06:30:38 UTC

GrapheneOS isn't vulnerable to the 3 recently disclosed Linux kernel vulnerabilities named Copy Fail, Copy Fail 2 and Dirty Frag. Current Android Open Source Project SELinux policies block exploiting all 3 bugs. Standard AOSP GKI kernel configuration also has 2/3 of the vulnerable features disabled.
Attack surface reduction via fine-grained SELinux policy rules and stripping out unused kernel features via kernel configuration goes a long way to protecting against vulnerabilities. There's also seccomp-bpf for various standard sandboxes but most of the attack surface reduction is via SELinux.
AOSP uses SELinux to allowlist ioctl commands for drivers, permitted socket types, etc. in a fine-grained way. It strictly controls a lot of functionality prone to vulnerabilities including user namespaces and io_uring which aren't allowed to be used by apps or nearly any of the base OS processes.
These kinds of issues are rare and attack surface reduction is the best way to defend against them. #GrapheneOS does additional kernel attack surface reduction but in these 3 cases it's enough to have modern AOSP GKI kernel and SELinux policies. We also greatly improve generic exploit protections.
Local privilege escalation vulnerabilities in the Linux kernel are very common. However, the vast majority are memory corruption bugs rather than these memory-related logic errors. We defend against the memory corruption bugs with hardware memory tagging, zero-on-free and similar generic defenses.
Linux has a massive amount of code for the core kernel and drivers for the hardware. All of the code runs with full privileges with no isolation. In a microkernel, each of these 3 recent vulnerabilities would have been in isolated processes. Virtualization will have a major role in addressing this.
Despite these not being traditional memory corruption, a memory safe language with a better type system would definitely help. Containing low-level handling of memory to a much smaller portion of the kernel and mostly using safe abstractions for networking, device drivers, etc. would help a lot.
Linux has a relentless flood of severe memory corruption bugs being discovered. Nearly all exploit chains for Linux-based systems by commercial and government exploit developers use Linux kernel memory corruption bugs. It's a lot harder to make very portable and reliable exploits for those bugs.
A lot can be done to further reduce Linux kernel attack surface in GrapheneOS and much better generic memory corruption exploit protections can also be developed. However, it clearly needs to be replaced. Hardware-based virtualization on smartphones keeps getting better and has a major role to play.

2026-05-05 19:01:49 UTC

- reply

For the future, yes.
Work currently is being done on Messaging, Contacts (to be completely redone from their AOSP base) and Gallery (fork)

2026-05-04 19:57:32 UTC

- reply

We are releasing an update today to fix this leak.

2026-05-04 19:54:32 UTC

The #GrapheneOS Gallery app is going to be replaced with a fork of ReFra. Here is how the app looks. It is far more complete and full of features than the original AOSP Gallery. I am sure you will like it.
https://blossom.primal.net/fff593a72e79f93448fe238f510479c1c15c8772515102b7a7870e5cf196684a.jpg
https://blossom.primal.net/52abbf4c8bfd07350448fbc3b728029b19369a754f2db2ec1e980d1093ac163c.jpg

2026-05-04 19:25:02 UTC

- reply

Reading the post, it looks like this leak was reported upstream into AOSP and was just ignored by them outright. What a mess.
We'll look into producing a fix for this ourselves and forward to the right people since they won't. If the researchers themselves also sent these things to us we could work on fixing them sooner.
Fortunately a native app needs to go out of their way to be designed to do this and certainly no app beyond this PoC is doing it right now.

2026-04-26 00:12:55 UTC

- reply

This looks awesome!

2026-04-18 07:47:07 UTC

- reply

Not right now. The system apps handle many OS/app intents, like camera, contact management, webview and file management.

2026-04-18 07:44:42 UTC

- reply

GrapheneOS doesn't persistently store notifications unless users explicitly enable notification history. For users enabling notification history, it's a 24 hour log that's cleared as soon as the feature is disabled again. This is the standard Android Open Source Project approach.
#nevent1q…mu5c

2026-04-15 19:18:45 UTC

Privacy and security on computing devices need to become far stronger to protect people from pervasive violations of their rights. Users have their privacy pervasively violated by corporations, criminals and governments. There are endless privacy and security weaknesses in software with exploits of those happening on a large scale. Operating systems, browsers and other apps need to do a much better job protecting users. Enormous progress is needed on both privacy and security.
#GrapheneOS provides a massive upgrade for privacy and security over the standard Android Open Source Project. GrapheneOS is nowhere near good enough and we have an enormous amount of work to do improving both. Our work is an ongoing process and doesn't have an end point. Privacy and security heavily involve competition between attackers and defenders. Most defenders are making little progress and falling increasingly far behind.
Attackers continue improving their exploits of privacy and security weaknesses. Commercial exploit tools are increasingly widely deployed for broad attacks. Software has a very high density of privacy and security vulnerabilities. LLMs are accelerating both vulnerability discovery and exploit development. For most computing devices, defense is increasingly far behind offense. iOS and GrapheneOS are exceptional cases not representative of degrading privacy and security across computing devices.
Growing numbers of internet connected devices are incorporated into botnets. This harms the privacy and security of the internet as a whole through heavily pushing it towards centralization behind services such as Cloudflare. Insecure devices without security patches harm the internet as a whole. It isn't only embedded devices but also desktops, mobile devices and servers being used as part of these botnets. It isn't only people with these insecure devices who are harmed. It can get much worse.
We're building GrapheneOS to protect everyone's privacy and security. It's aimed at widespread adoption and is highly usable. It's compatible with the vast majority of Android apps. It has major privacy benefits for every user including stopping a lot of data collection by apps and services with a better permission model increasingly addressing being coerced to grant access. GrapheneOS has many users with little technical knowledge and isn't hard to install or use.
We're continuing to work on improving privacy, security, usability and app compatibility for all of our users. Contact Scopes, Storage Scopes, per-app Sensors toggle, VPN leak protection and many other features we provde are very important privacy protections. We're building alternatives to the Camera, Microphone and other permissions too. Our major improvements to exploit protections are there to protect user privacy. Privacy depends on security and that's why we heavily work on security too.
Contrary to what's often claimed, GrapheneOS is far more usable and requires far less sacrifice compared to other alternatives. Providing far better protection against sophisticated exploits isn't at the expense of that. Our opt-in sandboxed Google Play compatibility layer combines privacy and high usability. We're gradually making replacements for more Google services apps rely on. Location services, network-based location, geocoding and more has already been replaced and much more is coming.

2026-04-06 21:42:29 UTC

We need more apps with widgets. Can't make my home screen look good...

2026-04-06 12:52:12 UTC

- reply

Where have you seen this? We have the build instructions here at https://grapheneos.org/build

2026-04-05 11:26:29 UTC

- reply

Use the Telegram official app if you use Telegram. You're using Telegram anyway. There's not really a "hardened" alternative I recommend like Molly for Signal.

2026-04-05 10:39:57 UTC

(updated post) The Nekogram telegram client contains code that grabs your Telegram ID and phone number to send to their own bots, also some other OSINT bots mentioned. They admitted to it in their channel (@NekoUpdates) and are insulting users in the comments. Assume your number and user can be correlated at a worst case. Keep away from third party clients.
https://github.com/Nekogram/Nekogram/issues/336
https://github.com/RomashkaTea/nekogram-proof-of-logging

2026-03-27 07:32:13 UTC

- reply

The CIA could definitely hire anyone from any country they wanted to lol. Devs aren't able to commit their own code to our repos regardless and it must be peer reviewed through PRs anyone can see.

2026-03-25 21:32:07 UTC

- reply

More things like Messaging, Keyboard, Gallery, Dialer, the prebuilt apps. Terminal is something we can look at as well but there's a lot of user experience improvements we want to make with the everyday apps.

2026-03-25 19:38:40 UTC

We are hiring Android app software engineers to develop and take ownership of maintaining new #GrapheneOS default applications. This is a fully remote, worldwide position.
If you have experience in Kotlin, Jetpack Compose and shipping production Android applications with commitment to security and privacy principles, come help fruit the next chapters of GrapheneOS.
Apply:
https://grapheneos.org/hiring#android-apps-software-engineer

2026-03-21 14:07:00 UTC

- reply

Those are for project account pages. There is no project page for GrapheneOS. I'm just one guy.
Updating GrapheneOS can be done via Settings app but it is usually done seamlessly and in the background. You'll receive a notification once it's installed requesting to restart. For most people it restarts on its own overnight.

2026-03-20 23:06:36 UTC

Pixel 10a users can now try out our experimental release of #GrapheneOS. Help us fix any potential regressions for a stable release!
#nevent1q…jppy

2026-03-20 20:57:36 UTC

#GrapheneOS version 2026032000 released. This release introduces experimental support for the Pixel 10a.
- add experimental Pixel 10a support
- Launcher: change app drawer search bar to cancelling search when the back action is invoked instead of the query becoming empty
- backport SELinux policy for CameraX extensions property used by the Pixel Camera HAL from Android 16 QPR3
- hardened_malloc: multiple small optimizations to improve performance
- kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.166
- kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.127
- kernel (6.12): update to latest GKI LTS branch revision including update to 6.12.76
- Vanadium: update to version 146.0.7680.153.0
- adevtool: add support for keeping only certain unpacked images to help with constrained storage
- switch to cross-device gmscompat_lib key for 10th gen Pixels
- Auditor: update to version 91
All of the Android 16 security patches from the current April 2026, May 2026, June 2026, July 2026 and August 2026 Android Security Bulletins are included in the 2026032001 security preview release.
List of additional fixed CVEs:
Critical: CVE-2026-0039, CVE-2026-0040, CVE-2026-0041, CVE-2026-0042, CVE-2026-0043, CVE-2026-0044, CVE-2026-0049, CVE-2026-0052, CVE-2026-0073, CVE-2026-0080
High: CVE-2025-22424, CVE-2025-22426, CVE-2025-48600, CVE-2025-48612, CVE-2026-0016, CVE-2026-0036, CVE-2026-0048, CVE-2026-0050, CVE-2026-0053, CVE-2026-0054, CVE-2026-0055, CVE-2026-0056, CVE-2026-0059, CVE-2026-0060, CVE-2026-0061, CVE-2026-0062, CVE-2026-0063, CVE-2026-0065, CVE-2026-0067, CVE-2026-0070, CVE-2026-0074, CVE-2026-0075, CVE-2026-0076, CVE-2026-0077, CVE-2026-0078, CVE-2026-0079
https://grapheneos.org/releases#2026032000

2026-03-20 20:47:30 UTC

- reply

This is not LineageOS but MicroG's distribution of it. A confusing name.

2026-03-20 18:58:19 UTC

- reply

We're yet to see this implemented in AOSP. We won't be adding sideloading restrictions.

2026-03-20 12:26:16 UTC

GrapheneOS will remain usable by anyone around the world without requiring personal information, identification or an account. GrapheneOS and our online services will remain available internationally. If GrapheneOS devices can't be sold in a region due to their regulations, so be it.

2026-03-07 17:24:39 UTC

- reply

McDonalds when they are requiring strict device integrity and OS enforcement they can be 100.00% sure that I like burgers
https://blossom.primal.net/784ae564927621a16743a487ef2fff4407b727e3680e824545691ecbed48abab.jpg

2026-03-07 17:21:52 UTC

The official microG OS project (https://lineage.microg.org) leaked their private keys for logging into their servers and signing releases:
https://github.com/lineageos4microg/l4m-wiki/wiki/December-2025-security-issues
We make our official builds on local machines. Our signing machine's keys aren't ever on any storage unencrypted.
Our roadmap for improving security of verifying updates is based on taking advantage of the reproducible builds. We plan to have multiple official build locations and a configurable signoff verification system in the update clients also usable with third party signoff providers.
We don't have faith in any available commercial HSM products being more secure than keeping keys encrypted at rest on the primary local build machine. Instead, we're planning to develop software for using the secure element on #GrapheneOS phones as an HSM for signing our releases.

2026-03-07 02:19:35 UTC

Proton on the news, again!? So let's bring it back!
#nevent1q…tkkc

2026-03-05 23:29:26 UTC

- reply

No future devices based on current ones looking at as targets appear to be that small. Closest is the Motorola Signature which is 6.8, assuming the next gen successor is the same size as the Signature. The razr ultra is a little slimmer but 7 inches, but folds.

2026-03-05 23:25:35 UTC

- reply

The device / OS pair is certified. It has some requirements that if the OEM follows them they are able to be certified. For example, Google services available, many as privileged components. While we have sandboxed Google Play that is still not sufficient. Some users don't have a play services implementation at all.
So while some OEMs make awfully changed Android releases, ours is left in the dirt there. We don't try for Google certifications.

2026-03-05 23:20:00 UTC

- reply

Imagine it is too late. Will be using the Qualcomm SOC secure element. OpenTitan also isn't built for Android (Titan M2 is based off of this), so there would have to be someone willing to manufacture secure elements and support the Android APIs, etc.
Regardless this article is seriously great news.

2026-03-05 08:40:53 UTC

- reply

I'm far from a bitcoiner... Strongly dislike maxi groupthink. That post is about funds being moved out of bitcoin and into monero. My following list is mostly devs or xmr. Not sure how praising an availability of a service to offload received funds into xmr is giving up ideals... unless the ideal was being bitcoin only or something? I think people can use what they want.
A ton of privacy features for on-chain bitcoin like Silent Payments are just under adopted (most are just users of one wallet that is on a smartphone) that recieving LN and ramping out into Monero is a much more likely outcome. You're likely to get an LN or XMR address to send/receive to a merchant than a SP address today. Hope it changes.
Nostr users are there because it is almost entirely centred around Lightning. The best clients for it are too. Monero oriented clients are often weird forks or too new to recommend anywhere for my taste. I'm pretty strict on keeping away from software that is new or experimental.
I do want to see improvements on more wallets adopting SPs (big fan of Sparrow) and Nostr clients outside of bitcoinery though

2026-03-05 08:08:26 UTC

- reply

Obviously they'd avoid using a different currency to transact as much as possible.

2026-03-05 08:05:06 UTC

- reply

This comment, but I'm mostly talking about recieving funds online. A monero user wouldn't store any funds in Lightning, they simply swap what they recieve into Monero or swap out to make a transaction immediately.
If I had problems with swap services or Spark knowing too much I'd roll funds out to other wallets. This is including both the LN or XMR side. For a long time I off-ramped zaps into other LN wallets or swapped them already.

2026-03-04 21:30:26 UTC

- reply

It gets people to gateway into Monero far easier. A lot of concepts people are familiar with in cryptocurrency spaces do not exist or matter in Monero either due to a different climate or technical differences.
You definitely have to be a more technically inclined and aware person to use XMR (this can also be considered a merit) so I think having swaps to/from assets with greater mini economies greatly decreases the entry barrier.

2026-03-04 21:26:41 UTC

- reply

XMR can be difficult to receive for new users. Having a lightning address to receive funds that can be swapped is significant. Lightning is very popular amongst smaller purchases and online stores. I buy a fair amount of living resources using ZEUS.
I mention Nostr specifically since Nostr is almost entirely oriented around Lightning. Nostr clients oriented around other assets are often lesser maintained and more risky. These clients are a security haunted houses to begin with. Better to have some sort of LN address to receive and then swap for people into that imo.

2026-03-04 21:19:41 UTC

- reply

Yes. Swapping opening up access to a lot of vendors in both teams to make private purchases with one another.
Especially helpful at this current moment since on-chain BTC privacy features like Silent Payments are seldom adopted except for Cake Wallet and partially in Sparrow Wallet. SP to XMR swap far less likely to be than XMR/LNBTC as of right now.

2026-03-04 20:36:08 UTC

Lightning support in Cake Wallet should be huge for XMR nostr users
https://blossom.primal.net/d93fa65cb5fc9f0ed35c9a1371fd3be9273c7693b1912e76072ee6296eaab767.jpg

2026-03-04 20:25:20 UTC

- reply

...you can argue that Windows was already full of sketchy bloatware without the OEMs bundling bullshit too. it's really sad to see what has been going on with Windows in recent times.

2026-03-04 20:22:14 UTC

- reply

If you mean modified as in installed another OS, barely any in this case. They're all non-Google certified operating systems so Play Integrity hardware attestation can force apps not to work on LineageOS, CalyxOS etc.

2026-03-04 20:20:52 UTC

- reply

Thanks!

2026-03-04 20:20:24 UTC

- reply

There's nothing to mitigate in the first place. It has nothing to do with GrapheneOS or smartphones. Every Windows laptop vendor has bundled sketchy bloatware in the past and many still do in the present. Security research targets are encouraged, feel free to find something, anything, in these devices that you think are off. Use a non-Motorola device if you want to choose based on pure vibes or you don't like them for any other reason. If you're an OEM, contact us and work with us.
If you really have to get to the details then Superfish is not installed by the firmware but was bundled operating system software and was trivially discovered. Obviously, there's no such thing that will happen here or GrapheneOS, it would be caught by our (very) vigilant users and I know I put the rep on the line saying that.
>now these assholes control the bootloader, the baseband
The bootloader is a standard littlekernel-based Android bootloader. The baseband is Qualcomm's, part of their SoC. Our device requirements on the site state explicitly radios must be isolated and that sensitive data cannot be accessed at the bootloader (working verified boot, zeroing memory left over from the OS, etc.), we are very conscious about that and received bounties for discovering and patching security deficiencies in bootloaders targeting Pixels that were exploited in the wild.
We'll be having involvement in the driver and firmware side of things. Working to improve their security posture and harden their stock OS and firmware is part of the partnership.

2026-03-03 20:56:10 UTC

New update of #GrapheneOS with this month's full security patch level. With the security preview release, all of the Android 16 security patches from the current March 2026, April 2026, May 2026, June 2026, July 2026 and August 2026 Android Security Bulletins are here too.
#nevent1q…jy3v

2026-03-03 20:47:51 UTC

- reply

What we need more than funding is development resources really. It would be nice to make major improvements to GrapheneOS before devices come out, especially the usability front so we have an even better experience for the tons of new users who would arrive. Motorola could try help us with this (GrapheneOS obviously will remain free and open source).
We are hiring a few new devs for this too.

2026-03-03 07:42:05 UTC

- reply

This is what we will be working towards, yes. If we can get devices to come with GrapheneOS that's a plus.