For the record, Apple's support web pages are also broken when it comes to Safari Extensions. Go to https://support.apple.com/en-gb/guide/deployment/welcome/web Type Safari Extensions in the search field and run the search. Click the link 'Safari extensions management declarative configuration for Apple devices'. => You're back to the Apple Platform Deployment home page. :-(

There are no different behaviors. As mentioned, eslogger reports the same value as the ES Framework. For the record, the "problem" is at the Endpoint Security framework level.

Feedback ticket created: FB13751871 For the record, the "problem" is at the Endpoint Security framework level. I checked with an ES client and eslogger is correctly reporting the data it's getting for the instigator field.

Actually, it was more a question regarding which options are available to an end-user to get DNS-over-HTTPS or TLS when a Network Extension (with a Data Filter Provider) is running on macOS.

Thanks. Does this mean that, in such a case, the only solutions to get DNS-over-HTTPS/-TLS are to either use your own DNS client code in your application (what Google Chrome does for instance) or to configure a DNS proxy solution (e.g. https://blog.smittytone.net/2022/05/07/how-to-do-dns-over-https-on-macos)?

Thanks.

Thanks. This at least helped narrowing things to smaller ranges of macOS 12. For macOS 11, unfortunately, the most recent versions are not listed in the page.

moving the installed files from the temporary staging area to the permanent location Do you mean moving the extracted payload files from /Library/InstallerSandboxes/A/B/C to /Applications for instance? Isn't this performed by 'shove'? In the case I described, the problem happens before the extraction of the payload files. It happens when the .pkg metadata (Distribution for instance) is about to be extracted. A step performed by installd IIRC.

DNS flows created by the first proxy are seen by the second. The gotcha here is that there’s no way to control the order in which the proxies are loaded. It looks to me that the random order is only one of the issues. Let's imagine a solution is found to fix the loading order. Those DNS flows created by the fist proxy can be DNS-over-HTTPS or DNS-over-TLS flows and none of these matches the description of the flows provided to a DNS proxy provider: "Each flow corresponds to a socket opened by an app to UDP port 53 or TCP port 53.". So, the second proxy provider would not see the DNS flows created by the first proxy. If we accumulate the order randomness and the fact that the classic UDP flows may not be seen at all by the second DNS proxy provider, I don't think this can be considered as working correctly. Am I missing something? Ref. https://developer.apple.com/documentation/networkextension/nednsproxyprovider?language=objc

Did you try this on 13.0? No, I'm running macOS 13.1 (in a VM, in case that matters).

Feedback IDs: FB11875368 - deprecated constants being used FB11873325 - registerAndReturnError: weird prototype and incorrect documentation FB11873316 - registerAndReturnError: incorrect documentation FB11873303 - missing information in online documentation FB11873295 - documentation is scary when it comes to updated plist or items. It also looks like, from what I'm observing, that the register and unregister APIs do no behave as documented. In the headers, it is written that when trying to register an already registered item or unregistering an already unregistered item, an error will be returned but the returned BOOL is YES and the out NSError * is nil. If the service is already registered, this API will return error kSMErrorAlreadyRegistered If the service is already unregistered, this API will return error kSMErrorJobNotFound Side note: it looks like that the forum code is not ready for FB# greater than 9999999 when it creates the helpful link.

Thank you very much for the detailed answer. I will check on my side if it's just the registering call that is missing. Regarding the status value, I'm apparently not the only one that is mislead because the documentation clearly states that this means there is an error: Both inline and online documentations: SMAppServiceNotFound An error occurred and no such service could be found While I'm looking into this new framework, I must confess that I find the documentation to be rather: confusing with important pieces of information being available in the inline documentation but not, AFAIK, in the online documentation. e.g the requirement for applications to be notarized to embed LaunchDaemons. incoherent with the returned values, whether a value is actually returned or not. e.g. the registerAndReturnError: method where the inline documentation states that true and false are returned, or where both the inline and online documentation state that CoreFoundation enum values are returned by this method whereas these are just possible error codes of the NSError * out parameter. confusing when it comes to the case where an embedded LaunchAgent or LaunchDaemon, or their corresponding PropertyList are updated. This is a part where a project example would provide some clarification. From the way it looks so far, the documentation seems to suggest that the version management of embedded agents or daemons could be worse than the embedded System Extensions' one and could make the whole thing unusable. I'm also surprised by the method prototypes for register and unregister which, unless I'm mistaken, do not follow the Cocoa pattern and are strongly suggesting that a NSError * is being returned. I'm surprised that there are no recommendations in the documentation regarding the POSIX permissions for the property list or embedded launch agents/daemons considering that these are usual show stoppers for the legacy agents or daemons. I'm disappointed that there are no Cocoa error domain string or error code values and that it is required to use CoreFoundation values. I filed a few Feedback assistant tickets about this.

vs. Ref. https://developer.apple.com/documentation/bundleresources/placing_content_in_a_bundle help app, helper tool. macOS. Contents/MacOS/ Contents/Helpers/ macOS framework. Versions/A/Helpers/

BTW, is there any plan to provide documentation for this event and the new Ventura events? This could be interesting to know whether there is a bug or this is the "designed" behavior. The online documentation for the new event types is currently: not helpful as there is not the beginning of basic Discussion section. buggy: the new event types are listed separately as constants. Ref. https://developer.apple.com/documentation/endpointsecurity/es_event_type_t/es_event_type_notify_btm_launch_item_add

Apparently, there are __covariant and __contravariant attributes in Objective-C. __contravariant would mean, AFAIK, that only instances of MySubClass or its super classes would be possible keys. Instances of a subclass of MySubclass would not be allowed.