I'm not against using an App Group if that is what is needed. All the documentation I have seen says that App Groups are for sandboxed apps, and we don't use the sandbox. I have no idea of what an App Group is or how to use an App Group. I'm confused why I need to use App groups to have two non-sandboxed apps/binaries/processes to communicate.

Yes, I am using "app" in the general sense. They are a combination of apps and bundles that are either LaunchAgents or LaunchDaemons, or started from those binaries. One of the LaunchDaemons is responsible for launching a majority of the other processes depending on licensing and features. Nothing has to be double-clicked by the user.

Borrowing heavily from AppCommunication in the Filtering Network Traffic, I was able to get XPC communication between the container app and the network extension.One of our apps is an XPC broker that does some security checks (to see if processes are signed properly) before facilitating the XPC connection. So all of the XPC Service building and Client connecting code is in helper classes that faciltate that brokerage. I need to get at least one of these apps (preferably the network extension itself) to communicate to the XPC broker and communicate to another app that is not the container app.Thanks for your help.

I can confirm that in my testing, eskimo is right. I was unable to see the local port until data passed through the flow.

I created a Suggestion feedback ticket with number FB7573775 that suggests the AppProxyProvider be able to not proxy a flow but allow the flow to continue.

According to this documentation, the NEFilterDataProvider can only put up block pages if the flow originates from a WebKit browser. I also saw in documentation (but I can't find it at this moment) that Content Filters were only able to see the data but not modify it. If we can't use the built in block page aparatus, and we can't modify the flow to show a block page when needed, then we can't use the content filters. I realize that some of the documentation on these APIs are for macOS and iOS, so there might be some inconsistencies that are not well documented.Thanks for your insight!

All three actually. Looking at incoming data to look for malicious contentPotentially blocking outgoing connections to known bad actorsReplacing page contents with a product block page when user browses to malicious siteproduct warning page when user browses to unproductive siteproduct block page when user browses to unproductive siteSome of these use cases can be handled by the Content Filter, but I don't think it can cover all of them. We have to support all browsers, right down to the little unsigned homebrew wget.

Thanks for confirming it, Quinn. The bug number is FB7492627.