The sample project Filtering Network Traffic uses IPC (NSXPCConnection etc.) to send data from the network extension to the app, but the documentation for NEFilterProvider says
The sandbox prevents the Filter Data Provider extension from moving network content outside of its address space by blocking all network access, IPC, and disk write operations.
Since my network extension forwards all network traffic to the app so that the user can see it, I was wondering when the app isn’t running and the user shuts down the machine, if the network extension could write the flows it wasn’t able to forward to the app to disk, so that it could read them on the next successful connection to the app. Then almost by accident I read again the documentation and according to the quoted passage a network extension cannot write to disk, but it also cannot use IPC.
Is NSXPCConnection not considered IPC, or could the statement that it cannot write to disk be false as well?
Your reference to that sample code suggests that you’re on macOS. If so, that quote from the documentation doesn’t apply.
On iOS there are separate filter data and control providers to meet a specific privacy goal. The entire intro section on the Content filter providers documentation page assumes that design.
macOS doesn’t support this split; there is just one filter provider. That filter provider runs in a sandbox, but it’s not the custom sandbox that you get an iOS but rather something much closer to macOS’s traditional App Sandbox. This allows for writing to disk, IPC communication with code that shares an app group, and so on.
One day I’ll get around to fixing that page in the docs, but it’s not something I’m prepared to tackle today. You should feel free to file a bug against the doc though. It’s possible that someone from DevPubs might pick it up.
If you do file a bug, please post your bug number, just for the record.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"