Accessing sandboxed containers in macOS Sonoma

Jun 28, 2023   By: Brian Webster | 

As outlined in WWDC ’23’s “What’s New In Privacy” session and the sandbox documentation:

In macOS 14 and later, the operating system uses your app’s code signature to associate it with its sandbox container. If your app tries to access the sandbox container owned by another app, the system asks the person using your app whether to grant access. If the person denies access and your app is already running, then it can’t read or write the files in the other app’s sandbox container. If the person denies access while your app is launching and trying to enter the other app’s sandbox container, your app fails to launch.

The motivation behind this change is very understandable, to make sure the user has control over what apps on their system access other apps data, as well as ensuring that one app doesn’t try to pose as another one. However, in my opinion there are a couple major issues with the way this is implemented in the macOS Sonoma beta seeds thus far. When you launch an app that tries to read another app’s sandbox container, this is the message that is presented:

Note that the second message shown there can be defined by the running app’s developer (PowerPhotos in this case) by adding a “NSAppDataUsageDescription” key to your Info.plist file. (this key is not yet documented yet, but was confirmed by an Apple employee on their developer forums).

There are two main issues here:

1. The top message in the prompt doesn’t tell the user which app’s data is being read. In this case, my NSAppDataUsageDescription string explains what PowerPhotos is reading, but there’s no actual relation between that message and what files are actually being read. In other words, a malicious app can easily lie to the user here.
2. Unlike most of macOS’ security prompts, this one is displayed every single time the user launches your app, regardless of whether they’ve granted permission in the past. Not only is this just annoying, but this will quickly train the user to dismiss these prompts without reading them, which undercuts the whole purpose of the feature in the first place.

I’ve filed a Feedback (FB12473837) with Apple that basically suggests that these prompts should work more along the line of the existing “Automation” prompts, which are triggered when one app sends an Apple event to another app. The way it would work is:

1. The system should only ask once per combination of running app/sandboxed app (prompting again if either app’s code signature changes).
2. The sandboxed app should be named in the message that’s displayed to the user.
3. The results of these choices should be controllable via the Privacy & Security section of the System Settings app.

That way, the user doesn’t need to click through prompts every single they time they open a particular app, and it gives them additional control over which sandboxed apps data they want to allow or deny access to.

If anyone else agrees with me here, I’d encourage you to file a similar feedback with Apple, in hopes that we can help get this new feature improved before macOS Sonoma ships in the fall.