The edge cases and qualifiers you provide here are very far from my needs. Most executables I want to mute are well protected by SIP, and will never move (MacOS private frameworks, daemons etc. plus few third-party that are also very well defined). My issue is very blunt. I mute a simple and perfect executable path. Here are some - my list is much longer, but you'll get the idea: +(NSSet<NSString *> *) baseBinaryPathWhitelist { static NSSet *_baseBinaryPath = nil; // any executable in these specific paths will be ignored static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ _baseBinaryPath = [NSSet setWithArray: @[ NSProcessInfo.processInfo.arguments[0], // don't inspect our own ITProtector process. @"/sbin/launchd", @"/bin/launchctl", @"/bin/ps", @"/bin/sleep", @"/usr/bin/dscl", @"/usr/bin/log", @"/usr/bin/vmmap", @"/usr/sbin/syslogd", @"/usr/sbin/spindump", @"/usr/sbin/usernoted", @"/usr/sbin/securityd", @"/usr/sbin/ipconfig", @"/usr/libexec/biomesyncd", @"/usr/libexec/logd"]; But when I use the newer API (that you say is identical to the old, or rather that the 'old' API translates to the newer) Then I get lots of ES events from, for example @"/usr/sbin/ipconfig" Although I know for a fact that it was muted upfront, and that calling the muting API returned successfully. The strangest thing is, if I revert to the deprecated API - and that is ALL that I do, just change a single line of code -- then these events are NOT received anymore. Same array, same executables, no other change. I don't know how to extract a simple C project to demonstrate the issue, because my code is big and quite complicated, but I will make an attempt to provide such sample.

For one thing, though, I need clarification. the "path literal" that I mute. Is it, or is it not, the path of the EXECUTABLE. My need is simple: I do not want to receive any event for specific executables (OS processes I know to be benign and whose events I do not want to evaluate and authorize). Isn't there an API to do that? must I receive some event from them and then dynamically mute the process?

Personally, I never dared breaking the ES AUTH event's deadline, because people scared me that Apple counts your failures and will revoke your ES "capability" certificate if you exceed certain limit. My two cents -- Whenever my ES client was terminated for "not answering in time" -- it ALWAYS happened after 5-7 seconds, I think - regardless of the actual deadlines of the many events I receive and handle. This stretch of time reminds me of something different with similar behavior -- When you install a daemon publishing an XPC service (place a .plist definition file in /Library/LaunchDaemons/com.mycompany.mydaemon.plist), then if your daemon fails to launch and initialize itself and be ready to receive XPC calls -- it's being kicked/terminated by launchd, after about the same 5-7 seconds. But maybe that's my imagination...

I'm struggling with the very same issue and I think this SHOULD be possible, because many MacOS APIs you use (e.g. Notification-Center notification requests) are dealt out to the notification-center daemon via XPC, so obviously it happens. In my case, my external "another" app outside the sandbox is publishing an XPC service in the user's domain, and my calls to establish the connection finally fail because default 15:21:24.427058 [0x14a846f00] activating connection: mach=true listener=false peer=false name=com.mycompany.myapp.browser.monitor default 15:21:24.427459 [0x14a846f00] failed to do a bootstrap look-up: xpc_error=[159: Unknown error: 159] Have you been able to overcome this obstacle?

(Blushing) what does 'DO' stand for? And what architectural recommendation would you give for making XPC client / service implementation be a bit more "flexible" and not fail with exceptions and crashes just because a client did not implement the whole @protocol ? I found out the hard way - (and not without your kind help) along the last 3 years that NSXPC is implemented in quite limited way, and not everything you expect from Obj-C messaging works as expected -- only one "reply block" "reply block" must be last argument. "reply block can only be called once not any class can participate in the @protocol supported by an NSXPCInterface, and you must manually add classes you need. Now this... "respondsToSelector:" drops the XPC connection when something isn't implemented etc. I wish at the very least the NSXPCConnection documentation would cover these limitations as requirements, so I wouldn't have to apply "normal MacOS thinking" again and again, just to reach the end of implementation and stumble on the limitations like this. It is both frustrating, and pushes into bad design. I would design very differently had I known these things BEFORE I started implementing.

I'm trying, I'm trying, but it's really hard to do in my case. I'll explain.. This tiny menu-bar status-item app serves only as a "mouth" for a product comprised of about a dozen system-level daemons (sigh, a security tool) including EndpointSecurity client, many daemons that can't inform the user because they're not connected to any user-session or UI session etc. I found the hard way that Notification-Center is hardly usable from a "Global-Agent" or even "User Agent" which is not a "Bundle" but a unix-style binary -- so everyone speaks to the user via this tiny app via XPC - and the app converts stuff to "UI" (both in a small normal AppKit window, and via Notification-Center user-notifications. Because of this - its "function" is hardly controllable from within - it just reacts to XPC calls, and turning off stuff or digging for the "timing" of the issue is very hard to do. Our other daemons look for this app to launch - and then start chirping along on the XPC, sending it "progress" reports, summary of action reports messages the user and so on, so the timing between launch (and XPC Listener resume) to the time the dialog pops -- is clattered with many unsequenced XPC calls from different processes.

I also created and submitted an enhancement request: FB16070313 to be able to reset the TCC entry for "Local Network Access". I now see that all my submissions from the last 5 years have been completely neglected, so I don't have high hope here - nevertheless. The Eskimo recommends? I submit.

I have created and submitted a new request: FB16069295 with mostly the same definitions of my question here. Since I haven't been able to resolve the issue since then, it became even more important. Actual users (tens of thousands of them currently need to Allow/deny the Local-Network access for my App.

Once I remember there was some tool that you would run your binary through, and it would tell you which MacOS APIs you have used... This was decades ago, maybe on the move from Carbon to Cocoa, or from 32 to 64 bit, or maybe even from MacOS to iOS... can't recall now. Does such tool exist ? In my case, anything beyond very basic "Foundation" should be really minimal - so just looking at the list may be useful, This app does almost nothing when launched (merely makes XPC connections to other components of the product, and receives some "configuration" data via these connections. Then - when required by other components, it emits Notifications (via Notification Center) and updates a small popover window "data model". That's all. What could be this thing?

Playing hide and seek with my code to catch the API that indirectly needs "Local Network" permission is not only tedious - it's almost impossible Once the Dialog is up - a TCC entry is created in the TCC database records - no matter if the user answers yes or no, or doesn't even answer at all. It is created even if you cut the electricity to the Mac. From then on, no dialog will ever pop. The app gets a "NO" for Local network access, and works with that. I have NOT found a reasonable way to reset this TCC entry, and as far as I understand - there isn't any. The best I could till now - is to erase the user account and recreate it. But then --- reinstalling all the stuff there, and debugging with another subset of the code - this becomes insanely cumbersome. This is really annoying!!! how can any API require permission, without having at least a name, or some footprint in the OS logs? This is Mac and not IOS, and the available APIs are quite extensive. I'd like to know at least WHY my app wants this? I can't think of anything "network" in my app to start with! isn't this something that should be mentioned in the documentation somewhere?

Thank you very much. I'll try your suggested approach as well. Seems interesting. I think the inefficiency comes from the basic functionality of the APIs I found so far ( in MacOS Cocoa). They all assume that I'm interested in the actual items, and they fetch/pre-fetch meta-data for each file/item whereas all I need to do is COUNT. Furthermore - all existing APIs that support recursive scan of directory hierarchies - are AGGREGATING the results along the scan, and won't return until they have the full list of items. This of course both burdens CPU work and Memory consumption. I never thought to go to Posix APIs until now, because I dislike them (A True Mac programmer since 1987) because they're all synchronous and plain dumb - they do NOT cover the rich and strange behaviors and attributes of modern file-system. At least in the past, apple had its low-level FileSystem APIs exposed, and I could work magic with them. Since then the FileSystem has changed, but I don't know which APIs exist today. By example, I wrote the following naive code: static NSUInteger totalCount = 0; NSDirectoryEnumerator *dirPathEnumenumerator = [fm enumeratorAtPath:@"/Users/me/Documents"]; NSString *currRelativePath = nil; // local path while ( (currRelativePath = [dirPathEnumenumerator nextObject]) != nil) { NSDictionary *fileAttributes = [dirPathEnumenumerator fileAttributes]; if (![fileAttributes[NSFileType] isEqualToString:NSFileTypeDirectory]) totalCount++; And for my ~100,000 files Documents folder, it took about 6 seconds to run. I then wrote it differently - using SHALLOW directory enumeration, and instead of recursing, I dispatched "need to scan" code-blocks onto concurrent NSOperationQueue, thus removing recursion (and stacks) and also spreading the task over several cores -- like this: static NSUInteger totalCount = 0; static NSFileManager *fmm = nil; static NSArray *requiredProperties = nil; -(void)countFilesInDocumentsFolder { NSOperationQueue *q = [[NSOperationQueue alloc] init]; q.maxConcurrentOperationCount = 5; q.qualityOfService = NSQualityOfServiceUtility; q.name = @"file counting queue"; dirFullPath = @"/Users/me/Documents"; NSURL *topURL = [NSURL fileURLWithPath:dirFullPath]; if (fmm == nil) fmm = [NSFileManager defaultManager]; if (requiredProperties == nil) requiredProperties = @[NSURLNameKey, NSURLIsRegularFileKey ,NSURLIsDirectoryKey, NSURLIsSymbolicLinkKey, NSURLIsVolumeKey, NSURLIsPackageKey]; [self countFilesInDirectory:topURL usingQueue:q]; [q waitUntilAllOperationsAreFinished]; NSLog (@"Total File count in directory: %@ is: %lu", dirFullPath, totalCount); } -(void)countFilesInDirectory:(NSURL *)directoryURL usingQueue:(NSOperationQueue *)queue { [queue addOperationWithBlock:^{ NSError *error = nil; NSArray<NSURL *> *itemURLs = [fmm contentsOfDirectoryAtURL:directoryURL includingPropertiesForKeys:requiredProperties options:NSDirectoryEnumerationSkipsHiddenFiles error:&error]; if (error) { NSLog(@"Failed to get contents of: %@, Error:%@", directoryURL, error); return; }; for (NSURL *url in itemURLs) { NSDictionary<NSURLResourceKey, id> *fileAttributes = [url resourceValuesForKeys:requiredProperties error:&error]; if (error!=nil || fileAttributes == nil) { NSLog(@"Failed to retrieve attributes for:%@ Error:%@",url, error); continue; } if ([fileAttributes[NSURLIsDirectoryKey] boolValue]) { [queue addOperationWithBlock:^{ [self countFilesInDirectory:url usingQueue:queue]; }]; } else { if ( [fileAttributes[NSURLIsRegularFileKey] boolValue]) totalCount++; } } } }]; } And this one - although lengthy - took about 0.45 sec to do the same job (even a little better). So... with my ***** of a Mac and a fast-as-hell SSD, I am still very far from satisfied. I'll go down the POSIX rabbit hole and see what goes. Thanks! If I find the POSIX faster than my current thing, I'll accept your answer as the best :)

[quote='796747022, endecotp, /thread/760256?answerId=796747022#796747022, /profile/endecotp'] one [/quote]

Thanks for the info so far -- it is really valuable. However - few questions remained un-answered for me (in similar but not identical scenario) Should the set of allowed classes be applied to the "exported interface" on both Client and Server side of the XPC connection? only Server side? only Client side? Your question involves your own custom class. But what Cocoa classes are acceptable by default (without calling the "exportedInterface.setClasses", and what should be manually added ? Where is the list documented? B.T.W an ObjC version of the same snippet would be nice. 3, In my experience both server and client are Obj-C and I don't have any custom classes - only Cocoa classes), the behavior of XPC is very unclear. I experienced exceptions that claim exactly that - "unsupported classes" but only sometimes it fails, and sometimes it passes OK, and I can't understand when and what and why. For example, I removed NSError NSAttributedString classes from my XPC protocol, and that removed the intermittent exceptions. Why? Last, you asked about logs have you found relevant log messages related to this? Where to look for them? In my case, the only "logs" were .ips crash-logs...

Sorry, the tagging is wrong of course, but I can't see any UI here to change it. why did it chose "GameKit" Time and again I clicked the "AppKit". That's frustrating.

Thanks again. Indeed I missed the sentence "A method can have only one reply block." in the old archived documentation - but that same sentence also says: A method can have only one reply block. However, because connections are bidirectional, the XPC service helper can also reply by calling methods in the interface provided by the main application, if desired. Which brings me to the original question -- HOW do I do that? My "players" aren't an App and its helper-service, but rather independent, resilient system daemons and global agents that need communicate, in all directions. The dual XPC connection I'm maintaining now, is just cumbersome. Each "product shutdown" flow is an ugly nightmare, and recovering from one-side-crash looks different on either sides - which is ugly too. Bidirectional XPC connections look like the right thing to me. I found and downloaded the recommended 2012 WWDC session from here: https://archive.org/download/wwdc-2012-sessions and watched it carefully twice - but there too - it is only HINTED for a split second, that the connection is bidirectional and both sides can send messages - and immediately the hint is removed from screen, and replaced by that single reply-block technique. There is a tiny gap here I need to bridge. I already have a live NSXPCConnection, both sides agree on the same protocol, the "client side" obtains a "remote proxy" and the "server side" exports an object and assigns them to accepted incoming connection. Then client sends messages to the service. How can the client-side create an "exported object"? can it also assign an NSXPCInterface and exported-object to its NSXPCConnection when it connects to the service? and how would the service get the proxy if it wants to call-back to the client? If the docs say NSXPCConnection is bi-directional, SOMETHING must be said somewhere regarding the use of this feature. As in your hinted novel - I think I'll just go on and open the "disused lavatory" carrying that "Beware of the Leopard" sign, to find the demolition order for my house :( One things keeps me uneasy. In the full decade of NSXPCConnection, hasn't anyone need bi-directional IPC? Why is it only I'm looking for ways to do it? Design-wise, Is it something wrong with my ideas?