[summm]

That is almost the exact argument from the toxic Graphene community GP complained about. Only the anti-user part of the security model is really destroyed, and rightly so. The part that considers the user to be the attacker and wants to protect the app and their developer's evil intentions from the user.

An RCE that only affects a non-root component or a component that ran with system privileges anyway will not be enabled or facilitated by this.

Of course current root implementation may be not be as secure or convenient as they could be. For example after each update they must be re-applied, from a downloaded app, leading to people updating later and opening another problematic supply chain. But that could be remedied if they were better integrated into ROMs.

[noirscape]

To be more exact - the comment you're replying to is exactly the type of GOS dogma that makes it hard to recommend.

The problem is that GOS is taking a privacy approach that's so niche that it borders on being useless[0]. If you're the type who is at threat of say, state actors (or has convinced themselves they are), then it makes complete and total sense to use GOS with all the anti-user crap it entails. You get a completely secured fortress of a phone out of it.

What makes the GOS community toxic is the subsequent attitude taken by developers to other privacy models. Most people aren't "state actor" degrees of paranoid, they just don't want Google enabling hidden settings and pass the users photos onto their servers; they might want to reign in Play Services (without abandoning it entirely) or take advantage of GOS' anti-background GPS capabilities. These are all legitimate features that aren't undermined by having root. Google isn't generally a malicious actor with these things (you're not worth enough to them to do these tactics) and if someone is capable enough to install GOS they are also likely capable of maintaining decent app installation hygiene which limits that too.

The response from the GOS community when these things are brought up amount to 1. Fork Off (not happening because user != developer), 2. "You're holding it wrong" or 3. Ban the user for being a Calyx/Divest shill or whatever else (not endorsing either project).

There's also the projects noted history of using license trickery to prevent non-Vanadium browsers from implementing a System WebView that are why I'm considering them toxic to Android privacy as a whole. (And general trademark nonsense to prevent people from achieving the fork off bit) The GOS community is extremely "GOS or nothing" and it sucks because GOS itself is genuinely a technical achievement.

[0]: Which to be clear - multiple online privacy communities have this specific issue, that's not just on the GOS community.

[shortsunblack]

Graphene isn't a 'privacy' project. It's a security project. It just manages to be the most privacy friendly there can be; but it's not a design goal.

You cannot have 'privacy' without 'security', because your privacy measures can easily be circumvented and defeated otherwise. That's why calyx os or other grift projects are useless on both.

The design goal IS security. And each decision is motivated by such design goal. An unconstrained system user that circumvents the security model just to allow some users to intercept network requests to do adblocking is irreconcilable with the design goal of having a secure OS. What's stopping the adversary from terminating TLS requests and snooping on your plaintext traffic when such privileged API access is possible?

If you really want some adblocking, you can set-up to use a DNS server that does that. Such measure is not the best there can be, obviously.

Finally, if an user can bypass the security model, so can the attacker. The security boundary between "adversary user" and "not hostile user" is hard to define and enforce.

[mbananasynergy]

Hi there. GrapheneOS community moderator here.

GrapheneOS is a security and privacy project, and puts significant effort into advancing both. Security is a prerequisite for privacy, and getting that right is extremely important, but all of that is exactly so that you can then safeguard privacy.

GrapheneOS has many features which are heavily towards the "privacy" side of the scale, rather than the security one. Features such as Storage and Contact scopes are features which allow you to preserve privacy by granting apps just the information you need, instead of giving them bulk access to your data. The network permission is as much as a privacy feature as it is a security feature. Being able to deny sensors access from apps so that they can't access them is a privacy feature etc.

I'm mentioning the above because it seems like people tend to split security and privacy into completely different camps in a way that doesn't make sense. Those two things play off each other, and one needs the other to be effective. GrapheneOS focuses on both.

I hope that helps make things a bit more clear!