Comment by sfRattan
9 months ago
> 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.
> GrapheneOS security requirements very much do need to be that stringent. That's the whole reason for the project.
They don't though, that's just a nonsense claim.
Remove the parts dependent on the Pixel security hardware, and you still have a MUCH stronger android OS than anything else available.
> And thank goodness they don't!
Your reasoning does not support your conclusion.
>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?
4 replies →