Follow up: I've found two additional ways to allow the third app to connect to the endpoint system extension over XPC: Add the "System Extension" capability/entitlement to the app (even though this doesn't install a System Extension, it just received data from it); note, this changes the Signing Certificate from "Development" to "Apple Development: (my development identity info)" Change Signing Certificate to "Sign to Run Locally" If I do either of those, I can remove the temporary entitlement com.apple.security.temporary-exception.mach-lookup.global-name entitlement (I look forward to getting the endpoint security entitlement to see what issues go away and which ones remain (and to enable security on my laptop again)) Thanks

I just got it working but for logging only. I'm not trying to stop any flows at the moment. It took a while to get all the names right (e.g., NEMachServiceName, AppGroups, etc.). I have no filter rules, so my extension gets every flow. My extension does not send messages to the user app. I set up startFilter to look like this: override func startFilter(completionHandler: @escaping (Error?) -> Void) { completionHandler(nil) } and then handleFlow to look like this override func handleNewFlow(_ flow: NEFilterFlow) -> NEFilterNewFlowVerdict { if let socketFlow = flow as? NEFilterSocketFlow, let remoteEndpoint = socketFlow.remoteEndpoint, let localEndpoint = socketFlow.localEndpoint { os_log("Flow local endpoint %{public}@, remote endpoint %{public}@", localEndpoint, remoteEndpoint) } else { os_log("Flow (unknown)") } return .allow() } Then I use the Console app to watch all the log messages. I also set a filter string, SimpleFirewall, in the console app to keep an eye on just my stuff. Side note: in the os_log() call, use %{public}@, not just %@. My next step will be to send messages to the user app.

Adding a note in case someone (or the future version of me) runs across this in the future. Apple binaries (at least as of macOS 13.2.1) have an empty team_id.

I am getting this too when clearing the search field for a table in a macOS app built with SwiftUI. My code is very similar to the OP's code. I have a MainActor class that is an @ObservableObject (I create a singleton of it) holding a Deque of data that is @Published. I have a computed property that returns a filtered Deque (from the published Deque), and that what is used to populate the table. The table has a .searchable(text:) modifier. I get the alert when I clear the search field.

I am getting this too when clearing the search field for a table in a macOS app built with SwiftUI. My code is very similar to the OP's code. I have a MainActor class that is an @ObservableObject (I create a singleton of it) holding a Deque of data that is @Published. I have a computed property that returns a filtered Deque (from the published Deque), and that what is used to populate the table. The table has a .searchable(text:) modifier. I get the alert when I clear the search field.

FYI: I just compiled and ran Apple's sample GardenApp from their 2021 WWDC presentation SwiftUI on the Mac: Build the fundamentals, and after entering a search term for the table and then clearing the search term, the app generates the same warning. So, at least we are in good company. 2023-04-11 07:27:38.870357-0700 Garden App[14053:1032028] WARNING: Application performed a reentrant operation in its NSTableView delegate. This warning will become an assert in the future.

I was hoping there was an easy way for a user to determine UBF8T346G9 = Microsoft EQHXZ8M8AV = Google etc. A lot of the time the first two components in the signing ID was helpful (e.g., com.google), but as Eskimo mentions, this is only a convention and not reliable as an unique identifier. In the attached screenshot, I've searched for "crashpad". In the list of programs recently executed, and two different programs named "chrome_crashpad_handler" with the same signing ID ("chrome_crashpad_handler") popped up. Each had a different path. One was launched by Google Chrome (and had the Google Team ID) and one was launched by Microsoft Teams (and had the Microsoft Team ID). My end goal is to identify every organization that contributed signed code that ran on a given machine. The Team ID seems to do it, but it isn't very understandable to humans.

I think the problem was a combination of certificates expiring and registered devices expiring. Once I corrected these, installation of Endpoint System Extensions started working again. Note: I had multiple certificates generated on multiple Macs (that I actively use), which expired at different times. I think this created a rolling set of failures over a span of about a week. Development stopped working on one machine but not another. Eventually everything stopped working. It was very confusing for me at the time.

Here is a screenshot showing the output of the SwiftUI view sample code above. I can grab the dark bar/rect in the middle and drag it up and down to adjust which pane (blue or red) gets more space. Also, if there is a more elegant/standard way of doing this, I'd appreciate any pointers. I tried a Divider() instead of a rect, but I had problems selecting the divider with my mouse. Here is how I am using this in actual code. The top view is a list of organizations running code on my Mac. The bottom pane provides details about that team. The horizontal bar lets me adjust which view gets more space - the list view or the details view.

Good point. I've added some additional detail below. (I'm hoping there is a standard way of doing this, and I can just use that technique instead of my drag gesture code)

Note, the socket family = 30. IANA lists address family 30 as "MT IPv6: Multi-Topology IP version 6", and I've seen some material of Apple Wireless Direct Link (AWDL). I guess this is the first AWDL traffic I've noticed.

I still need to write up a detailed report, but a quick interim report: I compiled and notarized the app on my iMac Pro (Intel) running Ventura, I can now enable Full Disk Access on my iMac Pro. Also, the name in the Full Disk Access section is no longer to full Bundle ID but just the last component of the Bundle ID. (Previously I had compiled and notarized the app on a Mac Book Pro (M1 Pro) running Ventura)

I figured it out. When my endpoint system extension encountered the initial error calling es_new_client() because the program didn't have Full Disk Access, I did not exit the program (see sample code below). Once I added code to exit the program when an error was encountered, the operating system would restart the endpoint system extension 10 seconds later. The OS would keep starting the endpoint system extension every 10 seconds. Once the user did enable Full Disk Access, the next time the OS ran the endpoint system extension, es_new_client() succeeded and the program ran fine. Old (bad) code: @autoreleasepool { dispatch_sync(myQueue, ^{ setupMonitoring(); }); } dispatch_main(); In the code above, setupMonitoring(), which configures the es_client_t, returned a non-zero value if there was a problem (e.g., es_new_client() returned ES_NEW_CLIENT_RESULT_ERR_NOT_PERMITTED), but I ignored that value. New (working) code: @autoreleasepool { dispatch_sync(myQueue, ^{ if (setupMonitoring() != 0) { exit(-1); } }); } dispatch_main();

Just a brief update: my iMac Pro running Ventura 13.6.1 didn't require the app to have a provisioning profile to install an endpoint system extension. That was unexpected (to me). I created a clean sheet project making it as simple as I can. I have both the main app and the endpoint system extension built using "Automatically manage signing". I have not created any provisioning profiles for for the main app or endpoint system yet. I did a quick test with where the endpoint system extension could be run and enable Full Disk Access. Status MacBook Pro (M1 Pro, Ventura 13.6.1) where I built in - everything ran fine (not surprised) Mac Studio (M1 Max, Sonoma 14.1) - I could install the endpoint system extension but not grant Full Disk Access (not surprised) iMac Pro (Intel, Ventura 13.6.1) - I could install the endpoint system extension and enable Full Fisk Access (surprised) I was surprised I could install endpoint system extension and grant Full Disk Access on a different Mac without needing any provisioning profiles. Next, I'll build with a testing profile to see if I can get it running on the Mac Studio (Sonoma 14.1). The Mac Studio with Sonoma is where I've been having problems granting Full Disk Access lately.

I think I verified Quinn's suspicions: I needed to test with clean machines. I created two VMs in UTM running Ventura 13.6.1 and Sonoma 14.1 and creates an account that was not associated with my developer account. I then tried to run the automatically signed code (i.e., no provisioning profile) that worked strangely on my iMac Pro 13.6.1 and Mac Studio 14.1, and both VMs blocked the app from running. This is what I expected. Next step: checking with provisioning profiles...