A huge problem with Graphene is the incredibly small number of supported devices. We need something that isn't as reliant on specific hardware, and while that would mean some security features are not supported it would still be better than most other options by far.
Unfortunately, Google's Pixel devices have been the only ones with hardware that meets all of the project's stringent security requirements, including a secure hardware enclave and multiyear commitments from the vendor to firmware security updates (I think 7 years of updates now for the newest Pixels). Those seem to be the big two things that no other Android vendor achieves together.
The GrapheneOS devs are serious about security, probably more focused on it than 99% of end users. That they manage to release a project with the high level of usability that GrapheneOS achieves is impressive, even if it isn't as convenient to the end user as stock Android. Ultimately, nothing will ever be as convenient to the end user as stock Android or iOS, but that's not the point of the project.
> Unfortunately, Google's Pixel devices have been the only ones with hardware that meets all of the project's stringent security requirements, including a secure hardware enclave
That's my point, though. The projects security requirements don't need to be that stringent. By all means, take advantage of the hardware security on devices that offer it like pixel, but even on devices without that hardware security it would still be the most secure Android based OS available, and orders of magnitudes more people would benefit from having access to that.
> The projects security requirements don't need to be that stringent.
GrapheneOS security requirements very much do need to be that stringent. That's the whole reason for the project. Have something that is maximally secure within the most aggressive limits of what is possible today.
It targets end users who either have an acute threat model (e.g. journalists, dissidents) or are willing to tolerate some level of inconvenience (compared to stock Android) to gain the security advantages. Not everyone is willing to make that trade-off, and that's okay. I don't want my daily use phone OS to adopt a more permissive security model to appeal to a broader audience. I suspect most GrapheneOS users share that stance.
There are other AOSP custom distributions that benefit from the security improvements GrapheneOS is able to get accepted upstream (though Google is making this more difficult than it used to be). I think, for people who aren't willing to make the trade-off, a better path is to use another AOSP distribution on the hardware they prefer, or to establish a separate project to build a downstream version of GrapheneOS (under a clearly distinct name) for other, less secure hardware... Trying to shadow each release as closely as possible and make best use of Graphene's generally excellent software customizations (e.g. storage scopes, deny network permission, etc) without pursuing a hard fork.
I'd certainly like something similar for NVIDIA Shield Devices, for example. But I know that's not what Graphene's mission is.
The GrapheneOS devs absolutely will not listen to anyone asking them to loosen their security model. And thank goodness they don't! That's why I use GrapheneOS. It's why many do.
>Remove the parts dependent on the Pixel security hardware, and you still have a MUCH stronger android OS than anything else available.
Yes.
And the correct course of action is a separate, downstream project with a different name doing exactly that and shadowing the GrapheneOS releases. Not a weakening of the GrapheneOS security model. If you don't want a maximally secure build of AOSP, you don't want GrapheneOS: you want something else. Maybe something substantially similar, but not GrapheneOS.
>They don't though, that's just a nonsense claim.
I don't know what is nonsensical about claiming that a project whose principal goal is to be maximally secure shouldn't weaken its hardware security requirements. The statement is closer to tautological than it is to nonsensical.
> And the correct course of action is a separate, downstream project
Except that there is explicitly no need for that.
> Not a weakening of the GrapheneOS security model.
There is no weakening for those people like yourself that feel they need the extra security provided by using pixel devices.
> I don't know what is nonsensical about claiming that a project whose principal goal is to be maximally secure shouldn't weaken its hardware security requirements.
The fact that you are claiming a weakening is happening at all is ridiculous. If it was made available for more devices, you, using it on a pixel, would be exactly 0% less secure.
Do you have an understanding of the point you are arguing, or are you repeating things you've heard?
>Do you have an understanding of the point you are arguing, or are you repeating things you've heard?
Do you understand that a security model includes allocation of finite developer resources? How much time a project's developers will spend on each class of problems?
The GrapheneOS developers have chosen a narrow set of devices that meet their hardware requirements, and that narrow list of devices allows also them to focus their resources, tightly integrate software hardening with the functioning of the hardware, and makes the project logistically manageable at all. Each clause in that sentence is part of the security model, not just the hardware requirements.
Have you ever tried to get a new build of something like LineageOS (or, once upon a time, CyanogenMod) running on a new device at all? Each ARM SoC (i.e. almost every smartphone) has numerous bespoke customizations, and its own set of largely binary-blob firmware, and often necessitates per board builds of an OS.
Adding even another half dozen devices is highly nontrivial. If you want it that badly, do the work and port GrapheneOS to those devices. Release your work downstream of the project, and benefit from its security improvements in software. It would be a good, worthy project with its own goal of bringing better security to a broader audience who are only using stock Android. That isn't the GrapheneOS project's goal.
Do you understand the purpose of the GrapheneOS project?
Its developers are in an ongoing cyber-arms-race against companies like Cellebrite and against state-level actors. The extreme hardware requirements (the primary two being Titan chips and multiyear firmware update guarantees from the vendor) are chosen with those adversaries in mind. That's their goal.
You and I are incidental users of the project. We are not its intended user: the person who needs a device that is as secure as possible against focused, well-resourced, state-level adversaries.
My stance is that I'm grateful to have access to a top-tier security tool, free and open source, way beyond my actual needs or threat model. I'm grateful it is so easy to use that the compromise (specific hardware required, 3-5% of apps I try not working) is well worth it. My stance is also that I'm against the broadening of project scope for the convenience of people who, like me, don't actually need this level of security but who, unlike me, are unwilling to make the compromise.
I'm not repeating things I've heard. I've built versions of Cyanogen and Lineage for phones I've owned over the years. I have a good idea of the work involved just getting things running at all, before even approaching the question of security. And all I'm saying is, "if you want support on devices beyond the project's scope that badly, do that work yourself and share it with the community."
> Do you understand that a security model includes allocation of finite developer resources?
You went out of your way to avoid answering the question, so it seems the answer was no.
I don't think you have a clue what you're talking about, and are indeed just repeating things you've heard. I don't see this discussion progressing further because of that, instead devolving into an is-too/is-not back and forth.
Your claim the idea that allowing Graphene on a wider array of devices would somehow weaken it's model remains nonsense, and you certainly can't support it, although if you wanted to make an effort that was more than you just asserting and repeating things, I'd be interested to consider it.
I don't see this discussion progressing either, because you haven't added anything to it, and it's harder and harder to assume you are acting in good faith.
You haven't actually made any specific arguments. Nor refuted any specific arguments I've made. You've just repeated, over and over, everything what I say is nonsense and I must be repeating things I've heard. I'd agree that sort of repetition tends to stall out discourse.
I do hope you end up with (or have already) a smartphone that is secure to your satisfaction, on the hardware that is most convenient to you, whoever ends up doing the work to make that possible. Have a good day also, and best of luck in the search for such a solution.
You're making a claim; I've asked you to support it with more than preaching, and you've been unable to do so. The lack of the discussion progressing is entirely due to that, and nothing more.
