> Chromium browsers (Chrome, Brave, Edge, Island, Arc) copy their own app bundle into a random temp folder at launch so the code signature survives in-place updates. macOS keys the Local Network decision to that random path, so the next launch looks like a brand-new app.

OH DEAR GOD that explains so much other cursed behavior, including the "do you want to allow google chrome helper to show notifications" always reappearing. or teams. or anything that does autoupdates.

> Nothing on a typical Mac needs this permission except a printer or scanner utility, a media server, or a LAN-discovery tool, and those you answer once and they're done.

This is wrong. Browsers and media players need it because that is how multicast discovery for stuff like Chromecast works. Spotify, same thing. And Steam plus virtually all games with LAN multiplay for the same reason. Did I note already that Steam also has an autoupdater and so does Spotify and... argh.

Apple really needs to fix the very first point, preferably in a way that doesn't force app developers to ship a "helper" binary.

(Side note: it might even be the case that opening the file picker may be enough, if you got network-discoverable paths in your Finder Locations sidebar, but i'm too tired to test that one out...)

That explanation sounds wrong to me. I've written my own implementation of macOS signing logic. TCC doesn't usually tie permission grants to paths, it ties it to the designated requirement of the app bundle, which in turn is usually an indirection through the code signing certificate identity. The whole macOS architecture is designed to let you drag apps around and treat them as files, it's not a UNIX where installation path is meant to matter.

I just dumped my TCC database and the entries are mostly not path tied. The Chrome entry is as expected a bundle ID+designated requirement. Unless the local network permission inexplicably uses a different permissions engine, that statement is a misdiagnosis of what's happening.

     $ sudo sqlite3 "/Library/Application Support/com.apple.TCC/TCC.db" "SELECT hex(csreq) FROM access WHERE client = 'com.google.Chrome';" | xxd -r -p | csreq -r /dev/stdin -t

    (identifier "com.google.Chrome" or identifier "com.google.Chrome.beta" or identifier "com.google.Chrome.dev" or identifier "com.google.Chrome.canary") and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = EQHXZ8M8AV
In other words, the permission grant applies to any Chrome channel as long as it's signed by Google's team ID.

Even for chromecast and spotify I never want or use these features, and if I am not turning such a feature on I never want to be asked about a permission related to it, as a user. If I am turning a feature on or I am trying to use chromecast, THAT is the time to prompt me about it

It's a user experience thing. They don't want to show the cast icon to the user if there is no device present to cast to.

(I think both POVs are valid, but the actual solution should be for a proper OS-level interface to provide mDNS discovery...)

The permission keying off of a temp folder feels so broken. I don't know whether Google / Chrome deserves the blame for the weird hack of running an app from a place the user never specified or Apple the OS for making such a hack necessary and not giving the permission system a way to understand the canonical user installed app as the source of the request.