Played around with this some more while writing my update for FB16077972 - here is some more detail of exactly what I'm seeing on 15.2 (24C101) When the application is inside the Applications folder: Starting a scan will trigger the Local Network Privacy alert. Once the Local Network Privacy alert has been responded to, if it is disabled, then the browser will receive a Ready update, followed by a Waiting - Denied update, However, on the initial run, before the privacy alert has been shown (i.e. the undetermined state), the browser will receive a Ready update. I never saw the Denied update though, either when the privacy alert was shown, or when it was responded to - if access is granted the browser will start to receive results. If access is denied, no further state updates are received. When the browser is stopped and started again, it will then receive the Waiting Denied update. This also applies if the browser is stopped and started while the Local Network privacy alert is being shown. Once the Local Network privacy alert has been responded to, if the application is inside the Applications folder, and browsing has started, and then the Local Network privacy state is changed, the browser does not receive any updates. For example, if Local Network privacy is disabled, it does not transition from Ready to Waiting, and vice versa. When the application is initially on the Desktop, instead of inside Applications, the privacy alert will not be triggered, and the browser never receives the denied update, and can apparently browse. Once the privacy alert has been triggered, if the application is moved to the Desktop, then it will no longer get the denied update, even if Local Network privacy is disabled, and will be able to browse. I'm kind of suspicious that it's behaving so strangely for me - from other threads I got the impression that people had a bit of trouble with it, but not as much as this.

About to update FB16077972 - I get exactly the same result on a 15.2 (24C101) VM - if the test app is on the Desktop the local network alert does not trigger, and kDNSServiceErr_PolicyDenied is never received. If the app is moved to the Applications folder, then it behaves as expected.

One more piece of tangentially relevant data - the technique described in https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy#Trigger-the-local-network-alert does trigger the alert for me, regardless of whether the app is installed in Applications or not.

My build environment was Sonoma 14.7.2 (23H311), Xcode 16.1 (16B40), and my target VM was running Sequoia 15.1.1 (24B2091)

So ... using your exact steps, I get exactly the behavior you describe. But if I skip this step: "In the VM, I moved the app to Applications folder" then I just get the "Ready" state. I never get the Local Network Privacy prompt. If I launch the app from Applications folder, and then deny or disable Local Network privacy permissions, I get the "correct" behaviour. If I then copy the app to the Desktop, and delete it from applications, I stop seeing waiting(-65570: PolicyDenied) - I just get Ready as I described. I haven't really tried to see if I'm actually getting blocked when the app is not in the Applications folder, but quite possibly not. Regardless of whether I do actually get blocked or not, the different behaviour depending on whether the app is in Applications or not seems a bit off.

Just adding kDNSServiceErr_PolicyDenied to the thread, as this is how I picked up other relevant posts

So I'm currently testing on Sequoia 15.1.1 (24B91), but I have access to the other Sequoia versions as well. Testing from an app, launching via double click. I did find some oddities when launching in other ways (e.g. invoking the binary from the Terminal - that did not seem to trigger the privacy alert - only double-clicking, or the equivalent did.

This problem now appears to be resolved for me, and on the thread linked above there are other reports that this has gone away

Currently working for me just now from Australia

It's been a while since I worked with this API, but I think what might be happening is that the AVPlayer is trying an optimistic request first ("give me all the data"), and then when it sees what the response rate is (how quickly you callback, and with how much data), it's then cancelling the request for everything, and is going to make some more reasonable ranged requests afterwards.Do you get any further requests after the cancel?