You’re relying on framework versions? Actually, no — that’s just how Chromium organizes its build. Is the local network call being made by the process running your app’s main executable? Or by, perhaps, a helper tool embedded in this framework? Chromium does network request out of Main process, in helper process in framework. /Applications/Comet Dev.app/Contents/Frameworks/Comet Dev Framework.framework/Versions/140.0.7339.20748/Helpers/Comet Dev Helper.app/Contents/MacOS/Comet Dev Helper --type=utility Here I prepared two videos with demos: Usually it is easy reproducible when open Google meet… Here I run a regular build with local network permissions, mount the new build, run rsync, and catch the issue: https://www.loom.com/share/0e1dcafdf6c645e9a34087e36414bc78 As an experiment, I also prepared two builds with a static UUID for each Mach-0 generated by my patched LLD (UUID based on hash of the filename): https://www.loom.com/share/d48b6365a4154a3ba8da8f921ad445ca In this case I cannot reproduce the issue — I tried many times. I could be wrong, You will probably see more on your side. Both repros show the same output for the commands you requested: % codesign -v -vvv --deep --strict "/Applications/Comet Dev.app" and codesign -d -vvv "/Applications/Comet Dev.app" Is this issue causing grief for your users? Yes, unfortunately, many users are complaining about this pop-up that still appears even when permissions have already been granted. Thank you for participating

Hi Quinn, Thank you for your reply! After your advice I checked the code signing, and here’s what I found: With every release of our software, we sign all binaries using the codesign utility, and each binary has static Designated Requirements that don’t change from release to release. Overall, our signing process is the same as everyone else’s, and as far as I know, the original Chromium faces the same update issues https://issues.chromium.org/issues/346505950. Moreover, Chromium developers made opinion in (https://issues.chromium.org/issues/346505950#comment31) that this local network permission is associated with the specific Mach-O UUIDs of an application rather than being tied to a code signing identity like most other TCC permissions are on macOS. The network extension subsystem listens for LaunchServices notifications about an application being installed and updates the Mach-O UUIDs it associates with an application's bundle identifier. This means that when LaunchService sees a new version of an application, the local network permission is lost for prior versions of that application, even if they're still running. In our case, with every Rsync update, a new Contents/Frameworks/Comet Framework.framework/Versions/A.B.C.D folder with the updated version is added, and the main binary changes. However, the Designated Requirements remain the same. Here’s an example of how I checked (note the version numbers: 140.0.7339.20465 and 139.0.7258.18212) find "/Applications/Comet.app" -type f -print0 | xargs -0 file | grep -E 'Mach-O' | awk -F: '!/\(for architecture/ {print $1}' | sort -u | xargs -I {} codesign --display -r - "{}" https://gist.github.com/poluyanov/78893d8d574694164d7c5d310a1dcafa It seems that the problem might lie elsewhere, and I may be missing something. I really appreciate your help with this, Quinn. Best. IP

So, repeatedly calling SCScreenshotManager increments counter "accessed your screen and system audio" ?