I feel like GrapheneOS shot itself in the foot, being exclusive to Pixel phones. Pixel phones were great, in the past, but now they're mediocre offerings for their price range and the removal of the 3.5mm jack pushed many of the more techy users away — GrapheneOS's target audience.
Not sure if I'd use GrapheneOS even if it was available on other devices though. 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, in my opinion, can only exist the way they do because of their exclusive support for Pixel devices. It allows them to provide a uniquely high quality ROM with proper support guarantees.
Compare that to other custom ROMs, where you typically depend on volunteers maintaining the various devices. Sometimes people decide to step down, and suddenly find your device unsupported. This happened to me with LineageOS/CyanogenMod.
My understanding is also that the OEM ROMs of Pixel devices are closer to AOSP than those of other vendors like Samsung. This simplifies the maintenance of the ROMs, and enables the project to develop meaningful features instead.
See https://news.ycombinator.com/item?id=43670303 for a detailed explanation. If we were going to support another device, it would need to meet the security requirements AND provide proper production quality non-stock OS support with a strong commitment to keeping it properly working.
We can't safely use a device where they might patch out support for what we rely on. As an example, OnePlus patched out support for alternate OS verified boot due to serious security vulnerabilities with how they'd implemented it. Operating systems relying on it would no longer be able to update the firmware, leaving them insecure, but yet the verified boot never worked properly anyway so it ended up worse than them not trying in the first place.
Realistically, what we expect is that Pixels are the only devices we're not involved in making which we'll be able to support for the foreseeable future. To support other devices, we need a partnership with a competent OEM like Samsung. We can raise money to pay the usual licensing fees for platforms and then work with them where we have paid support so they aren't going to break things for us, drop update support unexpectedly, etc.
Thank you for working on GOS. It is one of the few, if not only, OS that makes mobile devices usable for me.
> To support other devices, we need a partnership with a competent OEM like Samsung.
How realistic would it be to have an official Graphene phone? Could you partner with an open-source friendly company like Purism or Framework to design and manufacture the hardware to your specifications? That would be the ultimate mobile device for tech and privacy nerds, for which I'm sure many would be willing to pay a premium over mass manufactured devices.
As much as I trust your vetting of Google devices, there's a strong incongruity between the mission of a trillion-dollar adtech company and yours that I just can't reconcile.
Samsung is the main company we'd really want to work with. They already provide devices meeting nearly all our requirements, they just don't provide us a way to support them yet. If they started doing that, we could support some of their devices. Better yet, if they actively worked with us, we could help them make major security improvements and there could be first class GrapheneOS support. We can raise money for it rather than having to convince them that it makes business sense to fill a product niche they aren't currently providing.
> As much as I trust your vetting of Google devices, there's a strong incongruity between the mission of a trillion-dollar adtech company and yours that I just can't reconcile.
Apple and Google provide a high level of security for their mobile devices. Other OEMs aren't on the same level. Samsung is the only one that's even remotely close. We'd love to work with Samsung but wanting to do it doesn't mean they will work with us. We could potentially pay them to build a device for us if we raised enough money in advance. We choose devices based on their security and other properties along with the actual record of the company making it. Corporations are amoral profit seeking entities in general. That's not something specific to Google.
> Could you partner with an open-source friendly company like Purism or Framework to design and manufacture the hardware to your specifications?
Framework doesn't currently build devices close to meeting our requirements but is not anti-security or misleading people like Purism. We wouldn't have any issue working with them, we just don't really expect them to start building what we need any time soon.
Purism has extremely anti-security practices and makes extraordinarily insecure devices incredibly far from meeting our requirements. They purposely choose low security components and don't provide important updates. They even block providing the updates from the OS. We'd much rather support a low-end Motorola phone with only 2-3 years of support than a Purism device because they're so much less secure than mainstream hardware. Purism has 0 days of update support for their products in the sense that we require.
We don't consider Purism to be a privacy friendly company due to the atrocious security of their products and services. The software they use on top is also far less private and secure than the Android Open Source Project. It's largely the complete opposite of GrapheneOS. They also do a lot of false marketing that's directly harmful to us such as their false claims about cellular radios. In reality, their device has a much less secure cellular radio with far more attack surface exposed from the OS than an iPhone. It's less isolated, not more isolated, and yet they've convinced many people otherwise with their marketing and done harm to the whole space with the misconception people now have. The same applies in other areas.
If we partnered with Samsung, people would know they're going to get a good product and that the company making the hardware would still be around providing support years later. If we instead partnered with a company known for not shipping people what they ordered and not providing what was claimed in the promotional material, that would be very hard for people to trust. Our community would be shocked and incredibly disappointed if we did that.
> 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.
I would say the exact opposite. The latest Pixel phones are "pretty much iPhones" in terms of hardware (and looks too). It seems smartphones have arrived at an agreed upon form factor and design in general.
What I noticed though is that Google often tries to upsell based on software features alone. For example, there is really no point in buying a Pixel 9 Pro instead of a base Pixel 9 as the hardware is practically the same except certain things. But Google markets the Pro model with more software based AI features. When installing GOS this really doesn't make a difference so one can always opt for the more inexpensive models.
Only providing the Pro mode in Pixel Camera on the Pro devices is one of the only ways they're artificially segmenting them via software. The AI model differences are largely based on real differences in available memory and that doesn't have much impact on available OS features. That matters to LLM enthusiasts but probably isn't a selling point for most people at this point.
The base devices are better value but the Pro devices do mainly differentiate based on hardware. Better display, addition of the 5x telephoto camera, better front camera and more memory are the main selling points. Pixel 9a is similarly a downgrade for the screen, cameras, memory, wireless charging speed and cellular radio (back to a variant of the 7th/8th gen Pixel radio). Pixel 9a has very good value but the cellular radio downgrade is a big one which people may care about more than they realize due to how it impacts battery life when using 5G.
> I feel like GrapheneOS shot itself in the foot, being exclusive to Pixel phones. Pixel phones were great, in the past, but now they're mediocre
Interesting that someone would say this. I’ve had several Nexus and Pixel phones in the past (last one was a Pixel 2) and they were all pretty bad in terms of hardware and the support from google was non existent. I only bought for them for the software… which wasn’t great either. They have always been mediocre phones, to put it mildly.
Huh? Pixels haven't had 3.5 jacks since Pixel 2 in 2017. wdym?
GrapheneOS is exclusive to Pixels because no other device has the same security features like bootloader relocking.
See https://grapheneos.org/faq#future-devices for the official list of security requirements. We've gone out of the way to keep them very reasonable to permit non-Pixel devices such as only requiring 5 years of updates rather than 7. We also don't require pKVM for virtualization to permit SoC vendors using their own proprietary hypervisors. It's a very reasonable list of requirements. Samsung has devices like their current generation flagship tablets meeting nearly all the security requirements. The blocker is Samsung not permitting another OS to properly support their devices including crippling security for them. The blocker isn't that there aren't devices providing the security features we need but that those devices don't allow us to support them. We aren't interested in low security devices like the Fairphone without even the basic security features included and with significant delays even for the security patch backports from the beginning.
If Samsung had allowed a non-stock OS to properly support devices like Samsung Galaxy Tab S10+ and Samsung Galaxy Tab S10 Ultra, we'd have been very interested. They did not allow it. They permanently cripple their devices if you unlock them. People should criticize Samsung for this rather than criticizing us for something we don't control. Companies like Fairphone are not realistically capable of building what we need due to lack of resources so there's little point in people bothering them about it.
2017? Maybe I'm getting old... Still, the point stands — the lack of a 3.5mm jack drives techy users away, and the Pixels just aren't very good for their price range today.
> GrapheneOS is exclusive to Pixels because no other device has the same security features like bootloader relocking.
Sure, because they picked a set of features exclusive to Pixels. Nothing is stopping them from being more permissive about the security features they require.
I do understand why they chose to stick to Pixels; I think it was a mistake nonetheless.
> Sure, because they picked a set of features exclusive to Pixels.
No, we don't do that. The security requirements are not exclusive to Pixels. Samsung flagships with an Exynos or MediaTek SoC have nearly every feature listed at https://grapheneos.org/faq#future-devices. They don't quite have proper updates and quality of implementation is an issue. If Samsung allowed us to properly support their devices, we would likely be supported a few Samsung devices. There are no other devices with a reasonable level of security combined with support for using another OS available for us to support. We've also made sure to keep the required support time at 5 years instead of 7 to allow for non-Pixel devices. Snapdragon still not supporting hardware memory tagging at this point is embarrassing for Qualcomm and it should be expected that it's supported at this point, especially since even MediaTek has it now. The OEM making that and other security features available is also needed.
> Nothing is stopping them from being more permissive about the security features they require.
It would not have our core feature set and comparable protections. It would not protect users from real world adversaries like Cellebrite and NSO in the way that it does right now. Our security requirements exist for a reason and major parts of GrapheneOS are built around hardware-based security features. If the device doesn't have hardware memory tagging, then how can we provide one of our main flagship features?
> I do understand why they chose to stick to Pixels; I think it was a mistake nonetheless.
It's strange that you keep mentioning this in the past tense. We support Pixels because they're currently the only devices providing our security requirements while permitting us to use them. If Samsung started permitting us to support their devices, we could support certain Samsung devices. There aren't currently any other devices meeting our requirements, but there isn't a reason to think that there won't be in the future. Our list of security requirements is a very reasonable list of industry standard features. Android OEMs largely aren't trying to provide reasonably secure devices and are not trying to compete with Pixels and iPhones on security. Samsung is an exception, but quality of implementation isn't as high and they're ruining the end result with the massive non-security changes they make that's massively expanding attack surface and making updates much harder.
> Sure, because they picked a set of features exclusive to Pixels. Nothing is stopping them from being more permissive about the security features they require.
You're not the target audience for this OS. Strong security guarantees require vertical integration.
It's not even a feature, but standard android bootloader will do this much. Vendors deliberately remove such features, if not disable phone unlocking outright[0].
Qualcomm offers the feature as an option to every OEM using Snapdragon. Our understanding is that it costs extra money to license, like many of their features including security features. Snapdragon is immensely expensive for a modern flagship SoC with long term support and the full feature set including security features.
OnePlus supported it on several devices but then removed it in updates fixing serious security vulnerabilities. Their non-stock verified boot support was insecure and instead of fixing it they removed it. It's likely there wasn't a clear or possible way to fix it due having a poor implementation which never worked properly. Fairphone 4 had a completely insecure implementation of verified boot trusting publicly available AOSP test keys. Having support for it really doesn't mean it works or will even keep appearing to work in future updates.
It's also just one feature. Our overall hardware security requirements are listed at https://grapheneos.org/faq#future-devices. People focus too much on relocking the device but we require a lot more than that. There are non-Pixel devices with essentially all the features we require such as the Samsung Galaxy S10+ and S10 Ultra but they don't allow using another OS without losing the security features. The updates are also still not what we expect, but if Samsung actually make it possible to support their devices we could accept some compromises. On the other hand, supporting far less secure devices missing things we consider hard requirements like memory tagging needed to provide our core feature set doesn't interest us.
The oneplus3 cannot be relocked as it wrongly trusts test-keys. It also has public EDL firehose files available allowing anyone to flash it arbitrarily even when locked or further dump ram or userdata.
I'm with GP on this one. I am also on a phone without 3.5 mm jack and have wireless headphones because of that. It sucks. With wired (3.5) headphones thing just worked. With wireless, I have to think about headphones' battery level. I can charge from an independent source, but that is a problem when I'm moving (but yes, powerbank would work). I can also use wired headphones through USB-C, but this is a problem in a different setting - the phone better be full or I won't be able to charge it at the same time because the port is used.
I'm sure there are valid technical reasons for removing the 3.5 jack, and I have adapted my headphones to the new situation, but man do I hate it.
I would pay you (almost) anything to find me a pair that fits. It has taken me a long time to finally find a pair that I can use not only walking but also running.
Then what to do when the battery dies? They only a last a couple of years. I can replace my phone pretty easily, but how can I find another pair of earplugs? That's a process I don't want to go through again. The human-device interfaces should just work.
The only other solution I have found is a USB-C-to-3.5mm dongle but then the phone doesn't fit comfortably in my pocket anymore, and it's very inconvenient when running.
> The only other solution I have found is a USB-C-to-3.5mm dongle but then the phone doesn't fit comfortably in my pocket anymore, and it's very inconvenient when running.
Get USB-C headphones rather than a DAC so that the DAC is in the headphones. There are high quality ones including earbuds.
Not sure if I'd use GrapheneOS even if it was available on other devices though. 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.