You can't trust macOS Privacy and Security settings

Original Article ↗ Hacker News Discussion ↗

macOS’s Privacy & Security controls are criticized as misleading, with users showing that apps can retain access to protected folders like Documents even after permissions appear revoked in system settings. Commenters argue this stems from overlapping mechanisms (TCC prompts vs. file-picker–based “implicit” consent) and architectural debt in grafting iOS-style permissions onto a traditional desktop OS, leaving users without clear visibility or revocation paths. The thread broadens into concerns about Apple’s wider security posture—especially for closed-source systems, VPN behavior, and sandboxing—and whether its permission prompts offer real protection or mostly security theater.

macOS folder permissions behavior

  • Core issue: apps can retain access to protected folders (e.g., Documents) even when System Settings shows access as revoked.
  • This often happens via the Open/Save panel: selecting a folder there grants access that can persist, but that grant isn’t clearly surfaced or revocable via the GUI.
  • Several commenters tested the article’s steps and confirmed that apps could still read Documents while the UI claimed access was blocked.
  • Some note that this is limited to TCC‑protected folders and doesn’t affect general filesystem access in the usual Unix sense.

Is it a bug, design quirk, or vulnerability?

  • One camp: this is a security‑UI bug / “security theater.”
    • The UI misrepresents actual permissions and offers no clear way to audit or revoke “implicit” grants.
    • For some, this undermines trust in macOS privacy controls.
  • Another camp: intended but poorly communicated behavior.
    • The file picker is treated as explicit consent; it’s a separate mechanism from the “Files & Folders” toggles.
    • From this view, two systems are working as designed; only the UI is inadequate.

TCC, sandboxing, and technical details

  • Distinction is made between:
    • TCC (privacy gates on Desktop/Documents, Messages, etc.)
    • The App Sandbox (entitlements, temporary “sandbox extensions,” and security‑scoped bookmarks).
  • Sandboxed apps typically get temporary access via file pickers unless they persist security‑scoped bookmarks.
  • For non‑sandboxed apps, TCC is a leaky layer bolted on top of a traditional desktop OS, with many legacy compromises.
  • One commenter notes extended attributes (e.g., com.apple.macl) and SIP making implicit grants hard to remove; others say tccutil reset plus reboot should work, though at least one report says it didn’t.

UX, permission fatigue, and “performative security”

  • Many criticize permission prompts as noisy, confusing, and inconsistent, comparing them unfavorably to Windows UAC or praising simpler Unix models plus containers.
  • Complaints include: barrage of prompts on fresh setups, app restarts required after toggling permissions, inconsistent behavior between Apple vs third‑party apps, unclear “Full Disk Access” semantics, and ambiguous toggle states.
  • Others argue that default deny is necessary in a world of compromised supply chains and untrusted plugins, and that developers underestimate real risk.

Broader trust and mitigations

  • Some express broader distrust of Apple’s privacy posture (VPN bypass history, iCloud behavior, persistent wireless state quirks).
  • Suggested mitigations include router‑level VPNs, using Linux/Unix with explicit sandboxing, and resetting TCC for specific apps.