Data isn't overwritten like that. The keys are deleted so the encrypted data is inaccessible.

And if people want a decoy, they can use a profile. I'm not sure why GrapheneOS has to add a feature for something that can already be done.

You cut out 90% of the security issues when you replace it with Lineage.

That's not true.

The duress PIN/password feature as is makes getting data off the device impossible. The decoy profile approach means handing an unlocked device over to someone with access to forensics software. They can see the other profiles, logs if they're still around, and other general data. If the profile's session was ended, they'd need to unlock it to access the data, but since they're already logged in there's a much bigger attack surface. Maybe it would make it easier for them to exploit the secure element and bypass throttling, for example. It's better to not unlock the device at all, even better if it had rebooted.

It's more complicated than that. Forensics software can get related data easy enough. Logs and other data will still be there until a reboot. If the device is rebooted, there is the hash that makes it clear it's GrapheneOS + a huge hard to miss triangle grabbing attention. Developer options is only available in the owner profile, so using another profile for that would be obvious too.

GOS devs don’t let anyone incorporate their code.

False

They also refuse to provide basic functionality like inverted navbar buttons.

This is supported in AOSP now.

Because they’re diva devs.

This doesn't seem like a mature thing to say just because you want to flip buttons and are annoyed that the privacy and security-focused project didn't add a feature to flip buttons.

That's very false. There are other OSes with GrapheneOS code or forks of GrapheneOS.

The way profiles work right now makes a decoy profile not work properly. GrapheneOS developers don't add features that can be defeated by basic training.

Last I heard, the way the developers want to do it is add an early boot passphrase and then a decoy setup would be possible without leaving a way for attackers to be able to know for sure that a decoy feature was used.

You don't need to reinstall as many people have suggested. There are instructions on the website for this https://grapheneos.org/faq#preinstalled-devices. Basically, verify the installation and do a factory reset from Recovery.

I may be misunderstanding, but which push? The open source project was started in 2014 and was named GrapheneOS sometime in 2019. You may be seeing more about GrapheneOS because of the Motorola partnership, CalyxOS dying/being on hiatus (so many of their users switched to GrapheneOS), and recent news pushing people to use more private OSes.

(GrapheneOS project member here) We are not aware of any organization or software that can hack into GrapheneOS.

It would be harder for a few reasons. In this case, it would be harder because the baseband is isolated on supported devices so hacking remotely would be harder. GrapheneOS also ports to new Android versions very quickly, which means security patches are applied that other devices/OSes are always far behind on. We also have security preview releases so even more patches are applied for users who enable that. And, finally, there are lots of other hardening things that have been done protect against unknown vulnerabilities. See the website for info about that, but basically the hardened memory allocator + enabling MTE for 8th generation devices and later will catch the most common classes of bugs.

Fair enough. I said "huge" because I guess some people care a lot. I personally don't and have been on security preview releases since they started releasing them.

Not exactly. GrapheneOS has an OEM partner and has early access to AOSP changes that aren't public. A huge downside to that is that security preview releases can't be open source until after Google makes the code public.