Comment by grapheneos

That doesn't come across as steelmanning our position at all but rather the opposite. It omits the most important points.

Providing app accessible root in the OS greatly reduces security without people ever using it. It gives root access to a huge portion of the OS by having it around as a feature even if it's never used. It fundamentally breaks a large portion of the security model for verified boot, which can no longer defend against attackers maintaining privileged access after a compromise

In addition to the inherent reduction in security from providing it, nearly all apps built around using full unconstrained root access don't need anywhere close to that. In nearly all cases, it's used as a shortcut instead of doing things securely. Following the principle of least privilege by only granting the required privileges is a core part of security. For example, an app for managing low-level firewall rules only needs an API for doing so in netd and netd only needs CAP_NET_ADMIN rather than full root. Doing this by giving full root access to a graphical application which is not properly integrated into the standard firewall management is not a secure approach. Giving full root access to a large portion of the rest of the OS in a way that can be hijacked in many attack vectors to make it possible to dynamically grant it makes it a lot worse.

GrapheneOS does have user-accessible root access in userdebug builds. Those aren't the main production builds of the OS but people who believe they know better and want to have it can build, sign and use those instead. Building the OS also gives an opportunity to include safe implementations of features instead of insecure hacks.

Every app can be backed up as part of the baseline. Apps can exclude specific data but are nearly all doing so because that data is a cache or can't be used elsewhere. For example, Signal encrypts their database with the hardware keystore and bypassing them excluding it from backups to back up all the files for it will not result in the data being possible to restore elsewhere.