I cannot find in the documentation if using NEFilterDataProvider.apply(_:) has any advantage over manually inspecting incoming flows in handleNewFlow(_:) other than being a shortcut. Or are those rules guaranteed to be applied even if the network extension crashes or similar? If it has no practical advantages, then manually inspecting each flow allows to set up more flexible dynamic rules.
What's the advantage of applying settings with NEFilterDataProvider.apply(_:) over manually checking incoming network flows?
Not sure I exactly understand your question here but let me provide some background and maybe that will take us in the right direction. When you create NENetworkRule's and apply them to your NEFilterSettings you are telling the system that your provider wants to setup policies for a specific set of traffic to filter. For example, let's say you want to filter all TCP traffic. You would setup a NENetworkRule that describes this condition and then you would apply it in the NEFilterSettings to the provider. This creates policies in the system and then based on those policies traffic matching your policy is handed off to handleNewFlow for your provider to evaluate and make a filtering decision upon.
Thank you for your input. It sounds like you're saying that I can set up rules to specify what flows I get. But what I'm doing right now is specifying an empty set of rules NEFilterSettings(rules: [], defaultAction: .filterData) which allows my code to manually filter all flows, right? Why should I specify any custom NENetworkRule if I can manually inspect all flows anyway?
It sounds like you're saying that I can set up rules to specify what flows I get.
Yes.
Regarding:
But what I'm doing right now is specifying an empty set of rules NEFilterSettings(rules: [], defaultAction: .filterData) which allows my code to manually filter all flows, right?
Yes, I believe in this mode you will simply get the standard system filter policy set and it will not scope the filter to any specific traffic.
Regarding:
Why should I specify any custom NENetworkRule if I can manually inspect all flows anyway?
If your provider is scoping the system for all traffic then your provider will become very very busy and this could slow down the traffic on the system while raising the CPU used by the provider. The advantage of scoping the traffic is so that you can focus on a subset of traffic that works for your business case while keeping performance on the system inline.
Thanks. So rules are more performant than custom filtering code and have no other practical advantage. Since I want to display all flows to the user of the app anyway, then there's no reason for me to use rules at all and simply get all the traffic.
So rules are more performant than custom filtering code and have no other practical advantage.
Yes, NEFilterRule's allow flows to be bypassed at the kernel level as opposed to stopping the flow and asking the user to provider a filter verdict.
Regarding:
then there's no reason for me to use rules at all and simply get all the traffic.
You may find that this is a lot of networking flows that the user ends up having to acknowledge when the filter is first turned on.
Thanks again.
You may find that this is a lot of networking flows that the user ends up having to acknowledge when the filter is first turned on.
Do you mean that enabling the filter generates a lot of network flows? In any case, I would like to give the user the chance to inspect all flows, but they are initially all allowed by default, without need of user interaction.
Do you mean that enabling the filter generates a lot of network flows?
Well, there are naturally a lot of flows on the system at any given moment, and enabling an open filter present the opportunity with the user needing to provider a filter verdict is what I meant.