Show HN: Auto Dismiss Mac OS "Allow <app> to find devices on local networks?"

A new macOS utility aims to quell the incessant and poorly designed 'Allow <app> to find devices on local networks?' pop-up, a persistent annoyance for many users, particularly those using Chromium-based browsers. This small Swift app, dontallow, leverages Accessibility permissions to automatically dismiss these prompts by clicking 'Don't Allow'. Its popularity on Hacker News highlights user frustration with Apple's opaque permission management and the community's drive to build clever workarounds for system-level UX shortcomings.

118

Score

Comments

Highest Rank

14h

on Front Page

First Seen

Oct 29, 8:00 PM

Last Seen

Oct 30, 9:00 AM

Rank Over Time

The Lowdown

The macOS 'Allow <app> to find devices on local networks?' prompt has been a source of significant frustration for many users, particularly due to its repetitive and often inexplicable appearance. John Cassil's new open-source Swift application, dontallow, directly addresses this pain point by automatically dismissing these dialogs, defaulting to 'Don't Allow', within a quarter-second of their appearance.

The Problematic Prompt: The local network access prompt typically appears when an application attempts to discover devices on the local network. However, for many apps, especially Chromium browsers, the prompt reappears on every launch because macOS keys the decision to a temporary app path that changes with updates. Other apps with versioned install paths or even misattributed prompts also contribute to the deluge of irrelevant dialogs.
Lack of Control: macOS currently offers no native way to globally disable this prompt, prune the list of permissions, or pre-deny access via MDM, forcing users to repeatedly interact with it.
How dontallow Works: The utility registers an Accessibility observer for window creation by UserNotificationCenter, identifies the local network prompt, and then programmatically clicks the 'Don't Allow' button. It's designed to be lightweight, consume zero CPU when idle, and survive reboots.
Installation & Usage: Installation is straightforward via Homebrew or manual build. Users can pause dontallow, add apps to an allowlist, or manually override decisions in System Settings. Notifications confirm dismissals.
When Local Network Access is Needed: For legitimate use cases like Chromecast or LAN multiplayer, users can temporarily pause dontallow, add an app to an allowlist, or manually grant permission in System Settings.
System Integrity: dontallow avoids modifying system files, disabling protections, or automatically granting 'Allow' permissions, focusing solely on dismissing unwanted prompts.

Ultimately, dontallow offers a pragmatic solution to a deeply irritating macOS user experience, born out of specific technical behaviors of applications and perceived limitations in Apple's permission system design. It reflects a common theme in the tech community: if a platform's built-in solutions fall short, a dedicated developer will often step in to fill the gap.

The Gossip

Apple's Annoying Accessibility

Many commenters expressed deep frustration with macOS's permission dialogs, particularly the 'Local Network' prompt, criticizing Apple for poor UX design. Users highlighted the repetitive nature, lack of context, and the fact that legitimate apps like Chrome or Teams trigger these repeatedly due to how macOS keys permissions. The sentiment is that Apple's design leads to 'alert fatigue,' making users ignore important warnings, and that the OS should provide better controls or context for these prompts.

Security Skepticism & Scrutiny

A significant discussion revolved around the irony and inherent risk of installing an unsandboxed, third-party utility with Accessibility permissions to bypass security prompts. Commenters debated how to trust such small open-source projects, with some suggesting code review (potentially with AI assistance) or noting that the perceived annoyance outweighs the security risk. Others pointed out that these tools become necessary due to OS design flaws, creating a 'damned if you do, damned if you don't' situation for users.

Permission Ponderings & Proposals

The discussion delved into broader critiques of modern operating system permission models. Users suggested improvements like providing more technical detail on *why* an app needs a permission, offering a 'fake data' option instead of just 'Allow/Don't Allow,' or implementing an 'inbox' for permissions to be reviewed in bulk. The sentiment was that current permission systems are too coarse-grained and lack the necessary context for users to make informed decisions.

AI's Assisting Annoyance-Annihilation

A tangent emerged regarding the use of AI, specifically LLMs, to generate or review small utility apps like `dontallow`. Some users expressed optimism about AI democratizing development for fixing minor annoyances, while others raised concerns about the security implications of using LLMs for code review, particularly regarding prompt injection and the LLM's inability to reliably distinguish between benign instructions and malicious code within a given context.