> I feel like GrapheneOS shot itself in the foot, being exclusive to Pixel phones.
Pixels are the only available smartphones meeting our hardware security requirements while permitting us to use the hardware-based security features. Our requirements are very reasonable and listed at https://grapheneos.org/faq#future-devices. Recent Samsung flagships using an Exynos or MediaTek SoC have essentially all the security features on this list on paper. However, Samsung doesn't let us support their devices. Samsung cripples the device if you use another OS, mainly by disallowing using security features. Some of it is permanently disabled even if you go back to the stock OS and lock it again. There's an eFuse they refer to as the warranty bit which they burn when you unlock, crippling the device forever.
The audience using GrapheneOS has become much less technical over time as usability and app compatibility has greatly improved. Installation via the web installer is something many very non-technical people are regularly doing successfully, largely without help. 24/7 real time help with installation is available via our chat rooms. Our overall audience is less technical than you think. The chat rooms attract a more technical subset of the community and isn't really representative.
Pixels have digital USB-C audio output and DisplayPort alternate mode support. They have the start of a proper desktop mode and hardware virtualization support for running applications from other operating systems. In GrapheneOS, that can already be used for GUI applications with speaker, microphone and opt-in GPU acceleration support. Analog 3.5mm audio output isn't something people focused on bleeding edge technology want. Audiophiles never wanted to use low quality DAC in the phone but rather a high quality one connected via USB-C with digital audio output.
> Really not a fan of the hostile attitude towards rooting when it's needed for basic functionality like backups — actual, reliable backups for every app, unlike those provided by the built-in solution.
GrapheneOS has a built-in encrypted backup system which uses the device-to-device mode. That's the mode Google Play services uses on Google Mobile Services devices when you transfer to a new device. It does back up every app, they can't opt-out of it. They can explicitly exclude data from device-to-device backups which is non-portable or shouldn't be used across devices such as a device-specific login token. The previous systems for opting out of backups or excluding files only exclude them from cloud backups now.
Some apps like Signal encrypt their data themselves as an additional layer so no backup system other than the one built into their app is going to back that up and restore it in a useful way. Transferring data encrypted with a hardware keystore key which then can't be read/used by the app wouldn't be helpful. Transferring device-specific login tokens, etc. isn't wanted. The way the standard backup infrastructure is designed in Android is the right approach since Android 12. It does work well. The current backup service we're using is not a great implementation of it but has gotten better. We intend to completely fork it and massively overhaul it at some point. It was originally written by a GrapheneOS user for GrapheneOS but it got largely taken over by others and we don't agree with their approach or choices for it, so we'll be forking it.
Samsung is banned in my household. Separately from what you say, every Samsung anything I ever owned was a piece of shit, starting with a certain DVD player back in 2003 whose firmware crapped out exactly one day after the one year warranty.
> They can explicitly exclude data from device-to-device backups
Curious how many apps abuse that for purposes beyond the original intention? The big/popular apps etc? Ie what will be the real world experience despite this new feature
Android 12 theoretically added it but it didn't fully work yet and apps needed to start targeting Android 12+. Then, the backup app needed to add it which took a long time, so it's fairly recent as in within the past 2 years.
> Curious how many apps abuse that for purposes beyond the original intention? The big/popular apps etc? Ie what will be the real world experience despite this new feature
Many apps use the older system to disable backups or exclude files which only applies to cloud backups now. Most apps don't exclude files from device-to-device backups improperly. Excluding device-specific login tokens, caches, etc. is how it's intended to be used. It annoys people they need to login to apps again after a transfer but that's generally how those apps want their security model to work so there's an entry for each login session and logging out of it only logs it out on 1 device.
Apps can exclude files and define their own backup agent for handling converting to and from a portable format. Chrome does this to backup Android-specific settings, etc. not handled by Chrome's Sync feature. This means non-Chrome Chromium-based browsers largely lacking sync have poor backup support. We plan to address this in Vanadium but haven't decided how we want to approach it yet.
It does work well. People mostly have a good experience with device-to-device transfer with Google Mobile Services devices now. Certain apps like Signal or TOTP apps using the hardware keystore inherently can't be backed up this way. Signal doesn't use it in a sensible way for security and really just seems to have introduced hardware keystore based encryption to prevent using root-based backup systems not taking into account which data should be backed up or not backed up. They don't trust the OS backup infrastructure particularly since OEMs can include sketchy backup services so they don't want that to work either.
Backups are per-profile so you can test restoring most data in a temporary secondary user, just not settings it will only restore when restored in Owner.
Pixels are the only available smartphones meeting our hardware security requirements while permitting us to use the hardware-based security features. Our requirements are very reasonable and listed at https://grapheneos.org/faq#future-devices. Recent Samsung flagships using an Exynos or MediaTek SoC have essentially all the security features on this list on paper. However, Samsung doesn't let us support their devices. Samsung cripples the device if you use another OS, mainly by disallowing using security features. Some of it is permanently disabled even if you go back to the stock OS and lock it again. There's an eFuse they refer to as the warranty bit which they burn when you unlock, crippling the device forever.
The audience using GrapheneOS has become much less technical over time as usability and app compatibility has greatly improved. Installation via the web installer is something many very non-technical people are regularly doing successfully, largely without help. 24/7 real time help with installation is available via our chat rooms. Our overall audience is less technical than you think. The chat rooms attract a more technical subset of the community and isn't really representative.
Pixels have digital USB-C audio output and DisplayPort alternate mode support. They have the start of a proper desktop mode and hardware virtualization support for running applications from other operating systems. In GrapheneOS, that can already be used for GUI applications with speaker, microphone and opt-in GPU acceleration support. Analog 3.5mm audio output isn't something people focused on bleeding edge technology want. Audiophiles never wanted to use low quality DAC in the phone but rather a high quality one connected via USB-C with digital audio output.
> Really not a fan of the hostile attitude towards rooting when it's needed for basic functionality like backups — actual, reliable backups for every app, unlike those provided by the built-in solution.
GrapheneOS has a built-in encrypted backup system which uses the device-to-device mode. That's the mode Google Play services uses on Google Mobile Services devices when you transfer to a new device. It does back up every app, they can't opt-out of it. They can explicitly exclude data from device-to-device backups which is non-portable or shouldn't be used across devices such as a device-specific login token. The previous systems for opting out of backups or excluding files only exclude them from cloud backups now.
Some apps like Signal encrypt their data themselves as an additional layer so no backup system other than the one built into their app is going to back that up and restore it in a useful way. Transferring data encrypted with a hardware keystore key which then can't be read/used by the app wouldn't be helpful. Transferring device-specific login tokens, etc. isn't wanted. The way the standard backup infrastructure is designed in Android is the right approach since Android 12. It does work well. The current backup service we're using is not a great implementation of it but has gotten better. We intend to completely fork it and massively overhaul it at some point. It was originally written by a GrapheneOS user for GrapheneOS but it got largely taken over by others and we don't agree with their approach or choices for it, so we'll be forking it.