>I really wanted to like Graphene, but it feels more locked down than stock android. The primary reason I want a custom OS in the first place is that I want to control the device I own.

What specific ways do you feel are "more locked down" than stock? It's not recommended, but you can install magisk + root if you really wanted to. It won't try to prevent you.

>Graphene is just taking control of my phone from Google and giving it to whoever runs Graphene. I don't get any say in how my phone works.

That's fine. The homepage of grapheneos says:

"The private and secure mobile operating system with Android app compatibility"

Surely you must understand that "security" and "giving users a say in how their phone works" are diametrically opposed? A phone can't be secure if its sandbox can be bypassed in one tap by the user. You might have a lot of say in how your linux system works, but don't kid yourself into thinking it's secure. It's only one `bash -c "$(curl -fsSL http://...` from getting pwned.

> Surely you must understand that "security" and "giving users a say in how their phone works" are diametrically opposed?

Absolutely not.

> A phone can't be secure if its sandbox can be bypassed in one tap by the user. You might have a lot of say in how your linux system works, but don't kid yourself into thinking it's secure. It's only one `bash -c "$(curl -fsSL http://...` from getting pwned.

In both cases, yes, a user may choose to bypass a security measure. In most threat models, that's fine. If malware needs me to give it permission to compromise the system, I consider that a secure system.

> Surely you must understand that "security" and "giving users a say in how their phone works" are diametrically opposed?

Absolutely not. With that logic, Google shouldn't allow people a say in what ROM it runs but I think the people in this thread are rather happy with having such choices

> "security" and "giving users a say in how their phone works" are diametrically opposed

Try putting that sentence prominently on the front page of the GrapheneOS website and watch the monthly download count rapidly drop. It would not be out of place for an Apple press release, but it would be out of place there.

I think the Graphene people sometimes forget that the vast majority of their users are nerds who aren't being targeted by APTs, don't want to be locked out of their own device, and really just want a trustworthy Google-free OS on their phone. They also probably use Linux on their computers and yet haven't been hacked by "fake sudo" or "evil maid" attacks and likely never will be.

> It's not recommended, but you can install magisk + root if you really wanted to.

Apps will then either detect that you're rooted, or use AOSP attestation APIs to cryptographically verify that you aren't using a known-good custom ROM, and block your access to basic features of modern society such as mobile banking. This isn't Graphene's fault, but it should be noted that you will start losing out on things as soon as you start customizing or rooting the OS. So it does matter what upstream does to some extent.

FWIW I don't agree with the OP, just replying to your comment in particular.

> Try putting that sentence prominently on the front page of the GrapheneOS website and watch the monthly download count rapidly drop. It would not be out of place for an Apple press release, but it would be out of place there.

We don't reduce the functionality or configuration of AOSP.

> I think the Graphene people sometimes forget that the vast majority of their users are nerds who aren't being targeted by APTs

The overall audience using it is not super technical. The community of people active in the chat rooms on Matrix and Discord really doesn't reflect the overall userbase. There are around 300k people using it, who largely went out of the way to purchase a phone for it and then installed it via the web installer. Many people also purchase devices with it preinstalled.

It's easy to use and we're focused on making it easier including filling in gaps like the recently added network location support which will be added to the initial setup wizard.

We also protect against a lot more than sophisticated targeted attacks against someone.

> don't want to be locked out of their own device, and really just want a trustworthy Google-free OS on their phone.

GrapheneOS exists to provide a high level of privacy and security while maintaining usability and app compatibility. It's working towards being as usable as the stock Pixel OS. It's meant to be an OS for everyone, we just don't have unlimited resources to quickly build most of the things we want. It has never been aimed at power users tinkering with and customizing their device. The level of functionality and usability we want to provide is the stock Pixel OS experience. Features unrelated to privacy or security which are not present in the stock Pixel OS are mostly out of scope.

> They also probably use Linux on their computers and yet haven't been hacked by "fake sudo" or "evil maid" attacks and likely never will be.

Software being open source doesn't mean it's trustworthy or privacy respecting. Running everything without basics like a strong app sandbox and permission model isn't a good idea on a desktop either. Linux doesn't imply not having a strong application security model.

Supporting and normalizing applications depending on having incredibly invasive access where they can access all of the user's sensitive data, etc. is the opposite of what we want to do. We don't see apps being able to request more invasive permissions and refusing to work without them as user control. User control is being able to avoid that without the app knowing. Giving root access to a huge portion of the OS and to apps is the opposite of what we're building. You seem to want GrapheneOS to be something it's not for an audience that it's not targeting. We never said GrapheneOS is for power users who want to have a bunch of customization and to grant more invasive access to apps.

GrapheneOS supports hardware-based virtualization across all the supported devices and that's the way people will be able to more freely do things like software development without compromising the security of the base OS.

> Apps will then either detect that you're rooted, or use AOSP attestation APIs to cryptographically verify that you aren't using a known-good custom ROM, and block your access to basic features of modern society such as mobile banking. This isn't Graphene's fault, but it should be noted that you will start losing out on things as soon as you start customizing or rooting the OS. So it does matter what upstream does to some extent.

Those apps wouldn't be willing to support GrapheneOS if we didn't maintain the standard security model. We're already going to be pushing the limits of what some apps will tolerate via our alternatives to permissions, etc. but we don't plan to eliminate parts of the security model. At the moment, nearly every app using the Play Integrity API would be willing to support GrapheneOS if they understood what it was and that they could verify it. It's an issue with lack of knowledge and unwillingness to do extra work for it rather than any apps actually wanting to ban GrapheneOS. It's something which can be addressed but it will get worse before it gets better as apps adopt the Play Integrity API. Growing the userbase by an order of magnitude or more will help solve this. Apps using the Play Integrity API are already feeling increasing pressure to permit using it and several have done so recently.

Thanks for your thought-provoking response. I agree with most of it.

The vibe I generally get from Graphene users is that they feel that they are taking control over their device by installing Graphene onto it (which is almost always a manual process, at least for now). I probably exaggerated when I said the vast majority of users care deeply about this, but I think it's still a major selling point of Graphene for a lot of people.

And yes, I do agree that sandboxing actually provides more control to the user, not less! I'd just hate to see Graphene become more like iOS over time and start intentionally omitting features that would otherwise empower the user, for security's sake. If "security" and "giving users a say in how their phone works" really are diametrically opposed, and user freedom isn't a concern, then it would probably make sense to start gutting out stuff like developer mode, adb, and sideloading for the user's own safety. But the project's track record has been pretty good so far from what I can tell, and I don't think this will happen.

In general, we don't remove functionality. An exception is if something is explicitly insecure and has no reasonable use case. We removed support for instant apps, booting a Google signed GSI, adding new users while locked and pattern lock.

In very rare cases, someone complains about the removal of pattern lock, but it's a terrible feature and shouldn't be included in modern Android. It's a much worse variant of a PIN which gives people a false sense of security and encourages choosing an insecure lock method. We also didn't want to support it for our duress PIN/password feature or our upcoming random PIN/password generation feature. It's not really suited to either of those things. Pattern lock is genuinely an awful feature and shouldn't be included in modern Android, but they don't want to upset people by removing it. Extremely few people care that we remove it, and we've helped them by getting them to use a PIN instead especially if they use a proper random PIN.

> developer mode, adb, and sideloading

These things can be disabled with a device management app already, if what you mean by sideloading is installing apps via an APK or arbitrary app store. Sideloading an OS update to recovery has all of the usual signature verification and downgrade protection.