Eylenburg's site has comparisons between a bunch of different types of software and services with a significant focus on privacy and security rather than aesthetic customization features, etc.
For the Android comparison, GrapheneOS is the only privacy and security hardened OS included in the comparison. DivestOS used to be included before it was discontinued. An OS not including Google Mobile Services and branding itself as private based on that is a much different thing than a privacy and security hardened OS. Which other Android-based hardened OS could be included in the comparison?
None of the operating systems listed in the comparison include app accessible root access. Giving unconstrained root access to a huge portion of the OS including the application layer including a GUI application for managing firewall rules is not a well secured to implementing it. Managing firewall rules is entirely possible to implement while following the principle of least privilege and not substantially reducing OS security. In fact, Android has standard support for it and all of the operating systems included in his comparison rely on it if you want to do fine-grained traffic filtering.
RethinkDNS is a good example of an app providing support for local filtering via the VPN service app feature without losing the ability to use a VPN. RethinkDNS supports using a WireGuard VPN or even multiple chained WireGuard VPNs while doing local filtering of both DNS and arbitrary connections. It can filter connections based on the results of filtered DNS resolution. That's the approach that's used by Android so that's inherited by every OS in the comparison.
GrapheneOS is the only OS that's listed fixing all of the leaks for standard VPN lockdown feature which is needed to prevent leaks for firewall apps including RethinkDNS based on the VPN service app feature. That's not listed by the table, although it could be and it would make sense for someone to file an issue proposing listing it. Many GrapheneOS privacy and features are not listed by Eylenburg's comparison and a lot of what's listed are under huge categories such as "Hardened system components".
> For the Android comparison, GrapheneOS is the only privacy and security hardened OS included in the comparison. DivestOS used to be included before it was discontinued. An OS not including Google Mobile Services and branding itself as private based on that is a much different thing than a privacy and security hardened OS. Which other Android-based hardened OS could be included in the comparison?
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?"
> None of the operating systems listed in the comparison include app accessible root access.
There is a difference between not shipping something by default, and being actively hostile to it.
> Giving unconstrained root access to a huge portion of the OS including the application layer including a GUI application for managing firewall rules is not a well secured to implementing it.
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.
> RethinkDNS is a good example of an app providing support for local filtering via the VPN service app feature without losing the ability to use a VPN. RethinkDNS supports using a WireGuard VPN or even multiple chained WireGuard VPNs while doing local filtering of both DNS and arbitrary connections.
AFAICT, RethinkDNS demonstrates the problem quite nicely. On, say, my laptop, I can configure arbitrary VPNs and firewall rules, and I can configure them independently. 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. 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.
> 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.