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.
GrapheneOS wasn't going to be affected anyway and there's nothing for the GrapheneOS developers to change. The developer verification thing will be done by proprietary Google apps. Those apps cannot get the necessary permissions to block app installs or disable apps.
GrapheneOS won't be affected. The developer verification thing will be handled by another app and won't be part of the OS. That app won't have permission to block app installs or anything like that.
GrapheneOS isn't dying. There's an OEM partnership in the works and they'll release devices with support for GrapheneOS in a year or two. GrapheneOS still provides updates and while the changes have made some things harder, the project is still going strong.
I said "most users". There are some who are still experiencing issues, which is being looked into. Other people have had issues that were fixed by clearing the storage for Google Play, Google Play Services, Google Messages, then granting all necessary permissions before launching Google Messages again.
It's my understanding that the changes that were made didn't make things more or less proprietary. Some drivers are still open source, others are still closed source. The device trees mostly have other things in them like configuration files and stuff like that.
The way Google will block apps with unverified developers won't work on GrapheneOS. The change won't be part of AOSP. On the stock OS, the functionality will be handled by another Google app that has privileged access. GrapheneOS won't be affected directly.
Google has already shared how apps' developers will be verified. They're adding another app that will have access to block installing apps or disable them. That won't work on GrapheneOS because 1. the app won't be installed and 2. the app won't have that kind of privileged access.
It's my understanding that RCS was fixed for most users after this update: https://grapheneos.org/releases#2025092700. You may need to grant permissions to Google Play Services first, then clear Google Messages' storage, grant permissions to Google Messages, then try setting it up again.
Well, the fact is it is impossible to target someone with a modified update. The update client sends no IDs to the server, it just fetches static files and determines whether it needs to update or not. The server only has static files.
thet could, in theory, make a single OTA that everybody gets, but checks for a specific IMEI or other device ID and only there enables some malicious payload.
That would be very obvious in the code. And how would devices be targeted if GrapheneOS project members don't know the unique IDs because they're not sent in the first place? There are also community members who build GrapheneOS on their own and check if the builds match because GrapheneOS builds are reproducible. It just isn't possible. But even if people don't believe all of that, they can still disable the updater app and sideload updates manually. Instructions are on the website.
That's because they're the only ones that meet the project's requirements at the moment, but that may soon change soon. Maybe you've seen the news that the project is in talks with an OEM for them to meet the requirements and have official support for GrapheneOS for some of the existing devices.
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.
GrapheneOS wasn't going to be affected anyway and there's nothing for the GrapheneOS developers to change. The developer verification thing will be done by proprietary Google apps. Those apps cannot get the necessary permissions to block app installs or disable apps.
GrapheneOS won't be affected. The developer verification thing will be handled by another app and won't be part of the OS. That app won't have permission to block app installs or anything like that.
GrapheneOS isn't dying. There's an OEM partnership in the works and they'll release devices with support for GrapheneOS in a year or two. GrapheneOS still provides updates and while the changes have made some things harder, the project is still going strong.
GrapheneOS will be fine without F-Droid.
I said "most users". There are some who are still experiencing issues, which is being looked into. Other people have had issues that were fixed by clearing the storage for Google Play, Google Play Services, Google Messages, then granting all necessary permissions before launching Google Messages again.
It's my understanding that the changes that were made didn't make things more or less proprietary. Some drivers are still open source, others are still closed source. The device trees mostly have other things in them like configuration files and stuff like that.
It just won't work on GrapheneOS. Not sure if disabling it will work on the stock OS. We will have to wait and see on that one.
The way Google will block apps with unverified developers won't work on GrapheneOS. The change won't be part of AOSP. On the stock OS, the functionality will be handled by another Google app that has privileged access. GrapheneOS won't be affected directly.
Just check the project's X account. The OEM partnership is mentioned very regularly.
Google has already shared how apps' developers will be verified. They're adding another app that will have access to block installing apps or disable them. That won't work on GrapheneOS because 1. the app won't be installed and 2. the app won't have that kind of privileged access.
It's my understanding that RCS was fixed for most users after this update: https://grapheneos.org/releases#2025092700. You may need to grant permissions to Google Play Services first, then clear Google Messages' storage, grant permissions to Google Messages, then try setting it up again.
At this point GrapheneOS is big enough that there are people who do pay attention to changes and forks that would notice as well.
Well, the fact is it is impossible to target someone with a modified update. The update client sends no IDs to the server, it just fetches static files and determines whether it needs to update or not. The server only has static files.
That would be very obvious in the code. And how would devices be targeted if GrapheneOS project members don't know the unique IDs because they're not sent in the first place? There are also community members who build GrapheneOS on their own and check if the builds match because GrapheneOS builds are reproducible. It just isn't possible. But even if people don't believe all of that, they can still disable the updater app and sideload updates manually. Instructions are on the website.
That's because they're the only ones that meet the project's requirements at the moment, but that may soon change soon. Maybe you've seen the news that the project is in talks with an OEM for them to meet the requirements and have official support for GrapheneOS for some of the existing devices.