<unnamed>

Public Key

npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y

Profile Code

nprofile1qqstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgsppamhxue69uhkummnw3ezumt0d5q3kamnwvaz7tmedehhxarj9eukzetv9eshgtmkd93hgmmjfeqdzy

Publishing to

nostr.mom

ynostr.yael.at/victor

Last Notes

2026-09-13 15:53:01 UTC

- reply

Not intentional. Sent the above to team to see if it can be recreated. Some VPN apps may not be playing well to the tighter leak protection. I assume User Profiles are fine?

2026-09-12 11:29:49 UTC

- reply

You can see the individual pull requests for how many people have worked on the app and that there's people discussing what to do. There's people involved in every step or the development testing for quality. Here's the largest:
https://github.com/GrapheneOS/Messaging/pull/109
The leading apps dev has around a decade and a half of experience in developing on the Android platform alone. His contributions so far have been incredible.
We have a broad access to many LLMs for security testing, including cyber-enabled models for dual-use. It's not actually writing the code of GrapheneOS much. It would be poor to willingly dumb ourselves down when companies such as Cellebrite are devoting teams to creating AI tooling to reverse engineer mobile devices to try and exploit them.

2026-09-11 21:58:20 UTC

- reply

Was somehow an existing feature in the AOSP messaging app already.

2026-09-07 18:16:52 UTC

- reply

^ You can use a browser *designed* for going against it like Brave, but you'll find one of these tests still continue to work against it. Even the Tor Browser on Mobile does and you have to wipe the browser data / state each time for all of the browsers or timing out a service until they forget about you

2026-09-06 19:41:07 UTC

We're well into the process of converting the Messaging app included in #GrapheneOS into a modern app. We'll be making a new release later today with a completely overhauled user interface written in Android Compose. We've made a massive amount of other improvements and bug fixes beyond that too.
In the longer term, we plan to add support for RCS including support for the standard end-to-end encryption (E2EE) via Messaging Layer Security (MLS). Currently, RCS including E2EE is available on GrapheneOS via Google Messages. We want to avoid the need to use Google Messages for RCS eventually.
RCS on Android is currently implemented with code across the OS, Google Messages and Google Play services. Our plan is to start by making an equivalent to the portion in Google Messages. It would initially require sandboxed Google Play for RCS activation, etc. but we plan to implement that too..
RCS isn't an open platform in practice. It isn't even as open as SMS/MMS. It heavily depends on proprietary Google and carrier infrastructure in practice. We can start by replicating Google's approach and then we can work on only using carrier services for carriers where it's actually supported.
We're also going to be overhauling or fully replacing the rest of the AOSP apps in the near future. AOSP Gallery is incredibly outdated and is being entirely replaced. AOSP Keyboard may be similar. We recently hired a bunch of new people and will be hiring more so our progress will be accelerating.
In the past, our focus was nearly entirely on the base OS rather than bundled apps with alternatives available. We've heavily ramped up the resources we're investing into the bundled apps. We'll also be scaling up our work on the base OS too. More donations will enable us to hire even more people.

2026-08-30 22:56:47 UTC

- reply

See my previous posts on here

2026-08-29 10:56:03 UTC

- reply

Not without some weird hacky method I don't know about. It's a developer feature so you can consider it incomplete.

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-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: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-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-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.