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"

Done: FB15568200

I have a similar problem, but with a well known App... Google Chrome. I rejected the access to local network by mistake, and the toggle in "System Settings > Privacy & Security > Local Network" doesn't have any effect when I enable it.

Steps to reproduce:

1. Installed Google Chrome App in macOS 15.2.
2. Opened Chrome and tried to access a local network address
3. Got a prompt asking if Chrome should have permission to access the local network, replied No
4. Go back to "System Settings > Privacy & Security > Local Network" menu and tried to re-enable the local network access and it didn't work
5. Uninstalled Chrome using AppCleaner (also deleting all the related files from "~/Library/Application Support/Google")
6. App didn't disappear from "System Settings > Privacy & Security > Local Network" policies list.
7. Rebooted and the App is still listed there
8. Reinstalled Chrome and it didn't ask for permissions anymore
9. Tried to disable and then enable the local network access, it didn't work.

Tried creating a second user account, ran Chrome, accepted the permissions, worked. Tried logging in in Safe Boot with my user, to check if the toggle would have any effect, but also didn't work.

Also tried this: https://superuser.com/questions/526183/remove-applications-from-location-services-in-security-privacy-on-mac-os-x-10

But it doesn't work because apparently in macOS Sequoia we don't have permissions to edit any of those files in "/var/db/locationd/" even with sudo. Tried enabling the root user (https://support.apple.com/en-us/102367) to see if I could get around it, didn't work.

I believe this is clearly a bug that must be addressed by Apple. Would help if we could just have a way to remove the permissions for each App in that list, or if the tccutil would also reset the Local Network policies.

This is the only way to reset it:

https://forums.macrumors.com/threads/local-network-access-nightmare.2448144/post-33698401

We have seen similar results to those seen by the OP and others. We have submitted a separate FB incident (FB16512666) with our information and observations. For the most part it follows what others have said, though we have more to add on the inconsistency between UI and the actual permission granted. There are two related screenshots for this, the first of which shows the UI when the Local Network permission is OFF for our application called "Mbox": In this image you can see 10 instances of an application called "Mbox 5.2", circled in red. To the right you can see the contents of the /Library/Preferences/com.Apple.networkextension.plist file that stores the data related to the permission granted via the UI. This plist holds entries for each of the 10 instances of the application in the UI, each showing the same BundleID (com.PRG.MboxExtreme in this case) and showing a unique file path. I have drawn a red arrow pointing to one instance that has the application name "Mbox 5.2" that matches the name shown in the UI, and the state of the "DenyMulticast" boolean for that instance is circled in red - it is set to YES, which represents the result of the toggle switch in the UI being OFF. In the same image I have drawn a yellow arrow pointing to a separate instance with a different file path (and application name), and circled that instance's DenyMulticast key:value pair, which is NO, opposite to that for the other instance.

This next screenshot shows the result of toggling the UI to grant permission to the app. As noted by others, toggling any one instance of the application called "Mbox 5.2" causes the toggle for all instances to be in the same state. In the image you can see that the same instances are highlighted in the plist file, with the DenyMulticast value for the first instance now being set to NO:

In the first case outlined above, with permission turned off, the instance of our application called "Mbox 5.2" is NOT able to receive UDP multicast data, but ALL other instances are able to receive the same data. In the second case, with permission turned on, ALL instances of the application can receive UDP multicast.

Based on what we've seen, there's an obvious inconsistency between what's shown in the UI and what the actual permission state is. The UI seems to follow and only affect the first instance of the application. Either each instance of the application would have its own instance of the permission, or like other permissions there should be only one instance for each unique BundleID and the value affects all applications with that ID.

In addition to the inconsistency between the UI and actual operation, we have also seen in testing that even when granted permission for Local Network to an application, that after a reboot the application is unable to send/receive UDP multicast. To resolve this issue you can quit the affected app (or apps) then toggle their Local Network permission off then on again, and then relaunch the application. This state seems to hold until the next time the computer is rebooted. It is our suspicion that this issue is related to having multiple instances of the same application on the computer and the lack of consistency between UI and the plist. But we don't have any evidence of this yet.

I'll also repeat what others here and in other related posts have stated, that the concept of Local Network permission ought to have the means to test/debug the current state and also the ability to remove or reset the permissions in total or per app, As best we can tell, these items are already reported as FB8711182 and FB14944392 respectively.

Still waiting for solution.