How to reset (remove) apps from "Local Network" privacy settings?

After some more digging, I suspect that the information is stored in the various /Library/Preferences/com.apple.networkextension.….plist files. I tried to alter the file, but that led to the system refusing to boot (fortunately, this was done in a VM). I wonder if there are APIs to access/alter these files in a way that won't damage them.

I’m in the process of updating the Local Network Privacy FAQ and, as part of that, I’ve researched this question in depth. Currently there’s no good way to reset local network privacy on the Mac (r. 134842755). Personally, I get around this by running my program in a virtual machine (VM). To retest, I restore the VM from a snapshot taken before I installed your program.

Alternatively, create a new user account and run your test there. Remember that macOS maintains separate local network privacy state for each user account.

the Local Network permission isn't even managed by the TCC system

That’s correct. TCC manages many but not all of the privileges shown to the user in System Settings > Privacy & Security. Local Network and Location are the two critical outliers that I’m aware of.

Oh, and that’s one of the reasons why tccreset won’t fix this.

After some more digging, I suspect that the information is stored in the various [Network Extension preference files]

That’s very much an implementation detail. You shouldn’t rely on the presence or format of those files.

fortunately, this was done in a VM

Oh, you already have a VM for testing this? Well, that makes it easy.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you for looking into this, Quinn.

(The VM I had used had no snapshot (stupid of me), so when I borked it, I had to ditch it and start over, installing a new system from scratch, and then installing Xcode and all the other tools again, which took me quite a while that I would have liked to avoid. Also, I'm glad to be using VMware on a Intel so that I can make snapshots, as the support on Silicon is still a bit ... lacking in this regard :)

Ah, creating a new user - of course! I should have known that.

Also, there's another related issue:

In my testing with a fresh VM I noticed that when I download two versions of my app (release and beta, both signed with my dev ID and notarized, and then both downloaded from same server and thus quarantined), I found that macOS prompted me twice for the "Local Network" permission, i.e. one for each app version I launched. That's different from TCC permissions, where a single permission was always applicable to ALL versions of an app with the same signing ID. And even worse: Even though the System Settings then list the app twice, both use the same name even though I had named them differently, and right-click - Show in Finder shows the SAME app instead of the two separate apps that required to be acknowledge when they accessed the network. So, that appears to be another (minor) bug, though I don't know which would be the proper behavior: Require the permission only once for all apps with the same signing ID, or require them for each version but then list them also properly as individual instances with their own names and file system paths.

Can you confirm this misbehavior?

as the support on Silicon is still a bit ... lacking in this regard

Virtualization framework on Apple silicon recently added snapshot support, but it certainly requires careful integration on the part of the virtualisation product itself. My current process is to keep the VM shut down. I can then clone it and boot the clone for testing. The clone is cheap and fast due to APFS, and the boot is pretty speedy due to Apple silicon.

Also, there's another related issue:

The exact mechanism used to identify apps is complex. There are at least four factors involved:

• The bundle ID

• The path to the app

• The designated requirement [1]

• The main executable UUID [2]

In the case of your release and beta products, are any of these the same?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] See TN3127 Inside Code Signing: Requirements.

[2] See TN3178 Checking for and resolving build UUID problems.

Bundle ID and designated requirement are all the same. Path is not, as mentioned above. UUID is also different, as they're different builds.

But that just confirms what I suspected: That the privacy permissions are separate for different versions of the same app.

However, my concern was that even if that's done on purpose, then System Settings.app / Privacy / Local Network shouldn't show the SAME app version multiple times but should list separate apps, i.e. the different versions it has recorded so far.

To illustrate:

... Here I was going to reproduce the issue and show you a screenshot of the Settings app showing multiple instances of the same app, each pointing to the same path. But now that I had re-installed Sequoia and run each app version, they do not multiply in the Local Network list any more as they did before. And the screenshots of this effect that I had done before in the VM are lost when I borked that system. Sigh.

Alright, let's drop this for now. I'll get back to this thread should I encounter the problem again.

Actually...

I just read https://developer.apple.com/forums/thread/737416 which confirms that it's possible that multiple app instances are listed. So you know about this effect.

Then let me get back to the issue with that: If you have multiple app instances listed under "Local Network", and if you right-click on them to Reveal them in Finder, you'll get the SAME app revealed each time. This means that the code that lists the multiple instances in the Settings pane does not keep them separate for the sake of indentifying them to the user, which is clearly a bug. Agreed? I'd write a bug report but since I fail to be able to reproduce this, I believe it wouldn't get even any attention. But if you do, could you do something about it, please?

Later

Ahh - it appears that app versions with the same Signing ID are listed as one instance. Only if the Signing ID is different, e.g. for MAS vs. Indie releases, it's listed multiple times.

Adding to my last "Later" comment:

No, sometimes, even new versions with the same Signing ID get added as unique entries. I can't make sense of when this happens and when not, but here's the result:

And all 3 "Find Any File" items point to the same file and not, as expected, to the different versions that are all on the disk, at different paths.

While it’s tempting to try to understand how this is implemented, my advice is that you focus on the user-level behaviour. If there are reasonable user-level scenarios where the local network privacy messes up — either the core feature or the UI in Settings > Privacy & Security — then that’s bugworthy.

If you do file a bug, please post your bug number, just for the record.

And I recommend that you try these out in a fresh VM, because it’s not unexpected that the Mac on which you build your product we be confused.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

BTW, there's another issue with the new Local Network permission: There's no way to provide a "UsageDescription" for it, like for all the other ones, in Info.plist. (At least, Xcode 16.1b3 doesn't list any under the "Privacy - …" keys)

Yeah there is. See FAQ-11 in the Local Network Privacy FAQ.

In Xcode it shows up as Privacy - Local Network Usage Description.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Well, that's just the thing: That text is not displayed in my tests. Instead, it shows a generic msg. In both 15.0.1 and latest 15.1beta.

Here's the prompt that appears and the Info.plist of that very app:

This is working for me, on both macOS 15.0 and 15.1b6. Here’s my property list:

% plutil -p TriggerLocalNetworkPrivacyAlert.app/Contents/Info.plist
{
  …
  "NSLocalNetworkUsageDescription" => "For testing purposes only."
  …
}

and here’s the result:

Are you sure that the build setting has made it through to your Info.plist intact?

Are you localising this string? [1]

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] I’m not btw. My test app has a single localisation and the value displayed in present in the main Info.plist.

Thank you for double checking that it should work on macOS.

yes, I showed the plist of the app that I had launched. Not localizing the text. App is signed with dev id and notarized. Do I need special entitlements for this to work? App is not sandboxed if that matters. Can you share the app that you verified to work so that I can compare?

Nevermind - I found a test project myself (my own SSDP Browser on github). There, indeed, setting the NSLocalNetworkUsageDescription does work.

After verifying that, I checked my main app FindAnyFile again.

Lo and behold! After changing the app's bundle ID, it suddenly worked!

Now, the issue here seems to be:

The app was already known to macOS BEFORE upgrading to Sequoia. When running it on the updated Sequoia for the first time, the prompt for Local Network appears, but it's showing the default and not my custom usage message. However, if I install and run the app for the first time on Sequoia (which I simulate by giving it a new bundle ID), it does show the custom message.

So, I still believe that there's a bug in macOS 15.1, by which is doesn't show the app's NSLocalNetworkUsageDescription if it has been installed before, or possibly if there are also OLDER versions of the app around that do not contain the NSLocalNetworkUsageDescription, meaning that this information is cached somewhere else by macOS and is not updated with the LATEST app's information.

Can you tell me where macOS gets the NSLocalNetworkUsageDescription text from? Apparently, it's not reading it directly from the running app's Info.plist but from somewhere else, e.g. the LS database? If it's that, I could dump that to check why it doesn't get updated - or maybe it's updated there but the macOS code looks for the first app instance in the LS database instead of looking for the latest. Something is clearly wrong there and I'd like to help figuring out what, so that I can provide a clear and reproducible bug report.

Aaand I've confirmed it: After restoring the VM to 15.1beta where FAF hasn't been launched under yet, then deleting all copies of FAF (which are easy to locate with my "Launch Services" app) and then installing the single new version that contains the new key, I finally see the new usage description.

So my suspicion was probably correct: When prompting the user about the Local Network permission, it doesn't fetch the NSAllowsLocalNetworking value from the running app but from Launch Services, and in a way that doesn't ensure it's looking for the data from the latest or running version of the app, which it should.

Which isn't really a new issue when I think about it - I believe I've noticed more than once in recent years where Finder or other services failed to register new information from the latest version of an app but instead use data from outdated versions that are still installed elsewhere.

I wonder if this is even worth a bug report. It might be behaving "as designed".

I wonder if this is even worth a bug report.

Please do file a bug about this. None of these issues come up on iOS, where it’s only possible to install a single copy of any given app, so it’s important that the engineer team consider these cases properly.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"