<unnamed>

Public Key

npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y

Profile Code

nprofile1qqstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgspp4mhxue69uhkummn9ekx7mqpr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqppamhxue69uhkummnw3ezumt0d5g4dret

Publishing to

nos.lol

nostr.bitcoiner.social

nostr.mom

Last Notes

2026-01-18 15:02:05 UTC

- reply

This is known. It's a developer option and far from stable for daily usage. It will be looked at more once upstream improves it as well, unless we get the resources.

2026-01-18 15:01:15 UTC

- reply

It won't exactly be like Qubes but there will be a few improvements Qubes doesn't have i.e. verified boot, MTE and (if we are able to) run more secure operating systems out of the box. Would need to see how running multiple VMs is like first...
Unlike Qubes which defaults to Fedora and Whonix (which is just Debian, tons of OS hardening work was undone there) we would want to support hardened distros as soon as it becomes feasible for us. Changing Debian for Fedora is the first jump but want to go further with something like secureblue. The security of the guest OSes in the VMs also matter and if I had to name one shortcoming of Qubes this would be it.
They can't port secureblue to Qubes because it only supports Wayland which Qubes doesn't support yet.

2026-01-16 03:03:43 UTC

- reply

https://projectzero.google/2026/01/pixel-0-click-part-3.html
>We also discovered that kASLR is not effective on Pixel devices, due to a problem that has been known since 2016
KASLR works properly on GrapheneOS right now, unlike arm64 Linux elsewhere.
We fixed the issue of the physical address mapping not being randomized on arm64 Linux for GrapheneOS a while ago. The overall region is in a random location again including the kernel memory inside of it.
>Apple also recently implemented MIE, a hardware-based memory-protection technology similar to Memory Tagging (MTE), on new devices.
MIE is MTE. It is ARM FEAT_MTE4. It's Apples branding for MTE with a hardened allocator. Apple stepped forward in supporting MTE by default unlike stock Pixels.
>While MIE would not prevent the Dolby UDC vulnerability from being exploited in the absence of -fbounds-safety due to UDC using a custom allocator, it would probabilistically hinder an iOS kernel vulnerability similar to the BigWave driver bug from being exploitable. [...] Pixel 8 onwards shipped with MTE, but unfortunately, the feature has not been enabled except for users who opt into Advanced Protection mode, to the detriment of Pixel’s other users.
I don't think I need to mention which OS enables MTE by default for majority of the OS components and toggleable for user installed apps, unlike the stock OS.

2026-01-16 02:50:11 UTC

- reply

Fantastic work from Project Zero as always.
Thanks to security preview release channels these were patched in GrapheneOS before anywhere else. Considering memory corruption is involved and it was predominantly centered around Google Messages first, there would need to be a substantial effort to design an exploit chain around GrapheneOS if it was even possible. See what we said about it in November:
#nevent1q…rlzn

2026-01-15 05:03:30 UTC

- reply

You also have NextPush for Nextcloud too if Mozilla isn't your thing. Choices are pretty limited without hosting your own UnifiedPush infra unfortunately.
It is planned to work on having less features depend on sandboxed Google Play to reduce the need of people installing it for apps to work. We already do these efforts for apps like Google Messages and Pixel Camera.

2026-01-15 04:57:55 UTC

What this means that notifications will work for users not wishing to use play services sandboxed or otherwise.
Most android apps do notifications via FCM, which is Google's, and depends on a Play services implementation. If you ever wonder why app notifications barely work on AOSP distributions without Google services then now you know.
By using an app like Sunup (on Accrescent) you can use Mozilla's notification service via UnifiedPush for apps that use UnifiedPush notifications - such as this one.
Tell your developers to support notifications without Google.
#nevent1q…h0l3

2026-01-15 01:49:09 UTC

- reply

AOSP is working on implementing a Desktop Mode where you can connect your device to a monitor, keyboard and mouse and use a desktop environment where apps are windowed.
You can see some examples of it in GrapheneOS here:
#nevent1q…llnh

2026-01-15 01:45:18 UTC

- reply

The regressions with the Terminal app originate from the stock OS, including the VPN issue. The VM data also breaks and data can't be recovered at times. Don't store sensitive data without backups or run anything for production but feel free to try it out.
We do improve the Terminal app in a few ways and these fixes is something we need to look into but because it's still an experimental developer option it's priority isn't so high. If the stock OS deals with it first then it's less work on our plate. Desktop Mode needs to be first for all the cool stuff to happen.
What users see now will likely be very different to what our plans are should we be able to execute them. We don't want to just have a terminal but rather a VM manager capable of running other operating systems and GUI apps. Debian alone isn't desirable for our use case and we'd want a hardened OS like secureblue instead (ARM builds is beta). Virtualization could be extended to GrapheneOS or individual apps too.

2026-01-11 22:22:15 UTC

- reply

A hardened malloc notification would mean the application has a memory bug the exploit feature is detecting and forcibly crashes. Worth sending them the crash log.

2026-01-10 00:34:12 UTC

#GrapheneOS version 2026010800 released.
• raise declared patch level to 2026-01-05 which has been provided since we moved to Android 16 QPR2 in December due to Pixels shipping CVE-2025-54957 in December
• re-enable the system keyboard at boot if it's disabled
• switch to the system keyboard when device boots to the Safe Mode
• add "Reboot to Safe Mode" power menu button in Before First Unlock state to make Safe Mode much more discoverable for working around app issues such as a broken third party keyboard
• add workaround for upstream UsageStatsDatabase OOM system_server crash
• add workaround for upstream WindowContext.finalize() system_server crash
• disable buggy upstream disable_frozen_process_wakelocks feature causing system_server crashes for some users
• Sandboxed Google Play compatibility layer: fix phenotype flags not working in Play services clients
• Sandboxed Google Play compatibility layer: add MEDIA_CONTENT_CONTROL as a requested permission for Android Auto as part of our toggles for it to avoid needing to grant the far more invasive notification access permission
• Sandboxed Google Play compatibility layer: extend opt-in Android Auto Bluetooth support to allow A2dpService.setConnectionPolicy() to fix Bluetooth functionality (previously worked around with a GmsCompatConfig update avoiding a crash)
• switch to new upstream PackageInstallerUI implementation added in Android 16 QPR2 and port our changes to it
• update SQLite to 3.50.6 LTS release
• add an extra layer of USB port protection on 10th gen Pixels based on upstream functionality to replace our USB gadget control which was causing compatibility issues with the Pixel 10 USB drivers
• allow SystemUI to access NFC service on 10th gen Pixels to fix the NFC quick tile • disable the upstream Android USB data protection feature since it conflicts with our more advanced approach and causes issues
• issue CHARGING_ONLY_IMMEDIATE port control command in more cases
• fix an issue in our infrastructure for spoofing permission self-checks breaking automatically reading SMS one-time codes for certain apps
• add workaround for upstream KeySetManagerService system_server crash causing a user to be stuck on an old OS version due to it causing a boot failure when booting a the new OS version after updating
• wipe DPM partition on 10th gen Pixels as part of installation as we do on earlier Pixels since it's always meant to be zeroed on production devices
• Settings: disable indexing of the unsupported "Parental controls" setting which is not currently available in AOSP
• Settings: disable redundant indexing of widgets on lockscreen contents which is already indexed another way
• skip all pseudo kernel crash reports caused by device reboot to avoid various false positive crash reports
• Vanadium: update to version 143.0.7499.192.0
All of the Android 16 security patches from the current January 2026, February 2026, March 2026, April 2026, May 2026 and June 2026 Android Security Bulletins are included in the 2026010801 security preview release. List of additional fixed CVEs:
• High: CVE-2025-32348, CVE-2025-48561, CVE-2025-48615, CVE-2025-48630, CVE-2025-48641, CVE-2025-48642, CVE-2025-48644, CVE-2025-48645, CVE-2025-48646, CVE-2025-48649, CVE-2025-48652, CVE-2025-48653, CVE-2026-0014, CVE-2026-0015, CVE-2026-0016, CVE-2026-0017, CVE-2026-0018, CVE-2026-0020, CVE-2026-0021, CVE-2026-0022, CVE-2026-0023, CVE-2026-0024, CVE-2026-0025
https://grapheneos.org/releases#2026010800

2025-12-01 21:09:16 UTC

- reply

Redox is a fully working (but limited) operating system and is a microkernel. This is just a kernel project that also doesn't specify that if it is a microkernel or not (don't have time to see if it is right now) which is something we are explicitly interested in.

2025-11-24 20:14:35 UTC

We no longer have any active servers in France and are continuing the process of leaving OVH. We'll be rotating our TLS keys and Let's Encrypt account keys pinned via accounturi. DNSSEC keys may also be rotated. Our backups are encrypted and can remain on OVH for now.
Our App Store verifies the app store metadata with a cryptographic signature and downgrade protection along with verification of the packages. Android's package manager also has another layer of signature verification and downgrade protection.
Our System Updater verifies updates with a cryptographic signature and downgrade protection along with another layer of both in update_engine and a third layer of both via verified boot. Signing channel release channel names is planned too.
Our update mirrors are currently hosted on sponsored servers from ReliableSite (Los Angeles, Miami) and Tempest (London). London is a temporary location due to an emergency move from a provider which left the dedicated server business and will move. More sponsored update mirrors are coming.
Our ns1 anycast network is on Vultr and our ns2 anycast network is on BuyVM since both support BGP for announcing our own IP space. We're moving our main website/network servers used for default OS connections to a mix of Vultr+BuyVM locations.
We have 5 servers in Canada with OVH with more than static content and basic network services: email, Matrix, discussion forum, Mastodon and attestation. Our plan is to move these to Netcup root servers or a similar provider short term and then colocated servers in Toronto long term.
France isn't a safe country for open source privacy projects. They expect backdoors in encryption and for device access too. Secure devices and services are not going to be allowed. We don't feel safe using OVH for even a static website with servers in Canada/US via their Canada/US subsidiaries.
We were likely going to be able to release #GrapheneOS for experimental Pixel 10 support very soon and it's getting disrupted because of this. The attacks on our team continue to escalate. It is rough right now and your support is appreciated. Let's release soon.
#nevent1q…as3s

2025-11-23 16:59:33 UTC

More people should have the new updates with the UI refresh now.
#nevent1q…nqup

2025-11-21 11:19:34 UTC

- reply

Any works.
Cryptocurrency is encouraged since devs are paid with bitcoin or whatever their preference is.

2025-11-21 00:07:33 UTC

Interview of French federal prosecutor saying that not providing them with backdoors is unacceptable and they'll go after us with charges if we don't cooperate with them:
archive.is/UrlvK
There's a very direct threat towards us in that article. They've made it clear they do not consider it acceptable for there to be devices they cannot break into. In that interview, there's a clear statement they'll go after us as they did others if we don't "cooperate" with them.
The demands they have from us are unspecified but we're not going to wait around to find out what they expect from us. #GrapheneOS will exit remaining global infrastructure in France and OVH as soon as possible. We do not feel safe operating in a country with federal law enforcement agencies lying about us and threatening us.
France's government is a strong supporter of backdoors for secure messaging apps including heavily supporting Chat Control. They appear to have the same position on secure devices. Their previous law enforcement action against both was done based on claims of ties to criminals.
In some of the cases, it was clear the companies were tied to criminals. One of those companies was an FBI sting operation from early on which was advertising itself as being based on GrapheneOS. Maybe some of the ones they're conflating with us are also sting operations too.
They're conflating shady companies selling products they say are based on GrapheneOS with us. ANOM was a sting operation by the FBI paying criminals to sell phones to criminals while advertising it as being based on GrapheneOS. Since when is the FBI facilitating crimes in France our fault?

2025-11-20 23:15:49 UTC

- reply

Thank you! Despite the GitHub sponsors to him, it goes to the GrapheneOS Foundation. I am very grateful for what he has done for the team still.

2025-11-19 12:05:52 UTC

We at #GrapheneOS were contacted by a journalist at Le Parisien newspaper with this prompt:
> I am preparing an article on the use of your secure personal data phone solution by drug traffickers and other criminals. Have you ever been contacted by the police? Are you aware that some of your clients might be criminals? And how does the company manage this issue?
Absolutely no further details were provided about what was being claimed, who was making it or the basis for those being made about it. We could only provide a very generic response to this.
Our response was heavily cut down and the references to human rights organizations, large tech companies and others using GrapheneOS weren't included. Our response was in English was translated by them: "we have no clients or customers" was turned into "nous n’avons ni clients ni usagers", etc...
GrapheneOS is a freely available open source privacy project. It's obtained from our website, not shady dealers in dark alleys and the "dark web". It doesn't have a marketing budget and we certainly aren't promoting it through unlisted YouTube channels and the other nonsense that's being claimed.
GrapheneOS has no such thing as the fake Snapchat feature that's described. What they're describing appears to be forks of GrapheneOS by shady companies infringing on our trademark. Those products may not even be truly based on GrapheneOS, similar to how ANOM used parts of it to pass it off as such.
France is an increasingly authoritarian country on the brink of it getting far worse. They're already very strong supporters of EU Chat Control. Their fascist law enforcement is clearly ahead of the game pushing outrageous false claims about open source privacy projects. None of it is substantiated.
iodéOS and /e/OS are based in France. iodéOS and /e/OS make devices dramatically more vulnerable while misleading users about privacy and security. These fake privacy products serve the interest of authoritarians rather than protecting people. /e/OS receives millions of euros in government funding.
Those lag many months to years behind on providing standard Android privacy and security patches. They heavily encourage users to use devices without working disk encryption and important security protections. Their users have their data up for grabs by apps, services and governments who want it.
There's a reason they're going after a legitimate privacy and security project developed outside of their jurisdiction rather than 2 companies based in France within their reach profiting from selling 'privacy' products.
https://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private
Here's that article:
https://archive.is/AhMsj

2025-11-18 23:42:00 UTC

- reply

Release is here now. If you want it early you can use the Alpha channel. We will be having more releases to fix bugs though.

2025-10-20 02:36:08 UTC

Here is my scheduled corpo posting of a collage of software, now Please Buy My Fucking Products
https://blossom.primal.net/4544e4ebbca1c5bdba092d052bff20f72b1eb9dc62ffe0f58b027d0dc43f3f9a.jpg
#nevent1q…l7a0

2025-10-17 02:29:49 UTC

Twitter for you feed is so awful. Even after following accounts the recommendations stink.

2025-10-14 16:03:52 UTC

What I can say for now:
- #GrapheneOS has partnered with a major Android OEM. One of the top ten.
- We aim to have a device by H2 2026, but potentially 2027.
- We have early source access for patches and, soon, major releases through our partner.
- We are aiming to get their next generation flagship devices able to support installing GrapheneOS.
- The device will have the flagship Snapdragon 8 Elite 2 (SM8850) SoC.
- We will continue to support Pixels if they continue to release with support. We will also aim to have Pixel 10 support once Android 16 QPR1 sources are available.
#nevent1q…3p3p

2025-10-11 23:20:22 UTC

Just saying... #GrapheneOS 2025100300:
- add support for force enabling VoLTE, VoNR and 5G for carriers where those aren't supported with the standard configurations
https://grapheneos.org/releases#2025100300
#nevent1q…txld

2025-10-09 15:23:30 UTC

See more about information on how OEMs like Samsung provide patches and our early patching through security preview releases.
#nevent1q…awq2

2025-10-06 18:58:58 UTC

- reply

(made a deletion request on last note for a bad typo)
Patches always had a timed embargo for years, patches still come in a quarterly not monthly schedule. However, this embargo was stretched likely to get OEMs in on releasing patches on time (spoilers: they don't).
We got partner access from a major Android OEM who can provide these patches before their release, since we can just distribute this ourselves, it can be useful to people who want the patches. They're proprietary to the user but not us, we have access to sources and fix conflicts before distributing.
We openly encourage people to compare the update packages and reverse engineer it to figure out changes and make their own open source patches. People should encourage them to stop the embargo and patch faster.

2025-10-04 16:45:46 UTC

Our security preview releases provide early access to Android Security Bulletin patches prior to the official disclosure. Our current security preview releases provide the current revision of the November 2025 and December 2025 patches for the Android Open Source Project. We recommend enabling this.
The only difference between our regular releases and security preview releases are the future Android Security Bulletin patches being applied with any conflicts resolved. The downside of security preview releases is we cannot provide the sources for the patches until the official disclosure date.
The delay for being able to publish the sources is why we're now going through the significant effort of building 2 variants of each release. Our most recent 3 releases have both a regular and security preview variant:
2025092500 and 2025092501
2025092700 and 2025092701
2025100300 and 2025100301
You can enable security preview releases via Settings > System > System update > Receive security preview releases.
Our plan is to keep it off-by-default with a new page added to the Setup Wizard which will have it toggled on as a recommendation. We'll prompt users on existing installs to choose.
We're maintaining the upcoming Android security patches in a private repository where we've resolved the conflicts. Each of our security preview releases is tagged in this private repository. Our plan is to publish what we used once the embargo ends, so it will still be open source, but delayed.
The new security update Android is using provides around 3 months of early access to OEMs with permission to make binary-only releases from the beginning. As far as we know, #GrapheneOS is the first to take advantage of this and ship the patches early. Even the stock Pixel OS isn't doing this yet.
During the initial month, many patches are added or changed. By around the end of the month, the patches are finalized with nothing else being added or changed. Our 2025092500 release was made on the day the December 2025 patches were finalized, but we plan to ship the March 2026 patches earlier.
Previously, Android had monthly security patches with a 1 month embargo not permitting early releases. For GrapheneOS users enabling security preview releases, you'll get patches significantly earlier than before. We'd greatly prefer 3 day embargoes over 3 month embargoes but it's not our decision.
Security preview releases currently increment the build date and build number of the regular release by 1. You can upgrade from 2025100300 to 2025100301 but not vice versa. For now, you can switch back to regular releases without reinstalling such as 2025092701 to 2025100300, but this may change.

2025-10-04 07:38:38 UTC

- reply

CalyxOS doesn't even have the 2025-06-05 patch level and their 3 core devs quit. The project founder, who is the key custodian, was pushed out and updates stopped. He is now involved in trying to create a for-profit company with Louis Rossmann. I'd assume it's as good as dead if there is nothing to replace now.
GrapheneOS is a security/privacy focused OS, we arent promoting it as a political campaigning chip against a big tech company. We support Pixels cause of the security properties it provides.
We're negotiating with a top 10 Android OEM to get their newer devices ready to potentially be supported by GrapheneOS, but we can't say much details yet.
Most devices make using other OSes difficult / impossible, don't provide security updates on time and don't even use a secure element to protect against physical attacks. We aren't taking a LineageOS approach to push mixed functionality versions on every device as possible. People will blame us when they use GrapheneOS on some unsafe end of life device and still get pwned.

2025-10-03 07:33:19 UTC

- reply

(I know it's AI, but answering for the curious)

2025-10-03 07:32:11 UTC

- reply

Current people are paid in XMR or BTC afaik. We have a large reserve of Ethereum from some whale donors.
Lightning I have for myself. For GrapheneOS foundation it is planned, but we need to have a good software choice, the right accounting, etc.

2025-10-03 07:23:59 UTC

- reply

Yes. We'll even pay devs in cryptocurrencies if they ask for it - some already do.

2025-10-03 07:22:36 UTC

This is the same project who claimed to make their app only for Apple platforms for anonymity and numerous inaccurate privacy claims for Android on why they wouldn't support it...
I don't know why they didn't assume Apple would do such a thing, they did it with a similar Hong Kong protest map app years ago.
Apple store which accounts, devices install which apps. They also force apps to use their push notification service.
#nevent1q…x5g2

2025-06-11 11:21:36 UTC

- reply

If they decide to make it even more difficult than it becomes already. We are not the only project hit by this. The porting will be slower as more work to do. But the Port should be doable.
Would have to see what kind of state the Pixel 10 is in, although it is not out yet.

2025-06-11 11:04:42 UTC

- reply

A port to Android 16 is still being developed, it will just take longer. See:
#nevent1q…g5qz