And Graphene OS is also anti-user by being tremendously rude about NOT providing root and using the same tired "suck-u-rity" crap Google and Apple also use.
If you're smart enough to buy a phone that supports GrapheneOS, AND install it, yeah you should have root.
And tools like XPrivacy and plugins allow control of subsystems like GPS spoofing and lying to apps.
Software freedom is about freedom of choice, not philosophically mandated security holes. You are free to take the GrapheneOS code and introduce a huge vulnerability in the form of a privilege escalation path from sandboxed apps if you wish, it is open source and you can easily compile and flash your own build.
Mobile phones store incredibly intimate data and are incredibly vulnerable to seizure. It stores my message history, pictures I've taken, so many other records that together would provide an incredibly detailed view into my private life. And it is on my person at all times, even through checkpoints where I have minimal protections against search and seizure like borders! This is not a device that I want a broad surface for modification of system software on.
Why is providing a mechanism to view your own data a security risk? You cannot view application data (even in a read only fashion) without root on android. Why should the app be able to read its own data, but the human not able to?
GrapheneOS already ships Seedvault, which extracts application data with no root at all, so what you describe is possible in at least some form, but I assume not with the ergonomics you want.
Providing a good interface for that access is a specific missing capability. But we shouldn't presuppose that the only way to supply it is a global su. The former is a bounded fix; the latter changes the isolation model of the entire system. A portal is mediated, scoped to what you asked for, and revocable. Root is none of those things.
Seedvault is itself an example. The need for backups can be met either with a narrow backup service or by handing out root and letting you do it however you like. Those two have very different security properties, and you can want the new capability without wanting a generic privilege escalation path to deliver it.
> not philosophically mandated security holes.
So you're arguing the same technofascist arguments that Apple and Google both claim. I own my phone, not technofascist sky daddy, or whatever developer also envisions that role.
My hardware. My rules. More people like you need to learn what ownership actually bloody means.
The source code is right here, make your hardware follow whatever rules you wish with your derivative of it: https://grapheneos.org/source
you have the choice to run a custom build of grapheneOS with root. If you think its valuable there probably are other people that think so too and you could coordinate and figure out your own builds / releases / QOL, etc.
The graphene team provides so much value already. I don't expect them to cater to every need 100%. They are a positive force in the ecosystem when every other Android provider is locking down their builds they still provide everything as open source with security updates as best as they can.
It's pretty trivial to get your own almost-GOS with root. The official GOS release simply doesn't support it in the production images.
Why not root has been explained many times and you actually either want the official image with no root exactly because of the benefits, or you want custom image because you don't need these benefits.
For location faking Mock location works on GOS,l.
I see much bigger problem with not having a reliable backup than not having root.
If you are technical and want root its very easy to patch a build of GrapheneOS to include whatever mechanism you want. You can even automate this to continue to receive updates.
I think the decision of GrapheneOS to maintain the attestation features and not providing user root is what gives it a fighting chance of being accepted as legitimate 3rd choice. See: Revolut and others adding GrapheneOS keys and trusting their attestation
Like or not, for most users, having root access is a liability, especially with more and more important things being held on phones . Someone downloading a photo editing app and then having a rootkit installed in the background that waits to empty their bank account is not a workable situation.
> Someone downloading a photo editing app and then having a rootkit installed in the background that waits to empty their bank account is not a workable situation.
Yes, that would be absurd. Thankfully, that isn't how root access has worked in a very very long time if ever. If photo editing app requests root access... you click deny and uninstall it.
Because so-called “trusted” apps that you do give root to have no chance of getting compromised, right?
Pretty low, honestly, but being careful about that is why I tend to make it ask every single time.
Some percentage will click Allow.
Yes, that's Google's excuse for banning side loading. It's a terrible reason.
They aren't banning it. They are introducing a one time 24 hour waiting period. Not ideal, but not banning.
>If you are technical and want root its very easy to patch a build of GrapheneOS to include whatever mechanism you want. You can even automate this to continue to receive updates.
You don't even need to patch it, AFAIK. You can just install magisk, which is how you're supposed to get root on LineageOS as well.
Just to note Revolut are quite famously anti-security and GrapheneOS have had to work around attempts to ban it on a few occasions. You may have meant the swiss finance app Yuh or something else.
GrapheneOS's goals are privacy which must start from a secure baseline. If you want to make it less secure yourself, you can, but it's not the goal of the project.
It's not anti-user if it doesn't add the features you want that would destroy the security of the OS.
It has many features that give the user more control. Like disabling emergency alerts, protecting your data from attackers, contact and storage scopes (lying to apps for more privacy while retaining functionality), sensors permission, network permission.