> 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
Having had the (dis)pleasure of working with SELinux, it's clear that there are systems out there that can work to solve these problems. On Linux the problem is in the UI/UX layer (actually configuring SELinux rather than working around it is a massive pain) but Apple/Google/MS have the money to solve that.
I don't know if Apple has something like that. Surely they must do; Windows FACLs have been available since NT was part of the name, Linux has had them since Linux 2.5, and Apple invented a whole new filesystem relatively recently. They've also compartmentalised iOS apps since they were first released.
I'd be surprised if the currently available APIs aren't usable for applying effective restrictions just yet. Rather, I think Apple's choice is part of a process to move desktop applications towards the iOS model instead.
> On Linux the problem is in the UI/UX layer (actually configuring SELinux rather than working around it is a massive pain) but Apple/Google/MS have the money to solve that.
That assumes it can be solved and even then it requires research, so you cannot know how much effort it takes to find a solution.
Also, and IMO highly likely, any solution will be unusable for mere mortals. i thin that’s why you are saying “(dis)pleasure” and “configuring SELinux […] is a real pain”
SELinux was originally designed by the NSA to serve their needs, which are probably a bit more intense than "normal" users, and that was over 25 years ago. I'm not convinced a fresh effort couldn't do better, though I'm more skeptical that anyone is willing to invest the resources.
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.
> 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.
Window titles can and often do contain very personal information. A window titled "Planned Parenthood | Official Site" in the hands of a bad actor or some relative-monitoring spyware could have disastrous consequences.
> Want to paste some text into a text field? Accessibility Permissions.
Only if you aren't relying on user-initiated pasting like right click ' cmd+v.
I fully support you on your's previous comment but here I need to remind you what it is you who understand the implication of that query. Regular Joe isn't. And even more importantly is what the vendor is not on R.J. side, it is on the advertising side[0] where the excessive knowledge about a user is the thing.
Like just 15 minuts ago I opened Untappd likr a bazillion times before and were present with 15 screens of toggles and like 250 entities at least. There were at least 10 permissions to give the consent to track the things I do outside the app.
So not only a detailed reason for the permission wouldn't work, it wouldn't be implemented in the first place,
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.
How would you design such a system to be granular enough to solve for arbitrary application needs without being so complex as to be impossible to tune without false positives and false negatives all over the place?
It's not like people have tried to improve core security models, but in my opinion it's not really compatible with the core filesystem abstraction that programmers and power users of desktop computers demand. I think you need to move to a completely different model—like iOS for example—to meaningfully improve security controls without nerfing the OS.
So what? No one is disagreeing with you about that. The thread was about adding fine grain security controls to traditional OS filesystem access. I was just using iOS as an example, I could just have easily talked about containerization, as a security solution. Of course all those solutions are more limited than a local filesystem—the entire paradigm is designed around full control, you can't bolt on granular security. Heck, even basic UNIX permissions are pretty janky and unmanageable, but at least they more or less work everywhere since they've been around forever. Inventing something now is guaranteed to be annoying and useless.
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
thomas_witt · · focus · HN ↗
jeroenhd · · focus · HN ↗
I don't know if Apple has something like that. Surely they must do; Windows FACLs have been available since NT was part of the name, Linux has had them since Linux 2.5, and Apple invented a whole new filesystem relatively recently. They've also compartmentalised iOS apps since they were first released.
I'd be surprised if the currently available APIs aren't usable for applying effective restrictions just yet. Rather, I think Apple's choice is part of a process to move desktop applications towards the iOS model instead.
[deleted] · · focus · HN ↗
[deleted]
Someone · · focus · HN ↗
That assumes it can be solved and even then it requires research, so you cannot know how much effort it takes to find a solution.
Also, and IMO highly likely, any solution will be unusable for mere mortals. i thin that’s why you are saying “(dis)pleasure” and “configuring SELinux […] is a real pain”
gh02t · · focus · HN ↗
halJordan · · focus · HN ↗
nikanj · · focus · HN ↗
JdeBP · · focus · HN ↗
mmooss · · focus · HN ↗
<a href="https://irp.fas.org/nsa/rainbow/tg020-a.htm" rel="nofollow">https://irp.fas.org/nsa/rainbow/tg020-a.htm
What is the signficance now of this 1989 report?
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.
judge2020 · · focus · HN ↗
Window titles can and often do contain very personal information. A window titled "Planned Parenthood | Official Site" in the hands of a bad actor or some relative-monitoring spyware could have disastrous consequences.
> Want to paste some text into a text field? Accessibility Permissions.
Only if you aren't relying on user-initiated pasting like right click ' cmd+v.
alin23 · · focus · HN ↗
justsomehnguy · · focus · HN ↗
Like just 15 minuts ago I opened Untappd likr a bazillion times before and were present with 15 screens of toggles and like 250 entities at least. There were at least 10 permissions to give the consent to track the things I do outside the app.
So not only a detailed reason for the permission wouldn't work, it wouldn't be implemented in the first place,
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 ↗
dasil003 · · focus · HN ↗
It's not like people have tried to improve core security models, but in my opinion it's not really compatible with the core filesystem abstraction that programmers and power users of desktop computers demand. I think you need to move to a completely different model—like iOS for example—to meaningfully improve security controls without nerfing the OS.
SkiFire13 · · focus · HN ↗
How is moving to iOS's model not nerfing the OS?
dasil003 · · focus · HN ↗
SkiFire13 · · focus · HN ↗
dasil003 · · focus · HN ↗