The basic idea of a sandbox is that an app has restrictions that define where it can read and write data, as well as the kinds of inputs and outputs it can monitor or make use of. It has to “keep its sand in the sandbox”: it can’t see or touch files anywhere outside its designated space, or listen to mics, view video, or capture keystrokes without explicit permission that you give it when prompted or that you configure to allow.
Apple rarely uses the term sandboxing in end-user materials, though they employ the concept all over.
The intention is to prevent buggy, corrupted, or malicious apps from messing with data and files from other apps or macOS itself. It has the additional benefit of limiting legitimate software from accessing personal information and inputs that you don’t think it needs to.
There are three kinds of sandboxing in macOS. The oldest affects apps as a whole.
App sandboxing
Available since Mac OS X 10.7.5 Lion, macOS’s app sandboxing restricts the kind of behavior apps can engage in outside their bounds—particularly their own set of data and caches.
Suppose you visit a rogue website in Safari that attempts to execute some dastardly code through an exploit someone has discovered in JavaScript, the popular programming language that powers web apps. Because Safari runs in a sandbox, that malicious code can’t affect other files: it can’t read your contacts, delete system files, add a startup item, or do any other mischief outside the browser window without your permission.
System files are additionally protected in yet another kind of sandbox. See how macOS protects its own system files.
Apps downloaded from the Mac App Store must be sandboxed (with some exceptions for older apps). In addition, Apple apps included with macOS are sandboxed, and so are many third-party apps available directly from their developers. (That’s usually because they also offer the apps in the App Store and don’t want to create two entirely different versions.)
But nothing in the design of macOS (at least, not yet) prevents you as a user from running a non-sandboxed app if you want to. Unless you get an app from the App Store or the developer tells you the app is sandboxed you have no easy way to know.
Sandboxed apps can read and write files in non-default places if you agree to let them do so. You’re prompted when you try to access a new location, and have to give simple permission: a click, not a password. That’s then remembered by macOS from then on. (Under certain rare circumstances, you might have to reauthorize an app.)
You can’t turn off sandboxing or adjust its settings. All you can really do is be alert—if an app asks for access to a folder you don’t think it should be using, that’s because the folder isn’t currently within its sandbox. Think carefully before saying yes—if it’s unexpected, the app could be trying to do something it shouldn’t.
Camera and microphone permission
Since Mojave, macOS asks you questions when an app or other software tries to use audio input or video cameras for the first time.
This was added to prevent potential snooping by malicious software, by having a deeply wired system opt-in requirement. It’s one thing for a malware developer to hack into your camera through software that runs with user-level permissions; it’s another for them to subvert the system and block the warning.
A lot of security and privacy companies offer A/V input features in their anti-malware software or standalone apps, some with more granularity (like “allow for an hour”) and a different workflow for detection. The free OverSight app from security researcher Patrick Wardle is a great place to start (along with all his other apps).
Apps don’t have to do anything special to request access. If it hasn’t been granted access, the first time an app attempts to use a camera, mic, or other audio input, macOS prompts you to approve it or not. If the app wants to bypass Apple’s built-in system, as with Zoom, you see a more severe warning about what it could access.
Once approved, manage access for apps and other components via System Settings > Privacy & Security. In some cases, deselecting an item results in a prompt to choose to quit and restart the app you changed settings for and offers Later as the other option.
Notebook Macs have a hardware disconnect switch that cuts off mic input when the lid is closed, too.
Some apps may have multiple entries in the list: one is for the user-facing app you launch and another for helper software that runs in the background.
Apps may respond differently if you deselect mic or camera permission. Some may not recognize they lack access and crash or behave erratically. Others test for access and prompt, such as Zoom after I allowed and then disabled camera access.
To let you know when certain inputs are in use, Control Center briefly displays a message showing recent use of your mic or camera. Click to reveal Control Center, and you’ll see a mic or camera icon followed by an app name, sometimes followed by “recently” if it’s active or was just active. The status message disappears quickly.
Any use of video, audio, or screen control/screen sharing lights up a colored icon in the menu bar—a green video icon, an orange mic icon, or a purple screen use icon—that indicates active or recent usage. Click the menu to reveal available specialty options for camera and mic effects, like Studio Light for your video or Voice Isolation for your mic, or to see what app is making use of your screen. (I’ve even seen two screen use icons: one for the Screen Sharing app and one for general screen-recording.)
Folder permission
In addition to app-based and A/V input sandboxing discussed above and personal-data privacy controls discussed just below, Apple uses sandboxing for all apps, which requires your permission for them to access certain folders. These locations include:
- The Desktop, Documents, and Downloads folders in your account
- Your iCloud Drive access
- Cloud storage from third parties that appears via Finder-accessible folders, like Dropbox and Google Drive
- Network volumes and removable volumes, each as a separate category of permission
The idea is that it’s suspicious if an arbitrary app needed to read from, much less write to, any of these locations without your explicit knowledge and permission. This can also help subvert ransomware, which tries to access important files wherever they are stored.
Whenever an app first tries to access items in any of these locations, your Mac prompts you to ensure you want to allow it.
If you use an external startup drive, you will see this message frequently. Every time an app wants to save a file on the startup volume, a Mac prompts for permission. By design, Apple prevents apps from saving to external volumes without a grant of permission.
As with mic and camera input, you can view and revoke permissions in System Settings > Privacy & Security: select Files and Folders and scroll to find the app.
Once you grant permission, you can only disable it—you can’t remove it from the list. The only way to remove an app from the list is to empty the list entirely using the command-line utility tccutil. It’s rare you would need to do this.
