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.