Local Network Privacy on Sequoia

This would be the first time that a brand new security dialog in macOS does not work as expected…

Oh wait, no.

Oh look, *yet another* TCC bug!

It's bad enough that these are security features no one asked for and are solutions looking for problems. If they worked as intended they'd be heinously annoying. But the fact that they're all that AND broken too just makes it intolerable to me.

So many hours of my life have been wasted trying to work around these and dealing with the support requests they trigger.

For one QT application, I approved local network access, but the app still did not have local network access. A reboot was the only way to solve that.

@rpmik Yes, not sure what causes it, but I’ve seen that sort of delayed access granting with other TCC stuff like Full Disk Access.

The new Local Network prompt in Sequoia is giving me so many headaches, and I suspect I'm not the only developer dealing with that.

I make an IP camera viewer which connects to local cameras and have been testing all Sequoia betas all summer without any issues; same experience from beta testers, all good.
When Sequoia launched, I started hearing from Users who could stream their cameras on Sonoma and couldn't anymore after updating to Sequoia.
The number of people affected is low (I heard from 8, out of hundreds who updated), but the issue seem to be hard to pinpoint to a single scenario:

- Some were never prompted to allow Local Network access (of course, they should have) and have had to manually enter the Settings screen to enable it;

- For some of them (4 so far) turning it ON in Settings manually still did not produce the desired effect (toggle ON, app cannot communicate);

- For one User, turning off the Firewall was the solution, though my app is distributed via the App Store (and therefore blessed by default by the firewall) and was also in the list of allowed apps (and again, the firewall was already on when they ran Sonoma with my app);

- One long-time User sent me a screen recording of his Intel Mac running Sequoia in which my app could connect to cameras in the local network (and works instead with cameras via internet) UNTIL THEY LAUNCHED another app, the 4D database (which also has Local Network access allowed in Settings). Again, I have seen with my own eyes that with my app and 4D both enabled in the Local Network panel, my app cannot see a local cameras UNTIL a different app, 4D, is launched, and after that everything works. Mind blowing, especially because the User can reproduce this each time after rebooting.

These permission issues are not specific to my app, as the Users who tested VLC for the same purpose had exactly the same experience: no prompt to allow Local Networking when opening a RTSP URL (and no stream), or the permission enabled in the Settings > Privacy > Local Network panel, without any effect.

Funny enough, if I turn off Local Network access for my app, or VLC, I still can stream my cameras. Indeed, I had already filed a Feedback (FB15176762) about the fact that the Settings UI for this feature is disconnected from the actual behavior, meaning that turning on or off the permission does not affect the app, and even after deleting the apps and rebooting one or more instances of them remain listed (screenshot of the FB here: https://iosdev.space/@cdf1982/113164866859627559).
I got a reply to this Feedback asking for a sys dump with time codes and provided it early this week, reporting also the User issues above, so at least we know Apple is aware and dealing with at least one feedback.

An additional know problem with this new "security" feature has been reported by JD Gadina with FB15174703 (screenshot here: https://mastodon.social/@macmade/113163757345604170): if an app is not the Applications folder, it skips the check and can go anywhere it wants. I reproduced it, it's true. It's not like any malware would go in a different folder, right?

Speaking of the 4D database, while googling for the odd behavior described above, I stumbled on this: https://discuss.4d.com/t/note-do-not-update-to-macos-15-sequoia/32483
Clearly the Local Network is preventing to some Users there to see their local database server as well.

Yesterday one User asked if my app was compatible with Sequoia. I replied:

> Two weeks ago, my answer would have been very straightforward: yes, I make a point to be ready “on day one” and have been for 5 years. Now, after a small number of Users reported problems with a new, buggy Local Network feature Apple has added, I must be more careful: you’ll likely be fine (98% of Users who updated were), but if you really really rely on my app, I’d wait at least the release of 15.2 (15.1 is all about Apple Intelligence and I doubt Apple will be ready with a fix for when it ships, but I might be too pessimistic).

I am not happy, luckily Users are very understanding, but this is not how I expected the last two and half weeks to go. What's even the point to beta-test during the Summer, if the GM includes breaking changes to such a fundamental aspect as networking (let's not forget the Firewall issues that Micheal had already documented with a specific post last week)?

This kind of crap, btw, is why I stayed on 10.14 for so long, in spite of the pain of everyone dropping support for it with terrible swiftness. As soon as Catalina came along and made it clear what direction Apple was going, I held off for as long as I could. Being a developer that specializes in the macOS Accessibility API, I'm well aware of how buggy and broken TCC is, and the prospect of having even more TCC permissions to stomp all over everything I'm trying to do turned me off to any new macOS. The terrible UI update in Big Sur didn't help either.

I finally bit the bullet and updated to Ventura earlier this year because it seemed like a relatively stable spot to jump to. I avoided Sonoma because so many people reported tons of show stopping bugs with it, including in minor updates. And now Sequoia sounds like a nightmare. Maybe by the time they get to macOS 15.6 or whatever it'll be usable. But every update just seems to make things worse and worse...

Yup, upgrading to Sequoia on my main iMac would be utter madness at this point, hard to believe iOS 18.1 is more polished. Basically if you take the easy road you'll be fine, but any adventures at all in anything even vaguely technically advanced and you'll probably run into something unspeakably stupid, like this.

And I wonder how much people are actually beta-testing, if it's taking as long as it is to find this stuff. It it surely not *just* all laziness and trophy-hunting, is it?

@Sebby It seems like, once again, there were significant changes shortly before the GM. So spending lots of time beta testing early on is no guarantee of finding anything.

FYI: "Local Network" permission is not managed by TCC (and therefore, "tccutil reset" won't clear it either. See here for a discussion with Quinn involved: https://developer.apple.com/forums/thread/766270

Apple published a tech note with information about this: https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy.

Some highlights:

> There’s no direct way to track down unexpected local network operations. Your best option is to remove code from your program until it stops presenting the local network alert.
> Once that happens, add smaller chunks of code back into your program to home in on the cause.

> On macOS there’s no way to reset your program’s Local Network privilege to the undetermined state.

> Local network privacy uses your main executable UUID as part of its implementation. If your main executable has no UUID, or shares a UUID with other programs, local network privacy may behave weirdly.

> There’s no general API that returns whether the current process has local network access.

This sounds like a nightmare. I'm going to avoid upgrading to Sequoia and beyond for as long as I possibly can. I stuck with Mojave for over five years. By god I'll do it again.

So I read the technote and *gasp* I actually can't find fault with the intent here; if it works, I think it's fair to argue that it actually does provide value. As always, it's the stupid implementation and the lack of a global off switch and control of the UX for devs, together with the usual manifestations of incompetence for the day-one release. They say they've started fixing the issues for 15.1, and I've no doubt they'll get it right eventually. But the idea is sound enough.

@Sebby Totally agree. I already have the ability to stop an app connecting to the local network through Little Snitch, and I like that. But of course that gives me all the power bundled up in a great interface. The disheartening thing is just how awful and disruptive Apple's implementation of these features are.

@Bri Yes indeed; you could say Apple are a victim of backward-compatibility here. It's very unfortunate that they are choosing to bolt on these features imperfectly, which just isn't going to give you the same reliability and UX as having a proper boundary API which would require forward-compatibility in a new SDK and work from the devs to use it. It's a shame because in the end it's not power-users who are ultimately hurt, but ordinary users who get confused because they can't understand why their app isn't working right and there's no obvious way to diagnose and put right the situation. I'm big on privacy but Apple simply doesn't have the luxury that Objective Development do with Little Snitch, of just deferring to the advanced user. And ordinary users need this feature too, particularly since it is known that local network fingerprinting is one way to profile the user by location. So Apple have to get it right, which they are failing to do. :(