Final

Operations staff @ GrapheneOS Foundation.

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

Email: [email protected]
Matrix: f1nal:grapheneos.org

Public Key

npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y

NIP-05 Address

[email protected]

Profile Code

nprofile1qqstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgspp4mhxue69uhkummn9ekx7mqpr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqm79n2l

Publishing to

nos.lol

nostr.bitcoiner.social

nostr.mom

Author Public Key

npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y

Show more details

Last Notes

2026-09-01 06:12:54 UTC

We have good news about the Pixel 11. It still has at least bare minimum support for MTE at a hardware level. We think they removed most of the hardware acceleration from the CPU cache to save money. They ruined the performance so it ended up being fully disabled in firmware. It may still be usable.
Android 17 QPR2 Beta 4 was released on August 28th. It's the first Beta release with Pixel 11 support. MTE support is still completely disabled in the OS and arm64.nomte is unconditionally passed by the firmware to the kernel. The good news is the firmware itself had MTE support added back to it.
It's possible to enable reserving the tag memory for MTE via `fastboot oem mte on`, boot a non-stock kernel ignoring arm64.nomte and use MTE. We're in the process of determining whether it's fully functional and the performance characteristics. It's likely disabled due to performance being ruined.
We expect performance must be quite bad for Google to have decided to entirely strip out support for it in not only the software but also the firmware so that no would could even try to use it before Android 17 QPR2 Beta 4. That's a very strange thing to do. It's at least added back to firmware now.
We reached out to multiple people at Google asking about the MTE situation on the Pixel 11 prior to making our original thread and didn't receive any responses. We still don't know what's wrong with MTE on the Pixel 11. It isn't clear if there are serious CPU errata or it simply performs very badly.
If the issue is simply that MTE performance is poor, then we can support the Pixel 11 in #GrapheneOS with the major caveat that it will be a significant performance downgrade. Aside from MTE, Google downgraded the Pixel 11 series GPU compared to the Pixel 10 series in addition to reducing RAM for base Pro models.
Google has been increasingly silent in response to any communications since dropping Pixel support from AOSP with Android 16 in June 2025. They could have told us MTE performance was significantly reduced so they disabled it at launch but will add it back to firmware for QPR2. That's still unclear.
Android 17 QPR2 Beta 4 releases for the Pixel 11 series were only uploaded around 10 hours ago rather than with the initial release on August 28th so this hasn't been available for very long. It wasn't missed by us or people who looked into it after our initial thread but rather wasn't out yet.

2026-08-30 22:56:47 UTC

- reply

See my previous posts on here

2026-08-30 22:13:16 UTC

Near the end of May 2026, Russia began filtering access to DataPacket IP space with an enforced domain allowlist for HTTP and TLS SNI. #GrapheneOS services aren't on the allowlist so we had to switch from DataPacket Frankfurt to Cherry Servers Amsterdam for Russia. That's now getting filtered too.
We've fixed it again by using Zare London for connections from Russia instead. That's the final of our sponsored servers in Europe we can use so we'll need to fall back to Xenyth Toronto if they filter it. We're using our own IP space in Toronto so it should work unless they specifically block us.
We don't think we'll be blocked directly but we're also unlikely to get placed on the allowlist. That means our services are gradually going to become inaccessible in Russia via the IP space of major cloud services. Our own IP space will still work fine and we don't host any VPN services ourselves.
Our website, OS updates, app repository, connectivity checks, network time, network-based location, geocoding and other main services should work again in Russia. It's likely they'll expand to filtering Zare's IP space and then we'll have to use Toronto where we have our own non-anycast IPv4 /24.
They use a domain blocklist for most of the internet and an allowlist for many VPS and dedicated server hosting providers to block access to VPN services. It's likely they'll expand to enforcing an allowlist for every major server hosting provider. That's far more aggressive than China's filtering.
Our authoritative DNS is hosted via 2 anycast networks using our own ASN and IP space so it hasn't been impacted by this. It's likely we can avoid it for the rest of our services by using our own IP space. If they start filtering netcup IP space, we can make a reverse proxy to those from Toronto.
If our services are blocked, connectivity checks can also be set to Standard rather than Disabled to use the Google servers. That'll keep automatic selection of networks with internet working along with automatic captive portal handling and JobSceduler not assuming every network has internet access.

2026-08-30 21:57:47 UTC

Searching 'MTE' on Twitter to see countless established security researchers shocked at the Pixel 11. Clear example on how to alienate a community.

2026-08-30 20:41:22 UTC

- reply

2027. We will make announcements on our progress with Motorola when appropriate.

2026-08-30 20:39:50 UTC

- reply

They can connect to GrapheneOS services again without one, providing they don't choose to block GrapheneOS directly.

2026-08-30 20:21:25 UTC

- reply

Cost cutting in favour of trying to profit with their AI product. It's just that one feature despite security improving a lot elsewhere. They added a weird Gemini colored LED to the back of the new phones. They moved to a new generation processor and they never used MTE in production in the previous phones for almost all of the OS for the devices they had it, being limited to Android's Advanced Protection feature. It's likely they stopped caring about it.
Apple has it in some places on their latest iPhones and is always on for iOS.

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-24 20:58:56 UTC

- reply

None of their phones have that. I know the ThinkPhone exists but that was just a typical smartphone for enterprises.

2026-08-24 09:55:22 UTC

- reply

Motorola Mobility (Lenovo).

2026-08-22 22:08:26 UTC

- reply

Like most vendors it's from when the device is first released. GrapheneOS users will be familiar with that since Pixels work like this with 7 years of updates from launch.

2026-08-22 16:34:38 UTC

- reply

The Secure in this instance means a place that is difficult to get out of or escape from, rather than the digital security itself. The purpose is to store sensitive data away from the OS so it is not compromised if the OS is. There are many secure elements that have poor security, like your standard dedicated desktop 'TPM'.

2026-08-22 16:29:16 UTC

- reply

The latter.

2026-08-22 16:26:14 UTC

I very much appreciate the human (or strong effort to make it appear human) design of the upcoming Monero site.
I hate extremely vibe coded web sites more than apps themselves. The web site is your space to promote and document your software, so in my eyes it has to be written by you because it represents the authors.
https://beta.getmonero.org/

2026-08-22 08:27:55 UTC

Initial focus for our partnership with Motorola is a regular non-folding device. Current generation Motorola Signature (2026), Razr Fold (2026) and Razr Ultra (2026) are very close to meeting our requirements but lack MTE, adequate secure element integration and other features being added for 2027.
Flagship Snapdragon provides much better CPU and GPU performance and provide more of what's needed via isolated components on the SoC. That includes better cellular, Wi-Fi/Bluetooth and GNSS radios with solid security including good isolation. Snapdragon Pixels worked well for us and it will again.
Tensor was a sidegrade or downgrade from Snapdragon in many ways. Tensor is paired with the fantastic Titan M2/M3 which was a huge security advantage. It also brought hardware memory tagging (MTE) with the Pixel 8. Snapdragon 8 Elite Gen 5 finally shipped MTE but it's broken on the non-Elite SoC.
Next generation Snapdragon will have more mature support for MTE and greatly improved secure element support. It's still likely going to be a lot of work to get MTE fully deployed for the kernel and OS. We need all our hardware-based features including our USB-C port protection ported to it too.
These devices will meet or exceed of our official requirements including 7 years of proper updates, starting out with the Linux 6.18 LTS which can be upgraded to a new branch eventually, reset attack protection for firmware boot modes and everything else. There wasn't time to do it all for 2026.
It's very realistic to provide better security than Pixels against remote attacks. It's far harder to provide a secure element as good as the Titan M2/M3. There will definitely be a decent secure element providing the current generation features including the Android 16 QPR2+ rate limiting design.
Pixels have become much harder to support. AOSP 16 removed support for Pixels and they became harder to properly support than many other devices rather than easier. It's crucial to keep up with the major OS updates to provide all the security patches and we do but it's much harder for us now.
Motorola is doing a large portion of the work of porting #GrapheneOS to their devices. They'll provide us with what we need for firmware/drivers in the form we need it and it will be far easier than Pixels. We'll be able to get issues in the firmware and drivers fixed through Motorola and Qualcomm.
We do plan to support Motorola's Razr Fold and Razr Ultra (flip) devices in addition to a regular device. We already support the original Pixel Fold (Pixel 7) along with the Pixel 9 Pro Fold and Pixel 10 Pro Fold. We still plan to add support for 11th gen Pixels including the Pixel 11 Pro Fold too.
Supporting a flip device with vertical folding would be a new form factor for GrapheneOS. The main use case for those is a tiny phone to use with one hand in the folded form factor. The tablet-style folding devices we already support are extremely useful for web browsing, reading, maps, etc.

2026-08-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-16 11:31:53 UTC

848 Linux CVEs in the past 24 hours BTW
https://app.opencve.io/cve/?q=vendor%3Alinux+AND+created%3D2026-08-15
#nevent1q…huw8

2026-08-16 09:47:07 UTC

- reply

The feature is on by default. If you want to turn it off you can do that in GrapheneOS (with all alert types unlike the stock OS). So people saying it's off in GrapheneOS are only half-correct.

2026-08-15 14:54:51 UTC

- reply

Android does a ton of that already. The amount of vulns discovered has significantly increased. On our end, we have Anthropic accounts with security restrictions lifted for our own testing too.
This shouldn't replace others trying to look for vulns themselves. We don't have the manpower to have a couple of people hammering everything with agents to find bugs full time. We are fortunate to be using a codebase that actually does have that.

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

- reply

I haven't seen much on the claims they made, nor the quality of their implementations to know, simply at a design perspective. The Betrusted original is very interesting as is their Precursor product but from what I can infer they are dev kits while KeyOS is meant to be a production OS, even running on completely different CPU architecture

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

- reply

Linux has had days where hundreds of CVEs come up at once for a while. I reposted times it's happened before. It's not so unique.

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-10 07:38:26 UTC

One of the so-called 'missing' CVEs (CVE-2015-6609) was discovered by the founder and original lead developer of GrapheneOS in *2015*. The methodology here was so poor it is making false measurements for vulnerabilities the project disclosed.
https://source.android.com/docs/security/bulletin/2015-11-01#acknowledgements
#nevent1q…qypy

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-06 19:50:50 UTC

We should call software less buzzwords. Something that's 'Cypherpunk', 'sovereign' and 'freedom' actually tells me nothing about their properties.

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

- reply

Other VPN apps work fine. Something wrong with Orbot particularly? Unsure if they have even full support for Android 17.

2026-08-04 03:21:12 UTC

- reply

If we want to implement something deniable, it has to be a different approach. Virtualization and amestic systems come to mind.

2026-08-03 07:54:47 UTC

- reply

Making easy access to your code also goes a long way. libngu made many mistakes:
- not on the ColdCard GitHub org, so harder for people to find
- git commit history looks like this:
https://npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y.blossom.band/f515a1ae400222d28dbc04f6d5926b2b6e7121f89650f0a388e777d4d9f7b345.jpg

2026-08-02 00:41:12 UTC

Chromium fork devs: We shall name it
*throwing dart at periodic table*... Gallium
Firefox fork devs: Introducing the Gooch Browser

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-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 22:45:37 UTC

- reply

According to the defendant's motion to suppress in this case, the authorities refused to read him his rights and also made extreme, unfounded accusations such as checking for CSAM (which was never implicated to be under their possession nor was the defendant ever indicted for it, it is not in any court docs) to try and coerce them into unlocking their phone. It appears he chose the Duress knowing he was not given his rights. I would be interested to see how this case develops.
Authorities CAN and WILL lie to you to try and incriminate you even if you have done nothing wrong. Do not talk to them, do not discuss your day and if you are in a questioning then exercise your right to remain silent and get a lawyer.

2026-07-23 22:34:26 UTC

https://www.theguardian.com/us-news/2026/jul/23/cop-city-protester-phone

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

- reply

GrapheneOS does not create identifiers for users nor track them. All services we do host require the minimum for that service to function, for example when requesting an OS update we would only be able to see an IP address checking an update for a certain phone model.
Android has an "Advertising ID" but this is Play Services dependent and can be deleted in their settings.

2026-07-19 17:38:28 UTC

Join Josh from Side Of Burritos and our Community Manager spring-onion in a live conversation about everything #GrapheneOS on July 20th!
PDT - 10:00 / 10:00 AM
EDT - 13:00 / 1:00 PM
UTC - 17:00 / 5:00 PM
BST - 18:00 / 6:00 PM
CEST - 19:00 / 7:00 PM
AEST - 03:00 / 03:00 AM / July 21st
To accommodate for different preferences the stream will be available simultaneously on both YouTube and a self-hosted instance of Owncast. Additionally, we will also be watching for your questions and comments in the media channels within our Discord and Matrix chats.
https://youtube.com/watch?v=56-DCAHU29Y
https://sideofburritos.com/live/
https://grapheneos.org/contact#community-chat

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-30 20:01:35 UTC

- reply

Yes, Android 17 blocks loopback access across profiles for tougher isolation.

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-27 13:42:39 UTC

- reply

From what I know the Accrescent developer had a lot of personal stuff going on (not bad! just that they're busy). They're doing a lot of stuff behind the scenes for it as seen on the GitHub org. I can ask but I can't make any guarantees and he possibly might not want to make exceptions at this stage.
https://github.com/accrescent

2026-06-27 13:37:30 UTC

- reply

What like? I assume most of them will be Android 17 limitations.

2026-06-26 05:32:14 UTC

- reply

Later next year

2026-06-26 05:25:18 UTC

#GrapheneOS releases based on Android 17 are in Stable now. Enjoy Android 17!
#nevent1q…fnnm

2026-06-23 23:16:34 UTC

- reply

The bookmarks? We have that:
https://npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y.blossom.band/d0b6d9085fe85d577b20668259c01729d0b9d6a0a540a9598194a6856a91ebfb.jpg

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-23 20:57:27 UTC

An Android 17 release of #GrapheneOS is now available in the Alpha channel for users who do not want to use an experimental channel. This is a major release with some more slight UI changes and an introduction of a Desktop Mode that can be enabled by plugging in a device to an external display via USB-C DisplayPort Alt Mode on Pixel 8 and later. We are regularly working on more fixes in the mean time and it is likely a later release will end up in Stable as there are more releases ready to come now.

2026-06-17 22:10:09 UTC

- reply

This is in our issue tracker and could be something to fix when we remake the Dialer app. We are currently doing an overhaul of all of the default apps, namely Messaging and Gallery.

2026-06-16 21:52:50 UTC

- reply

Availability of devices to the people working on the port. Don't worry, they'll get GrapheneOS at the same time too.

2026-06-16 21:45:48 UTC

Today is the official release day for Android 17. We've already fully ported #GrapheneOS to Android 17 and are in the process of pushing the code to our public repositories. We're building a final official release based on Android 16 QPR2 today and we'll do an initial Android 17 release tomorrow.
We've already tested the Android 17 port of GrapheneOS on the Pixel 6a, 7, 7a, 8, 10a, 10 and 10 Pro Fold. It will be possible for people to start building and testing it themselves later today once we finish pushing the code. We'll start the process of public testing for official releases tomorrow.

2026-06-16 21:45:04 UTC

2026-06-07 09:11:33 UTC

- reply

2. It's a Google / AOSP issue they deliberately hold back patches to critical / high vulnerabilities for over a month. It's also an issue of the OEMs who have these early access but don't issue all the patches. GrapheneOS Security Preview does.

2026-06-07 09:06:54 UTC

- reply

OEMs get early access to the patches and are allowed to push them on their OS, but no one does them all. Google and Samsung do a small amount of them. Since they are embargoed and not open source immediately, they aren't released into AOSP until months later with their scheduled security patch level.

2026-06-06 22:27:07 UTC

- reply

Not really needed, Molly is just a Signal fork with some added privacy and security features. If you use Signal you can use Molly too.

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

- reply

Doesn't mean much if the source is uploading a malicious app and the hash for the malicious app. The hash would match but it's obviously not Telegram. You'd have to compare the APK's signer to that of Telegram.

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:22:41 UTC

- reply

Yep. But Telegram storing all of your group chat messages and having no end to end encryption by default is expected behavior, not your actions also being sent to some random C2 server from an unknown individual. Even nonprivate instant messengers wouldn't dare stoop so low!

2026-05-24 13:19:23 UTC

- reply

inb4 obligatory 'why are you using telegram anyway' comment, I mean yeah, why the hell are you downloading Telegram especially from some third party app repo

2026-05-24 13:17:30 UTC

- reply

Credits to Eric Parker for the screenshot:
https://x.com/EricParker/status/2058411298195661221

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-24 12:54:48 UTC

- reply

A managed service doesn't equal a private or secure service and it isn't trying to say that it is. The post is saying average users (normies) will often use a managed service over running their own even if the service has problems. You could put any cloud storage in that scenario.

2026-05-24 12:42:04 UTC

- reply

I opened a dialogue with the author of this article recently to add some further information that might be of interest, given the article's nature I thought I would share it here too. Some of my suggestions have already been put in place. I will likely go on to recommend adding more countermeasures not mentioned in this article, such as the use of user profiles/private spaces for separated user data encryption.
This post provides an overview on how disk encryption works on Android, common attack vectors used by forensic tools to brute force or extract a device, their countermeasures against popular security features like automatic reboot in iOS and how you can protect yourself against such tools, including several mentions about #GrapheneOS.
#nevent1q…fg2w

2026-05-22 05:48:19 UTC

- reply

It's simply part of the Android OS location service:
https://developer.android.com/reference/android/location/Geocoder
I believe most major map apps support this. Not much on our end to do.

2026-05-21 20:50:51 UTC

>Add Silent Payments (SP) receiving wallets, including support for airgapped hardware wallet signers
https://blossom.primal.net/473825056c63fb6110983a4eb61cf5fd7019239746536c992c7119dfe9710636.gif
#nevent1q…zmhf

2026-05-21 20:41:22 UTC

- reply

There isn't a formal document on our roadmap beyond far future wishes in our FAQ but currently we're working on:
- Replacing Gallery (we're on the last steps for this)
- Overhauling SMS app (got a ton of progress for porting UI to Material 3 Compose/Kotlin but not done)
- To overhaul the contacts app and other apps
- Preparing for Android 17, which moves Desktop Mode to a production feature
A lot of accessibility stuff as well, such a improving the TTS engine, possibly SST. A lot of the work this year is to make GrapheneOS more usable and modern to prepare for the flood of Motorola users by next year.
Improving profiles is a minor feature we want to add later. The second suggestion wouldn't really be possible to meet it's goals as secondary users can't enable ADB for forensics tools that police use. You can't hide the fact you have multiple users at this time. Even the lock screen tells you.

2026-05-21 20:36:06 UTC

To also be pushed into the latest GrapheneOS release!
#nevent1q…g0cw

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 22:21:56 UTC

- reply

Adding more text from the official project announcement
Once it's bundled with the OS, it will be enabled by default so activating it won't be necessary. Needing to activate the TTS engine causes a lot of confusion since Android's standard user interface shows the first TTS engine as active if none is active due to assuming one is bundled.
Our Speech Services app uses a fully open source model for text-to-speech which we created ourselves using existing open source code and data. We'll be able to train a better model to replace this one now that we have an RTX 5090 for this purpose. We also plan to make voices for other languages too.
The second most used language by GrapheneOS users is very likely German and then likely French. UK English would likely be much easier to add than those due to shared code and data sources so we may do that first but German will likely be next if we can find high quality open data to use for it.
In the short term, we could alias all of the other English variants to US English to have it working by default with those selected as system languages. We don't really want to train more than US and UK voices in the mid term rather than adding other languages so we'll just alias those to US or UK.
We also plan to make our own speech-to-text implementation to go along with the text-to-speech implementation. The models are end up very large so it's unclear if we want to bundle more than US English with the OS. The other languages could be available as extra language packs in App Store instead.
#GrapheneOS

2026-05-20 22:18:09 UTC

- reply

Speech Services and Transcribro are by the same developer. Rest assured we know what we want to build next to be implemented into GrapheneOS.

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:31:55 UTC

This is the first release of our Speech Services text to speech engine. This introduces text to speech in the OS for apps that call for OS TTS. Please feel free to test this as the first users so it can be improved for future releases. Please note that only English (US) is available for this first release but others will be implemented in the future.
Since this is a text to speech engine and not a standalone application, you have to enable this in Settings > System > Language & Region > Speech > Text to speech output > Preferred engine. Eventually this will be default.
If an app calls for OS text to speech, for example Organic Maps/CoMaps, it will use it there.
#nevent1q…g0cw
#GrapheneOS

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:54:11 UTC

- reply

Already supported