> We give developers powerful APIs to build incredible capabilities
> Full Disk Access largely sidesteps these controls
That's because you don't really. Just like you don't give users "powerfulf" controls, so instead they have to resort to dumb ones like "Full disk"
For example, if you care about "mail, messages, and even browsing history", why isn't there a subset of "full disk access except for reading mail/messages/browsing history"? Or if vibe code have some basic disk sizing functionality to ask questions about your files, why can't it have a more granular "full disk read only access for file sizes only" so that your vibe coded disk visualization app can't destroy your data or your privacy
> can only do so with very explicit user action.
Which is in the same vein and is mostly useless, just another inconvenient bump
I have a file search app that does its own indexing similar to Everything on Windows (<a href="https://lowtechguys.com/cling" rel="nofollow">https://lowtechguys.com/cling) and I only index paths.
I don't need file contents, I can skip showing file sizes and date modified on protected paths. Hell I can skip indexing Mail and Messages files altogether since they're pretty useless anyway. But how am I supposed to know beforehand which path will trigger a scary Cling wants to see your <private folder> when doing a simple traversal.
Similarly, window switchers like my rcmd app (<a href="https://lowtechguys.com/rcmd" rel="nofollow">https://lowtechguys.com/rcmd) need access to window titles to function properly, but for that, the app has to ask for Screen Recording permissions. I don't need to record anything, I just need the damn title text and users will be happy to give access to that, but not to recording the screen.
This goes on and on.
Want to register a more interesting hotkey like fn-letter? You have to act like a keylogger and ask for Input Monitoring.
Want to focus a specific window instead of activating the app and letting the OS decide which window comes forward? You need Accessibility permissions and full access to control the whole computer.
Want to paste some text into a text field? Accessibility Permissions.
Too granular permissions is hell. But there are these decade-old common use cases for macOS utilities that would make it much easier to keep permissions locked if they became their own permissions.
I have a disk monitoring app that also gives quick access or the ability to eject external drives. Without Full Disk Access, you can’t open a Finder window to the root of the external drive. You can open the parent and select the disk mount point.
I burned a support request on this years ago, and was told that it seemed like a good idea for a future update… a API to open a Finder window at a known path.
macOS used to be one of the most power tool friendly operating systems. Apple Events and AppleScript dictionaries made automation like this so easy. Now everything requires a special permission or specialized Kit to do things that were simple two decades ago.
Personally I’m switching to Omarchy the minute they’ve got an Apple silicon image. Been on macOS since the 90s. I just want to be able to tell the papercuts to go away. Not confident in Apple’s ability to scratch that itch anymore.
I'm not sure I will migrate to Omarchy, but seeing the hype around the system gave me incentive to create TUIs for most of my apps. I'm making my day to day DX as OS-neutral as possible until I finally move to Linux.
eviks · · focus · HN ↗
> Full Disk Access largely sidesteps these controls
That's because you don't really. Just like you don't give users "powerfulf" controls, so instead they have to resort to dumb ones like "Full disk"
For example, if you care about "mail, messages, and even browsing history", why isn't there a subset of "full disk access except for reading mail/messages/browsing history"? Or if vibe code have some basic disk sizing functionality to ask questions about your files, why can't it have a more granular "full disk read only access for file sizes only" so that your vibe coded disk visualization app can't destroy your data or your privacy
> can only do so with very explicit user action.
Which is in the same vein and is mostly useless, just another inconvenient bump
alin23 · · focus · HN ↗
I don't need file contents, I can skip showing file sizes and date modified on protected paths. Hell I can skip indexing Mail and Messages files altogether since they're pretty useless anyway. But how am I supposed to know beforehand which path will trigger a scary Cling wants to see your <private folder> when doing a simple traversal.
Similarly, window switchers like my rcmd app (<a href="https://lowtechguys.com/rcmd" rel="nofollow">https://lowtechguys.com/rcmd) need access to window titles to function properly, but for that, the app has to ask for Screen Recording permissions. I don't need to record anything, I just need the damn title text and users will be happy to give access to that, but not to recording the screen.
This goes on and on.
Want to register a more interesting hotkey like fn-letter? You have to act like a keylogger and ask for Input Monitoring.
Want to focus a specific window instead of activating the app and letting the OS decide which window comes forward? You need Accessibility permissions and full access to control the whole computer.
Want to paste some text into a text field? Accessibility Permissions.
Too granular permissions is hell. But there are these decade-old common use cases for macOS utilities that would make it much easier to keep permissions locked if they became their own permissions.
jonhohle · · focus · HN ↗
I burned a support request on this years ago, and was told that it seemed like a good idea for a future update… a API to open a Finder window at a known path.
macOS used to be one of the most power tool friendly operating systems. Apple Events and AppleScript dictionaries made automation like this so easy. Now everything requires a special permission or specialized Kit to do things that were simple two decades ago.
junofan · · focus · HN ↗
rubslopes · · focus · HN ↗