> You either build a debug image, so you just have it,

It is my understanding that that only gives root to adb, not apps, so no.

> or you add your own patches adding this capability (in exactly the same way the project modifies stock aosp), and build it.

If we're at the point of patching source trees, then no, we've left the realm of "very easy" behind. Installing Magisk is easy. Building Android from source, let alone patching it, is not.

> It's not disconnected from the project, but it's inherently within the project. SURE you can consider these two separate skills, but within the context of "getting the root on the GOS build" it's one. If you don't know how to make it happen, you don't have a skill to safely use it.

I really disagree. Knowing when to click the allow button or not is a separate skill from building/patching a ROM from source.

> Now let's consider the risks of that, - https://cybernews.com/security/rooted-android-ios-devices-su... - https://www.talsec.app/blog/what-is-rooting-and-how-to-prote...

I'd love to, but you'll have to mention what they might be. Both of those links treat root as nearly synonymous with compromise but never bother to explain how that compromise would occur, just 1. root 2. ??? 3. malware. That's fear-mongering, not a threat model.

> I mean, if you're a security researcher with a considerable reputation, you can certainly argue with authority, but I don't see the angle.

Or, we could avoid Appeal to Authority and talk threat models. The only one I've seen yet in this thread is people claiming that malware can fake out permission dialogs and that this is a problem for root permissions but somehow leaves the rest of Android's permission model in a usable state, which is... an interesting claim.

> Is the risk high? The consensus is that it is. I agree, you don't, I'm okay with it.

Many people making vague claims might technically be a "consensus" but it's not actually meaningful. If you've got an actual threat model, let's hear it, otherwise there's not much point to this.

Android of course requires root for installing and configuring applications. It just grants the root automatically.

Have a look at https://qubes-os.org to understand why you're mistaken.

> Look, if your media player or game can just steal your ssh keys, or slightly modify your changes to your code, or inject a script into your startup sequence, that's not very safe, is it?

The availability of application sandboxen and the availability of root access are two entirely separate security concerns.

I'm willing to take the very slight chance of getting compromised in exchange for getting things done.

Chromebooks have Developer Mode that gives full root.

https://www.chromium.org/chromium-os/developer-library/guide...

Can you elaborate on the differences in the compartmentalization? When the existence of root is equivalent to a broken security, it doesn't look secure to me at all. Are you talking about the security from the user?

By the way, personal attacks are against the HN Guidelines.

Linux doesn't mean systemd, GNU coreutils, glibc, GCC, GNU binutils, GNOME, etc. GrapheneOS is a Linux distribution and supports the Linux 6.1, 6.6 or 6.12 LTS branches. 6.12 is the latest LTS branch. Using Linux is a pragmatic thing, not a positive one for privacy or security. A huge monolithic kernel written in C is not the future for a highly secure OS. Moving away from the Linux kernel is important. QubesOS exists as a workaround for the insecurity of Linux. If the OS was using a highly secure microkernel in the first place, their hardware virtualization approach wouldn't be needed.