Corrections/elaborations on some points

Hi everyone. GrapheneOS community manager here. We reached out to the author with some comments/corrections and we were encouraged to post them as a comment, as there seems to be a policy to not editing the article after publication in most cases.

One is about the history of the project. The open source project has been the same from the beginning. It started as a solo project, was known as CopperheadOS for a time, then later was renamed to GrapheneOS. What is now CopperheadOS is a fork. See the following links:

-https://github.com/GrapheneOS/platform_manifest/forks?inc...
-https://github.com/GrapheneOS/platform_bionic/forks?inclu...
-https://github.com/GrapheneOS-Archive/legacy_bugtracker/i...

The above links show forks of our repositories dating back to 2016, which shows that GrapheneOS is the original project, not some spin-off that started later. The third link points to our legacy bugtracker, prior to the rename.

Regarding the failed cli install, we're not sure what happened there. Flashing that way works fine. We are aware that some issues can arise in certain cases, like when using OS-provided Fastboot. If you were to try again, we'd suggest making sure you are using the Fastboot mentioned in our install instructions to avoid these sorts of issues.

We usually suggest people flash GrapheneOS using the web installer because it's easier for most people. Also, as you found, the cli install is robust but uses more OS-provided functionality so more issues can occur due to bugs in the OS outside of our control especially if using an OS package for fastboot. We're glad you were able to install GrapheneOS easily with the web installer, though.

Regarding Play Integrity, it should be noted that there's nothing we can do if apps check for device or strong integrity since Play Integrity responses are signed by Google. The issue isn't one of whether we've implemented something or not. We do have a guide on how apps can add support for GrapheneOS using hardware attestation https://grapheneos.org/articles/attestation-compatibility..., which some apps have done, including Yuh and Swissquote.

Regarding the network permission, users can install apps without the network permission granted by unchecking the network permission box when installing the app.

And for the sensors permission, there is a toggle in Settings where apps can have the sensors permission not granted by default.

In the section about fingerprint unlocks and PINs are mentioned, it is worth explaining that the duress feature doesn't brick the device, it wipes keys from the keystore (among other things). After duress is triggered, the device will say it's corrupt, and from there it can be factory reset via Recovery.

It is mentioned that after 5 unsuccessful fingerprint attempts, you're locked out for 30 minutes. On GrapheneOS, it is permanent until you input your primary unlock method again. On the stock OS, it locks you out after 5 attempts for a time period and has permanent lockout until you input your primary unlock method again after 20 attempts.

A related feature is our 2nd factor fingerprint unlock feature. When using this feature, users can set a very strong alphanumeric password for the primary unlock method and use their enrolled fingerprint + a PIN for added security.

The best way to see what the project is prioritizing is by checking the issue tracker. Planned features have priority labels.

Development guidelines can be found in the build page that is linked there, under this section: https://grapheneos.org/build#development-guidelines, and if someone wanted to help contribute, they can express interest in our development room, or they can comment on an issue they are interested in contributing to.

The project has and is subject to attacks over the years, so most contributors prefer to keep their heads down and maintain anonymity. This way they are less likely to be targeted. We really care about protecting our project members, so we're taking the appropriate measures to do that.

This may be why from the outside it looks like Daniel Micay is still the driving force of the project, which makes sense because he's the founder and has always been the public face for the project. Nowadays, other developers do the majority of development work, including reviews. Nonetheless, his expertise remains invaluable to the project.

Some other thoughts:

- On the stock OS, Android Auto is a privileged app. On GrapheneOS it's sandboxed and only necessary permissions are granted if users toggle them on. Still more access than other apps, but configurable and better than on other OSes.
- App compatibility is a priority for the project and we are always working on maintaining/improving that.
- From our perspective, running an invasive app on GrapheneOS is much better than running it on a less secure, less private OS that doesn't provide the same amount of control.
- It's important to note that if hardening features break apps, there are toggles that can be used to make apps work again.
- A correction regarding the timeline for Android 16: the initial upstream release was on June 10th and our initial production release was on June 30. It usually takes us ~2 days, but took longer this time due to upstream dropping some device repositories, so porting took longer than usual. We did backport driver/firmware security patches to Android 15 before finalizing the Android 16 port.
- At the beginning of the article, it was said that GrapheneOS is an "Android rebuild". It would be more accurate to call it a fork of the Android Open Source Project (AOSP).