> I was arguing on the other axis. It's got good coverage of OS options, but the list of features is indistinguishable from someone saying "okay, this is what GOS does; how do others compare to each of its selling points?"

That's not what they're doing. Their focus is privacy and security, but they've only included a single OS in the comparison aligned with that focus. They don't want to include less known operating systems such as forks of GrapheneOS.

> There is a difference between not shipping something by default, and being actively hostile to it.

GrapheneOS doesn't do anything that's hostile towards users having root access. It provides official support for it in userdebug builds, which we recommend doing with ro.adb.secure set to 1 rather than using the default Android userdebug configuration.

> Agreed, that would be foolish. Thankfully, nobody is suggesting that. Just use a permission prompt, like every android root solution has for... over a decade? I don't think I've ever seen anyone not putting root behind a permission prompt, actually.

That's not addressing what was said. Having a permission prompt to grant unconstrained root access to apps still involves giving root access to a massive portion of the OS, greatly harming the security model and losing a bunch of the security features. It inherently regresses security in an enormous way which having user-accessible root access alone does not. Making it accessible to apps through the high level OS UI is a far different thing from having a very well protected way for users to have root access.

> On, say, my laptop, I can configure arbitrary VPNs and firewall rules, and I can configure them independently.

There are major issues with VPN leaks without these things tightly tied together and having multiple things configuring firewall rules is going to cause major conflicts. Android provides support for having a per-profile VPN with built-in leak blocking where the OS takes on most of the responsibility for it and can properly integrate it everywhere that's required.

> Android conflates them such that - if not using root to work around the official way - your firewall app and your VPN app must be the same app.

No, it does not have to be the same app. It's a choice the app developers are making to not provide an extensible system interoperable with other apps but rather to do everything themselves. It's also not a conflation of these things but rather it needs to be implemented as an OS API to do it properly.

> It's nice that RethinkDNS has specifically added wireguard support to its firewall app, but the fact that they needed to is a symptom of a poor design.

It's not a poor design but rather a much better design which avoids the very broken approach of multiple applications including VPNs trying to configure firewall rules. It's impossible to get right without all of those applications closely coordinating which is not what happens. Having VPN support built into the OS with a well defined API for apps to implement it with leak blocking support built into the OS is a far better approach which can be done correctly instead of the mess on laptops/desktops you're talking about. Android doesn't have a great implementation of all this upstream but the high level design approach is a far better one. It needs a major overhaul to heavily use network namespaces instead of the current messy approach built on a legacy design. That does not change that providing the VPN leak blocking within the OS and an API for VPN implementations is definitely a better approach. Built-in WireGuard support would be nice too but should be done properly.

Giving root access to a huge portion of the OS including the high level application layer and to actual apps running on top is always an insecure approach to this. It's a lazy shortcut to skip having to implement a proper system following the principle of least privilege where the GUI portion of the OS does not simply have unconstrained root access to manage everything at a low level in incorrect, racy ways. The correct place for firewall management is netd with user-facing interfaces which end up controlling what's done by netd. netd has CAP_NET_ADMIN and is in fact contained by SELinux without access to much more than networking configuration. Giving unconstrained root access to the GUI portion of the OS where minor UI bugs can give permanent root access to an attacker where there's no way to revoke it if they want to stop it is definitely not the right approach to implementing more user-facing firewall controls.