@kaunteya that is not correct. Internally it may be either a NSLayoutGuide or an NSView. The Any? "hack" is necessary since there is no protocol to express *anchor properties. But in practice it will be an NSLayoutGuide most of the time unless you customize window's content view or play with its view hierarchy.

The SO_NET_SERVICE_TYPE option and its siblings StreamNetworkServiceType, NSStreamNetworkServiceType, kCFStreamNetworkServiceType configure Layer 1/2 QoS priority. In case of Wi-Fi they set 802.11 User Priority (UP). Whether it actually gets set in the actually transmitted frame depends on whether the OS trusts your application. AFAIK for iOS/iPadOS this feature has to be enabled via MDM for a generic app. Apps made by Apple and some other vendors, like Cisco, are trusted without this permissions. What happens next depends on your network equipment (routers, switches, APs etc) and its configuration. Some may translate received 802.11 UP into DSCP according to some mapping (either via RFC8325 or by whatever policy conceived by network admins). Additionally, you can set Layer 3 QoS via the DSCP (RFC 2474) field of an IP frame either by setting IP_TOS directly or setting the IP_HDRINCL socket option and supplying custom IP header. Don't get confused by option's name (TOS): it's exactly the same bits of the IP header. Treat it as DSCP. See the '-K' and '-z' options in ping.c from Apple opensource for usage examples.

FWIW, proposals on iPhone with iOS 15.2.1: Phase 1: ID:ENCR/PRF/D-H IKE:AES-CBC-256/SHA2-256/MODP-2048 IKE:AES-CBC-256/SHA1/MODP-2048 IKE:AES-CBC-256/MD5/MODP-2048 IKE:AES-CBC-256/SHA2-512/MODP-2048 IKE:AES-CBC-256/SHA1/MODP-1024 IKE:AES-CBC-256/MD5/MODP-1024 IKE:AES-CBC-128/SHA1/MODP-1024 IKE:AES-CBC-128/MD5/MODP-1024 IKE:3DES-CBC/SHA1/MODP-1024 IKE:3DES-CBC/MD5/MODP-1024 IKE:DES-CBC/SHA1/MODP-1024 IKE:DES-CBC/MD5/MODP-1024 Phase 2: ID:ENCR/PRF IKE:AES-CBC-256/SHA2-256 IKE:AES-CBC-256/SHA1 IKE:AES-CBC-256/MD5 IKE:AES-CBC-128/SHA2-256 IKE:AES-CBC-128/SHA1 IKE:AES-CBC-128/MD5 IKE:3DES/SHA2-256 IKE:3DES/SHA1 IKE:3DES/MD5

It uses the older SMLoginItemSetEnabled.

Okay, I seem to get to the bottom of this. One detail that I missed is that I run homebrew installation process as a non-admin user and group: $ dscl . -read /Users/brew dsAttrTypeNative:IsHidden: 1 PrimaryGroupID: 801 RealName: Homebrew RecordName: brew RecordType: dsRecTypeStandard:Users UniqueID: 801 UserShell: /usr/bin/false $ dscl . -read /Groups/brew GroupMembership: brew PrimaryGroupID: 801 RealName: Homebrew RecordName: brew RecordType: dsRecTypeStandard:Groups When Homebrew installs the app, I end up with a bundle owned by brew:brew. Launching the app with login user will display the warning only once, but the quarantine attribute will remain with unchanged value regardless of how many times I restart it. However, if I chown the app to the login user before the launch, I will get the warning again (even if I already got one when it was owned by other user) but this time attribute's value will get cleared. Do you think I should file a bug?

Hmm, why would writability of /Application have any effect though? The installation process run via Homebrew by a non-admin user[1], in a nutshell, uses a shell script that downloads app's archive, unpacks it and then uses sudo[2] to move it to /Applications. As a result, I end up with a brew:brew owned app in the /Applications directory with the quarantine attribute assigned and set. When I run the app via my main admin user account and agree to the dialog (which is shown exactly once, on the first run only) I expect the quarantine attribute to get cleared for my main admin user. The login item is added to the gui/ domain so I expect launchd to consult the appropriate database when checking whether the login item is allowed to run. The way I understand gatekeeper process (root daemons) and quarantine attribute (values are per-user[3]), neither writability of /Applications nor /Applications/Maccy.app should have any effect. [1]: $ sudo -u brew id uid=801(brew) gid=801(brew) groups=801(brew),101(access_bpf),12(everyone),20(staff),61(localaccounts),701(com.apple.sharepoint.group.1),100(_lpoperator) [2]: On my machine, sudoers is set up such that plain sudo uses my main admin user account and not root via the runas_default and runaspw settings. [3]: If you run the app and agree to the warning then quit it and chown it someone else, it will display the warning again on the next run. So I'm not sure whether the actual quarantine value is preserved per file owner, per process owner or a combination of both.

Interesting. I suspect that’s because the Applications folder is only writable by admin But the user that's launching the app is an admin (me). Anyway, why does writability of /Applications or even /Applications/.app affects the behavior? Isn't the actual value of the quarantine attribute stored in a db somewhere else, per-user?

FWIW I have file the bug via Feedback Assistant: FB11958573

Are these agents owned by Apple or by some other 3rd party?

I since found that /Library/Filesystems is user-writable (but requires root). In order to expose mount_<filesystem> to autofs, the following directory can be added: /Library/Filesystems/<filesystem>.fs └── Contents └── Resources └── mount_<filesystem>

Thank you. Assuming I know what I'm looking for (I'm debugging why macOS does not display my Wire-Area DNS-SD services), can I calculate the hash separately to search the logs?

FWIW the Wi-Fi network has the "Private Wi-Fi address" option set to Fixed but "Limit IP address tracking" set to Enabled. I'm an iCloud subscriber and iCloud Private Relay is on.

Thank you Kevin. I just found that there is the mDNSResponder configuration profile provided by Apple, which has the following payload: <key>PayloadContent</key> <array> <dict> <key>PayloadDisplayName</key> <string>Logging Payload For mDNSResponder/srp-mdns-proxy.</string> <key>PayloadIdentifier</key> <string>com.apple.system.logging.ED3E600C-83D8-44D0-BF5B-8A7F889CDBDE</string> <key>PayloadType</key> <string>com.apple.system.logging</string> <key>PayloadUUID</key> <string>ED3E600C-83D8-44D0-BF5B-8A7F889CDBDE</string> <key>PayloadVersion</key> <integer>1</integer> <key>Subsystems</key> <dict> <key>com.apple.mDNSResponder</key> <dict> <key>DEFAULT-OPTIONS</key> <dict> <key>Enable-Oversize-Messages</key> <true/> <key>Level</key> <dict> <key>Enable</key> <string>Info</string> <key>Persist</key> <string>Info</string> </dict> <key>Privacy-Enable-Level</key> <string>Sensitive</string> </dict> </dict> <key>com.apple.mdns</key> <dict> <key>DEFAULT-OPTIONS</key> <dict> <key>Enable-Oversize-Messages</key> <true/> <key>Level</key> <dict> <key>Enable</key> <string>Info</string> <key>Persist</key> <string>Info</string> </dict> <key>Privacy-Enable-Level</key> <string>Sensitive</string> </dict> </dict> <key>com.apple.srp-mdns-proxy</key> <dict> <key>DEFAULT-OPTIONS</key> <dict> <key>Enable-Oversize-Messages</key> <true/> <key>Level</key> <dict> <key>Enable</key> <string>Debug</string> <key>Persist</key> <string>Info</string> </dict> <key>Privacy-Enable-Level</key> <string>Private</string> </dict> </dict> </dict> </dict> </array> I wonder whether the value of <string>Sensitive</string> alongside the fact that the profile is signed by Apple allows to unmask the redacted parts in the logs. Update Looks like it worked! I understand it did not enable compile-time exclusions, but other than that seems to work. Or do I miss something?

In the logs I see: Question for _smb._tcp.home.arpa. (PTR) assigned DNS service -- id: 7, type: ODoH, source: nw, scope: uuid (353A4F9C-CEF5-4CEE-93AD-4697BB0318D7), interface: /0, servers: {}, domains: {}, attributes: {a-ok, aaaa-ok, fail-fast, allows-failover}, interface properties: {ipv4, ipv6}, resolver config: {provider name: oblivious.r15.doh.dns.akasecure.net, provider path: /dns-query}, use count: 1 Which suggests that the mDNSResponder service attempted to forward .home.arpa. domain via ODOH, which is wrong per my interpretation of RFC 8375.

deleted