Opting Out of the Sandbox, On Purpose and With a Net

"The direct-distribution app is not App-Sandboxed. That is required for a Recall-resolved mounted-NAS path to open without a user picker; compensate with read-only handling, hardened runtime, no plugins/helpers, and strict validation."

A Protection You Turn Off Deserves a Serious Reason

App Sandbox is one of macOS's best protections: it confines an app to only the files the user explicitly hands it. Turning it off is not a shrug — it's a security decision that has to be named, justified, and compensated for. Ashen Reel opts out, and the reason is baked into the app's whole purpose.

The sandbox grants file access through user-selected scopes: an open panel, a drag-drop, a saved bookmark. But a Recall deep link resolves a path the user never picked in a panel — it came from a transcript search, not a file dialog. A sandboxed app has no security scope for that path and simply cannot open it. Sandbox on would break the exact handoff the app exists to provide. So the opt-out isn't convenience; it's the price of the core feature.

Turn off a protection only with a named reason and compensating controls. 'We disabled the sandbox' is a red flag when it's silent and a defensible engineering decision when it comes with a written why and a list of what replaces the protection you gave up. The opt-out and the compensation are a package.

What Replaces the Sandbox

Giving up the sandbox doesn't mean giving up on safety — it means rebuilding the relevant protections by hand. Ashen Reel's compensating controls are concrete: source media is handled strictly read-only (Track 5), the hardened runtime stays on so no unsigned code can be injected, there are no plugins, no privileged helper, no arbitrary shell, and no listening service to attack, and every Recall-resolved path is independently validated against allowed roots (Track 3). The sandbox's job was to limit blast radius; these controls limit it a different way.

The posture, written down so the tradeoff can't hide:

An unthinking opt-out is the actual danger. The problem is never 'sandbox off' by itself — it's 'sandbox off' with nothing put in its place and no reason recorded. Plenty of apps disable protections to make a warning go away and quietly become soft targets. The discipline is to opt out only when a real requirement forces it, and to owe the codebase a compensating control for every protection you removed.

Why This Is Honest Engineering

There's an integrity to naming a tradeoff instead of hiding it. Ashen Reel could have pretended the sandbox wasn't an issue, or quietly shipped a weaker app without saying why. Instead the architecture document states the opt-out, states the reason, and lists the compensation — so a future reader (including future-you) can audit the decision rather than stumble into it. A security posture you can read and challenge is stronger than one that merely happens to be true this week.

Code

The entitlements posture — the tradeoff made explicit, not hidden·text

Entitlements posture (a decision, written down):

  com.apple.security.app-sandbox                    = false  # opt OUT, on purpose
  hardened runtime (codesign --options runtime)      = ON     # keep other guards
  com.apple.security.cs.disable-library-validation   = false  # no unsigned code
  JIT / unsigned executable memory / dyld env overrides = none

WHY sandbox is off:
  A Recall deep link resolves a NAS path the user never picked in an open
  panel. A sandboxed app has no security scope for that path, so the core
  handoff cannot open the file. Sandbox on = the app's reason to exist, broken.

COMPENSATING CONTROLS (what replaces the sandbox's protection):
  - read-only media handling (Track 5): never writes the source
  - no plugins, no privileged helper, no arbitrary shell, no listening port
  - independent Recall-root + canonical-file validation (Track 3)
  - hardened runtime: still no unsigned code injection, no risky dyld env

Exercise

Find a security default your project has turned off or loosened — a disabled sandbox, a relaxed CORS policy, a permissive file permission, a skipped certificate check, an 'allow all' firewall rule. For that one, write two things: the specific requirement that forced the opt-out, and the concrete compensating controls that replace the protection you removed. If you can't fill in both, you have an unjustified weakness, not a tradeoff.

Hint

A defensible opt-out always has both halves: a real reason ('the core feature literally cannot work with it on') and a compensation ('here's what limits the blast radius instead'). If the reason is 'it was throwing warnings' and the compensation column is empty, that's not an engineering tradeoff — it's a soft target waiting to be found.

Opting Out of the Sandbox, On Purpose and With a Net

A Protection You Turn Off Deserves a Serious Reason

What Replaces the Sandbox

Why This Is Honest Engineering

Code

External links

Exercise

Progress

Comments 0