Hi Quinn, We are indeed trying to ensure our daemon is only accessed by our client. We do have hardened runtime and kill via -o runtime in our codesign use. We have some old code that checks our signing requirement though (pre-macOS 13) but it seems we can replace that old code with setCodeSigningRequirement(_:) instead. I wasn't clear from the documentation on setCodeSigningRequirement whether that was the case. Thanks, Dave

Hi @DTS Engineer I wanted to reopen the issue raised here are there has been a significant change with the release of macOS 15.6 We have seen a high failure rate with our content filter missing flows again. It also seems to cause wider network connectivity with a lot of random connection failures leading to slow network access. Are there any changes in macOS 15.6 which we could be falling foul of? Regards, Dave

Ok, but I want to avoid spamming the user with alerts. We could show a warning that the filter is not active and provide the user a means (eg button) to trigger that alert, that will avoid spamming.

@DTS Engineer I've been testing this issue against macOS 15.2 and it seems the problem with the built-in firewall may have been resolved. There's nothing obvious from the release notes though. Can you confirm if the problem has been addressed (or not)?

Bug report submitted, FB15833538

Hi, thanks for the feedback. QQ, just to clarify. Your "Yes" means this should be supported but performance could be an issue, right? Is our approach to using an app activated content filter reporting to a daemon connected via XPC unsupported? Yes. You have to be careful about performance here, but the basic concept is sound. I have been able to test the disabling the built-in firewall and after a restart to flows are received normally by our content filter. This would seem to confirm we're hitting the issue reported by others (FB15699871). I'll work on preparing a bug report and will post it here. Thanks for the help, Dave