Network permissions toggle exists for each user app and controls all traffic just for that specific user app on all interfaces. If, as you say in this thread, GrapheneOS drops all new inbound traffic (which is traffic not established by user app and traffic not related to existing user app traffic) on all interfaces by default then whether a server user app accepts such traffic (via Network permissions) or not is not relevant because (as you sayd in this thread) GrapheneOS processes and drops all new inbound traffic by default before it can be processed by any user app. As such, the statement from mentioned GitHub discussion, is either false because both user app and OS must accept new inbound traffic for a server to serve and that is not possible if GrapheneOS processes and drops all new inbound traffic (before it can reach any user app) OR what you say is false and GrapheneOS does indeed allow all new inbound traffic to allow user apps to be ones performing filtering. Both statements cannot be true because any server that serves must accept new inbound traffic and if GrapheneOS drops such traffic by default, running a server that requires acceptance of new inbound traffic is not possible.
Linux without any special configuration drops new inbound connections unless something is listening on the port. Network toggle controls whether something can listen on a port. Your statements are not accurate.
Running local DNS server software like AdGuard Home on Raspberry Pi (RPiOS/Linux) is a perfect example. You can enable AdGuard Home to accept or deny traffic from whichever source to itself as software on OS, not to OS itself, but only if OS accepts all traffic. If OS drops all new inbound traffic via Netfilter rules, then whether AdGuard Home allows such traffic or not is not revelent because OS drops all new inbound traffic before it can reach AdGuard Home.
Network toggle controls listening on ports including
localhost. It could be split up between public networks and
localhost in the future to permit one but not the other. Splitting it up almost any other way doesn't make sense.
Once again, if you can indeed run servers on GrapheneOS, then GrapheneOS itself must accept all new inbound traffic and have user apps decide if it accepts or drops such traffic. The GitHub response says that one can indeed run servers on GrapheneOS and that is controlled by Network permission toggle. If that is true, then GrapheneOS does not drop all new inbound traffic and allows user apps to be the one in control.
No, that's wrong, and it has been explained why it's wrong. Stop repeating misinformation.
If my assumption about GrapheneOS accepting all new inbound traffic is true and GrapheneOS leverages eBPF as OS-wide firewall then it integrates eBPF in a way that allows applications to control new inbound traffic and GrapheneOS does not drop such traffic by default.
It's not true. eBPF is used to drop all inbound traffic. Apps with the INTERNET permission (Network) are given an exception from the rule. VPN lockdown mode (block connections not through VPN) works in the same way. Your understanding of how eBPF works is wrong.
What AOSP firewall? Android 11 AOSP still has 3 Netfilter IPTables - INPUT, FORWARD, OUTPUT and all 3 are set to "ACCEPT" policies and allow traffic whichever apps. Some rules use markers I can't figure out, but new inbound traffic is definitely not dropped by default. Setting custom rules (which requires root of course) resolves that issue.
It was already explained repeatedly that iptables is legacy. It was replaced by nftables. Android moved to using eBPF for almost everything instead to have more control, higher performance and more dynamic configuration. New inbound traffic is dropped by default. Only apps added to the whitelist via the INTERNET permission can listen on a port. This has already been explained.