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

Original Article ↗ Hacker News Discussion ↗

A small macOS utility that automatically dismisses the “Allow <app> to find devices on local networks?” prompt is prompting broader reflection on Apple’s permission model and user experience. Commenters praise the ability to script away repetitive, ill-explained dialogs but raise concerns about trusting unsandboxed tools, the difficulty of vetting small open‑source utilities, and the risk that constant pop‑ups numb users to real privacy threats. Many argue for more contextual, fine‑grained, and developer-explainable permissions, while others emphasize that system-level prompts must remain strict to counter overreaching and potentially adversarial apps.

Overall reaction to the tool

  • Many find the macOS “allow local network” prompt as annoying and UX-hostile, especially with browsers and auto-updating apps constantly re-triggering it.
  • The tool is praised as something the OS should have built in, akin to blocking cookie banners.
  • Some see it as emblematic of macOS regressing towards noisy, Vista-like security prompts.
  • Others note the irony of fixing sandboxed app dialogs by granting broad Accessibility access to an unsandboxed helper, which may be riskier.

Security, trust, and small utilities

  • Several commenters worry about trusting small Homebrew-installed tools, since compromised distribution is an easy attack path.
  • Suggested mitigations: prefer small, open-source projects; fork and build locally; have an LLM review the code.
  • Counterpoint: LLM-based code review can itself be vulnerable to prompt injection hidden in repos.
  • Some argue for “living off the land” and minimizing extra software, even if that means tolerating annoyances.

Permissions model and UX critique

  • Many see the permission system as too coarse, noisy, and context-free: dialogs don’t explain what concrete action triggered them or what breaks if denied.
  • Some want auto-deny tools like this; others explicitly want the inverse (always allow) or even a global “I accept all risks for this app” switch.
  • There are calls for:
    • More precise, scoped permissions (e.g., fake or stub data, per-feature prompts, regex/prefix-based clipboard or network access).
    • Async, non-blocking consent screens with placeholder content.
    • OS-level batching/inbox of dialogs instead of focus-stealing popups.
  • Debate over letting developers customize dialog text:
    • Pro: better explanations reduce confusion and user backlash.
    • Con: malicious developers will lie; system messages must remain controlled.

Local network and Chromium behavior

  • One explanation blames Chromium’s practice of running from temp folders for repeated prompts, but another commenter inspects the TCC database and argues permissions are keyed to signing identity, not path, calling that explanation likely wrong.
  • It’s unclear exactly why some users see repeated prompts after Chrome updates.
  • Local network permission is genuinely needed for things like device discovery (Chromecast, LAN games, media players), but many users never use those features and resent being asked.

Broader ecosystem and AI angle

  • Multiple people describe using LLMs to quickly build small macOS utilities to fix personal annoyances, and see this as a glimpse of a future where anyone can customize their environment deeply.
  • The thread includes additional macOS gripes (VNC focus-stealing, file access prompts, Spotlight behavior) as examples of where such tools or OS fixes are desired.