How is your app signed? A problem with the signature might prevent the OS from "remembering" that permission has been granted before. Thanks for the suggestion, but I don't think there's any problem with the signature. All other warnings (Calendar, Reminders, etc.) only get shown once, but this one gets shown each time. I think it only started appearing since macOS 14 Sonoma.

While I was writing my earlier answer I just got 10 new flows from 0.0.0.0 to 192.168.1.1 by /sbin/ping: socketType = SOCK_RAW, socketFamily = AF_INET, socketProtocol = IPPROTO_ICMP.

Sorry for my late reply, again I wasn't notified of your response despite watching this thread. Yes, they are NEFilterSocketFlow. I just got 2 outbound flows from local :: to remote ff02::2 (both port 0) by /usr/libexec/configd: socketType = SOCK_RAW, socketFamily = AF_INET6, socketProtocol = IPPROTO_ICMPV6.

In this case look at the local and remote ports, is everything the same here for the flows or are they different? I can now confirm that local host and port, and remote host and port are the same. The process path is always /usr/sbin/mDNSResponder.

Does this only happen when data starts moving on the flow? Isn't handleNewFlow(_:) called only when data starts moving? I couldn't find any mention of a different behaviour in the documentation.

The intended function to use when you specify the .cursorUpdate option on your tracking area is cursorUpdate(with:): Thanks, that really seems to solve the issue with the sample code I provided above. I guess updating the cursor once in cursorUpdate(with:) makes macOS aware that there is a custom cursor so it doesn't try to reset it continuously, as opposed to "force" setting it in mouseMoved(with:). The problem now is that I was really looking for a way to set a custom cursor whenever the mouse moves, because in my custom view there can be many hotspots that should change the mouse cursor, and I guess adding hundreds of tracking areas is not ideal... or is it? These hotspots also change very frequently. It seems like calculating and creating all individual tracking areas is very inefficient, as opposed to dynamically finding out what the cursor should be depending on the mouse cursor's position (particularly since in my case this can be done with some simple calculations).

Did you remove the container app using Finder? Yes.

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?