{"id":53448,"date":"2026-10-05T15:40:34","date_gmt":"2026-10-05T19:40:34","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=53448"},"modified":"2026-10-05T15:42:13","modified_gmt":"2026-10-05T19:42:13","slug":"unspecified-full-disk-access-screw-tightening","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2026\/10\/05\/unspecified-full-disk-access-screw-tightening\/","title":{"rendered":"Unspecified Full Disk Access Screw Tightening"},"content":{"rendered":"

Apple<\/a> (Hacker News<\/a>, MacRumors<\/a>, Lobsters<\/a>, TidBITS-Talk<\/a>):<\/p>\n

\n

Full Disk Access largely sidesteps these controls in order to allow backup apps to function properly on the Mac. Some developers are using Full Disk Access in ways that could put users at risk, exposing everything on their systems—including files, mail, messages, and even browsing history—without users’ full knowledge and understanding.<\/p>\n

[…]<\/p>\n

Going forward, we will introduce additional controls to ensure that users who genuinely wish to grant an app this extraordinary level of access can only do so with very explicit user action. Addressing this is critical. As AI agents become increasingly capable and autonomous, the risks associated with this level of access will grow substantially.<\/p>\n<\/blockquote>\n\n

Guy English<\/a>:<\/p>\n

\n

It was pretty obvious something like this would happen after the Muse accessing Messages news.<\/p>\n<\/blockquote>\n\n

Jeff Johnson<\/a>:<\/p>\n

\n

What we have is just one noisy, confused journalist, Jason Aten. He granted FDA to Muse but refuses to admit it, to the public or even to himself.<\/p>\n<\/blockquote>\n\n

I see several issues with the current Full Disk Access system:<\/p>\n\n

    \n

  1. Backup apps need FDA, but so do many other types of apps. Often, they don’t need full<\/em> disk access but rather they need to work around a missing or broken API. All<\/em> of my apps except ToothFairy use FDA, not because I want to or because it’s easier to code, but because without it the user experience would be much worse or key features wouldn’t work at all.<\/p><\/li>\n\n

  2. There is no API for apps to see whether they have FDA or to request it from the user. It’s not like, say, accessing the user’s Contacts where macOS pops up a standard dialog and the app supplies a “reason” string to specify why it wants access. Instead, each app presents its own set of instructions for how to enable it deep in System Settings. It requires the confusing maneuver of first adding the app to the list; it doesn’t automatically show up with a slider switch next to it, like with other privacy settings. This adds an obstacle for users to get up and running with an app but doesn’t really provide additional security, just obscurity.<\/p><\/li>\n\n

  3. FDA is not granular. There’s no way for apps to request only the permissions they actually need. For example, SpamSieve wants to be able to access the user’s mail, but it doesn’t need or want to see their iMessages or browser history. This is bad for users because they may be exposing more information than they want to and bad for developers because some users will think your app isn’t worth the risks.<\/p><\/li>\n\n

  4. There is no way for the user to see what the app actually did. If it tells<\/em> me that it wants FDA to access my mail but actually<\/em> it mucked around with my Time Machine backup, how would I know?<\/p><\/li>\n\n

  5. Apple’s wording in System Settings is not very clear. I don’t think most users really understand what FDA is doing.<\/p><\/li>\n\n

  6. The previous items combine to create opportunities for malfeasance. It’s normalized that many apps that seem like they wouldn’t need full<\/em> disk access do need FDA, so this makes it easier for apps to trick the user into granting it under false pretenses. Apple requires<\/em> that apps coach the user through the process, so it’s normal that users mostly see text from the app (which might not be trustworthy) rather than standard text from Apple, as with other permissions prompts.<\/p><\/li>\n\n<\/ol>\n\n

    But the problem in the Muse case was not malfeasance. Rather, it seems that Muse asked Aten to enable FDA, but he doesn’t remember doing so or didn’t understand what he was doing. It sounds like Apple wants to make this consent more clear, which is good, but other issues would remain. As with the recent keychain story<\/a>, this feels like a bandaid rather than a thoughtful solution to the real problem. The issues with FDA were clear when it was introduced 8 years ago, and many Radars were filed, but it’s been virtually unchanged since.<\/p>\n\n

    Apple seems to think that by making a scarier warning they can convince more users not to grant FDA—or at least perhaps deflect blame from Apple to the user if they later regret it. Maybe that solves Apple’s problem, but it doesn’t really solve the user’s problem. The user is installing Muse because it’s more capable than Siri. They probably do<\/em> want it to access some<\/em> protected data, e.g. so it can find information in their mail or messages. So they actually do<\/em> need to give it FDA. Aside from deterrence, Apple is not actually protecting the user. And the deterrence is kind of sketchy. Rather than providing a safe way for users to choose what to share with a competing product, Apple is saying the only option is to share everything<\/em>, and then discouraging that. Meanwhile, there’s no switch to turn off Apple Intelligence. It’s like they expect you to stay on eWorld and not download Netscape. I actually really liked<\/em> eWorld, and the broad Internet wasn’t<\/em> totally safe (though neither was eWorld), but that doesn’t seem like much of a strategy.<\/p>\n\n

    Jeff Johnson<\/a>:<\/p>\n

    \n

    Below I’ve embedded […] a screen recording of a macOS Virtual Machine showing the first run experience of the Meta Muse app<\/a>.<\/p>\n

    […]<\/p>\n

    It’s important to note that macOS has no API for an app to request or acquire Full Disk Access. The only<\/em> way for an app to receive Full Disk Access is via the Full Disk Access pane of System Settings, as shown in the video. Thus, the only thing an app can do is open<\/em> the System Settings pane for the user, as also shown in the video. Once the user is in System Settings, it’s up to the user to manually grant Full Disk Access.<\/p>\n

    Without Full Disk Access, Muse cannot access the user’s Messages database. If it could, that would be a macOS zero day vulnerability.<\/p>\n

    […]<\/p>\n

    Aten oddly writes as if the “if you give it Full Disk Access” earlier in the article were counterfactual, merely hypothetical, still insisting that he did not<\/em> give Full Disk Access to Muse.<\/p>\n<\/blockquote>\n\n

    John Gruber<\/a> (Mastodon<\/a>):<\/p>\n

    \n

    I really worry about just how much Apple is going to lock Full Disk Access down. I use it with several apps that couldn’t function properly without it, and would be severely hampered if I needed to authorize it manually every time they do something.<\/p>\n<\/blockquote>\n\n

    Ben Lovejoy<\/a>:<\/p>\n

    \n

    However, what Apple absolutely must not<\/em> do is to make the mistake it made<\/a> with macOS Sequoia over screen recording. Sure, this is also incredibly dangerous and very strong warnings are appropriate, but what Apple did then was to force us all to confirm these permissions on a weekly basis, as well as after every restart. <\/p>\n<\/blockquote>\n\n

    Dave Nanian<\/a>:<\/p>\n

    \n

    Well, this is certainly ominous news for backup programs.<\/p>\n

    Like it’s not hard enough<\/em> to turn this stuff on…<\/p>\n<\/blockquote>\n\n

    Nick Heer<\/a>:<\/p>\n

    \n

    Is Apple suggesting this capability could be limited in the future to backup applications alone? I do not like that.<\/p>\n

    […]<\/p>\n

    Because of the lack of information available at present, I do not want to get too far ahead of myself, but I am concerned that it could be a significant curtailing of application permissions. It has the potential for further self-preferencing, as Apple will surely exempt Siri from the kinds of permissions requests it requires of third-party apps, even as it is updated with additional capabilities.<\/p>\n

    […]<\/p>\n

    Call me a naïve little baby if you want, but I do not think preserving Siri’s dominance on Apple’s devices is the company’s reason for locking down Full Disk Access. But Apple’s existing restrictions are part of the reason Siri was awful for a decade. If it had the opportunity to compete with third-party replacements, I doubt it would have languished in a miserable state for as long as it did.<\/p>\n<\/blockquote>\n\n

    John Voorhees<\/a>:<\/p>\n

    \n

    [Only] a handful of apps to which I’ve granted Full Disk Access are backup apps. Others include the Finder replacement Bloom<\/a>, launchers like Alfred<\/a>, the wonderful selection utility PopClip<\/a>, Apple’s own Pixelmator Pro<\/a>, Setapp<\/a>, TestFlight<\/a>, Supercharge<\/a>, Madden NFL 27 Arcade Edition<\/a>, Hazel<\/a>, and many others. It’s a diverse selection of apps covering everything from Apple’s own apps to Mac utilities that are longtime favorites of MacStories readers, and even one Apple Arcade game.<\/p>\n

    […]<\/p>\n

    On the one hand, it seems to suggest that users will simply have to jump through additional explicit hoops to grant Full Disk Access to their agents and other apps. On the other hand, claiming that Full Disk Access was designed solely for backup apps raises red flags that could signal that the company intends to restrict the kinds of apps that can use Full Disk Access. I sure hope not.<\/p>\n<\/blockquote>\n\n

    Dan Moren<\/a>:<\/p>\n

    \n

    But there are plenty of legit uses for Full Disk Access. Just looking at my MacBook Air this morning, I’ve given that permission to three apps: Terminal, BBEdit, and SuperDuper. All apps that I trust with that level of power because of their long history and because in order to do what they do best (or at all), they need that access. (Interestingly, on my Mac mini, that list also includes SpamSieve, KnockKnock<\/a>, and Shortcuts—though not BBEdit, for whatever reason.)<\/p>\n

    […]<\/p>\n

    I think there is<\/em> a good argument for protecting Full Disk Access further, but there’s also only so much you can do to protect a user from themselves. Ultimately, this is a cat-and-mouse game, and while I don’t want my data purloined or misused, I also don’t want my computer locked down to the point that I can’t use it for all the things I want to do.<\/p>\n<\/blockquote>\n\n

    Ben Thompson<\/a> (Hacker News<\/a>):<\/p>\n

    To say that I’m nervous about what Apple’s solution will entail is a massive understatement. There is one aspect in which the Mac is the perfect agent host: Apple has, for decades, invested in a combination of scriptability, automation, and accessibility APIs (these are very often the same thing) that makes it remarkably well-suited to computer use. Then there is the fact that macOS is a certified Unix system; this means that agents — which are perfectly suited to the command line — have access to the entire universe of tooling built for Unix systems. And, of course, Mac hardware is amazing.<\/p>\n

    The problem is that for my particular use case — a headless, always-on Mac Mini that I primarily access from other computers and my phone through the ChatGPT and Claude apps — macOS is incredibly hostile. The biggest issue is GUI-only permission prompts that are invisible to software running on said computer, including agents.<\/p>\n

    […]<\/p>\n

    This system is annoying but manageable on your primary Mac; it’s a disaster on a headless Mac running agents, for two reasons. First, agents write new programs all of the time, and in my case, those programs need access to devices on my network (SMB shares, for example, trigger a TCC warning). What I need is a permission layer for agents, not the programs they create; TCC is operating at the wrong level of abstraction.<\/p>\n

    Second, the TCC subsystem exposes its prompt in a protected space that no program can see; that means that programs silently fail and the agents don’t know why; what I have to do is remember that there is probably a permissions prompt on screen, log into the Mac Mini with screen-sharing software, and click OK.<\/p>\n<\/blockquote>\n\n

    Wade Tregaskis<\/a>:<\/p>\n

    \n

    Apple’d get a long way by just renaming the privilege. How many laypeople understand what a “disk” even is? Regular people just talk vaguely about how much “memory” their computer has - if they think about it at all other than when they run out of disk space - at which point, how many just think that means they have to buy a new computer? So, how about just “Full Access to All Your Data”? Call it what it basically is.<\/p>\n<\/blockquote>\n\n

    Jason Anthony Guy<\/a>:<\/p>\n

    \n

    If Apple has time (or is especially motivated), it might also add more granular options to control what data apps can access. For example, instead of today’s single toggle that grants an app access to the broadly defined “data like Mail, Messages, Safari, Home, Time Machine backups, and certain administrative settings,” it might instead allow you to enable access to specific data on a per-app basis. This would allow, for example, Muse to access Mail and Safari, but not Messages or Time Machine.<\/p>\n<\/blockquote>\n\n

    Kevin Grant<\/a>:<\/p>\n

    \n

    With all the levels of entitlements and crap they added, I find it ironic that SIP is “only” implemented as “open up every damned thing to everyone” without more refined levels.<\/p>\n<\/blockquote>\n\n

    John<\/a>:<\/p>\n

    \n

    I was frankly surprised when I learned FDA was for a machine, across user accounts, rather than for a single user. It seems like granting root, something the *nix community has tried to reduce and lock down for decades.<\/p>\n

    I certainly don’t trust anyone’s AI with root, and creating a weak, non-admin, user for AI experiments should be a safe path.<\/p>\n<\/blockquote>\n\n

    Jimmy Callin<\/a>:<\/p>\n

    \n

    While [Gruber sees] this as a “why we can’t have nice things” moment, I see it as another case of Apple using privacy to limit competition in areas it currently lag behind.<\/p>\n

    I’d prefer to decouple trust in how my personal data is handled from trust in a particular platform or software vendor. That’s what I personally value about EU’s approach: give people rights over their information, make mishandling it a legal liability, and severely punish companies that break those rules.<\/p>\n

    Apple getting unique privileges to access sensitive data simply because they own the platform, and thus there is an implicit trust in their handling of it, feels like a brittle long-term strategy. If this works without causing anti-trust issues, it only makes Apple more dominant while locking out potentially useful software.<\/p>\n<\/blockquote>\n\n

    Previously:<\/p>\n