In this case look at the local and remote ports, is everything the same here for the flows or are they different? If they are equal, would that mean that it's effectively the same flow? Why is then handleNewFlow(_:) called multiple times? Does this only happen when data starts moving on the flow? Not sure what you mean... it sounds like handleNewFlow(_:) can indeed be called multiple times. In case it was not clear, the same identifiers really appear multiple times when handling flows in handleNewFlow(_:) and not when handling reports in handle(_:). What I mean is that I didn't even check what happens in handle(_:).

I never removed the network configuration (I assume you mean in System Settings > Network). I just quit the container app and deleted it. When rebuilding it, moving it to /Applications and launching it again, sometimes I get the "System Extension Blocked" alert showing that the extension was deleted alongside the container app, but sometimes I don't.

Different info is available on iOS. I've been running this code on macOS, never on iOS, so the app and pid information seems to also available on macOS. Or do you mean that the information that's printed in the description is not reliable on macOS?

I recently noticed that NEFilterFlow already seems to have a notion of the process that generated it. In handleNewFlow(_:), printing flow.description outputs something like this: identifier = 976999BB-C169-42BE-9CAF-41D22E332848 hostname = www.imdb.com sourceAppIdentifier = .com.apple.Safari sourceAppVersion = 17.0 sourceAppUniqueIdentifier = {length = 20, bytes = 0x94d650dbd26d77127b24d6c80c1faf8109368246} procPID = 744 eprocPID = 600 direction = outbound inBytes = 0 outBytes = 0 signature = {length = 32, bytes = 0x3f4e07a6 6077bb66 05cd661f 522a515e ... fa2751eb ac6bb41a } localEndpoint = 192.168.1.6:52304 remoteEndpoint = 18.165.186.203:443 remoteHostname = www.imdb.com protocol = 6 family = 2 type = 1 procUUID = F470D161-B607-3458-ADDE-F35CC5857E19 eprocUUID = A8B1FDA3-50E6-3A8A-AFCF-47D86E86B87F In particular, notice sourceAppIdentifier = .com.apple.Safari and procPID = 744. Is this information reliable? Why does it appear in the description but cannot be accessed via the API?

Filter data providers only see TCP and UDP flows. Is this really the case? I also have a NEFilterDataProvider and until now I got ICMP (remote endpoint 192.168.1.1), ICMP6 (remote endpoint ff02::2), TCP and UDP flows.

In this case it seems to always be UDP. Is this different from protocol to protocol?

I install it through a container app which shows the "System Extension Blocked" alert.

This sounds like a severe impediment. Is there still no official response from Apple?

In my case I had a whitespace in the Network Extension's product name in the build settings. Removing it solved the issue.

Thanks, I will consider asking the user to contact me when the crash happens. I only have the crash reports from Xcode. Since the whole app extension depends on the existence of that directory, it doesn’t really make sense for me to prevent the crash.

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.

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.

Thank you. I already filed FB12057582 in March 2023 but got no response for now. It would be great if you have any power over speeding that up. Since I'm planning on releasing this in an App Store app, I want to be sure that only process names that can be securely determined are displayed as such, while all the other ones, which currently include the mentioned ones (trustd etc.) will be shown with red text and a warning. It would be great if all legit processes could be displayed as such sooner or later (but preferably sooner). And thank you for predicting that a TSI probably won't change things here. It's always frustrating discarding a TSI that simply results in a mere confirmation that it's a bug and one will have to wait for it to be solved.

Thanks for your help. I've created FB13238546. I already have an App Group entitlement with value $(TeamIdentifierPrefix)org.domain.app for the main app and the extension. I cannot reproduce the crash myself, not with the App Store app and not in Xcode.

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?