The Other Door: User Intent Is Its Own Authority

"Opening a file from Finder, Open With, drag/drop, or NSOpenPanel is a separate standalone file-open path. It may carry a file URL because macOS/user intent is the authority."

Two Doors, Two Authorities

After four lessons of "never a path," here's the twist that keeps the rule from becoming dogma: Ashen Reel opens paths all the time. When you drag a file onto the window, or use Open With, or pick a file from an open panel, a real file URL flows in — and that's completely fine. The identity-only rule was never about paths being evil. It was about who is allowed to choose the target.

The Recall deep link and the user file-open are two different doors with two different sources of authority. The deep link comes from an untrusted caller a web page could impersonate, so it gets identity-only and both-sides validation. The file-open comes from the user themselves, mediated by macOS, so a path is exactly the right thing to carry — the person sitting at the keyboard is the authority, and they picked the file on purpose.

Separate doors for separate authorities — and never route one through the other. The security of the handoff came from matching each entry point to what actually authorizes it. Conflate them and you either cripple normal use or reopen the hole.

Why You Must Keep Them Apart in Code

Imagine the two mistakes. Route every Finder open through the identity-only resolver, and normal use breaks — the user's own MKV on the Desktop has no video_id, so a perfectly legitimate file becomes unopenable. Route the Recall deep link through the user-open path, and you've handed the attacker exactly the path-acceptance you spent the whole track removing. The doors have to stay physically separate, each carrying its own trust assumption in its own function.

Authority is about the source, not the shape of the data. A file path from a user's open panel and a file path from a hostile URL look identical as strings. What differs is who chose it. Good security design tracks the provenance of a value, not just its type — the same path is trusted from one door and forbidden from another.

The two entry points, side by side, each honest about where its trust comes from:

The Rule, Generalized

This is a pattern you'll reuse far beyond a video player. Any app with more than one way in — a CLI flag and a config file, an API request and an admin console, a webhook and a human form — has more than one authority, and they rarely deserve the same trust. The discipline is to name each entry point's authority out loud and validate to that, never to average them into one lukewarm policy that's too strict for the human and too loose for the stranger.

Code

Two entry points, each honest about its authority·swift

// DOOR 1: the Recall deep link. Caller is UNTRUSTED (a web page could build it).
// Identity only -> strict parse -> resolve id in Recall -> re-validate -> open.
func handleRecallURL(_ url: URL) {
    guard case .ok(let req) = parseRecallOpen(url) else { return }   // strict
    resolveAndValidate(req) { validatedFile in open(validatedFile) }  // both sides
}

// DOOR 2: a file the USER explicitly chose. Authority = user intent + macOS.
// A real file URL is fine here, because a person -- not a page -- picked it.
func openUserSelectedFile(_ fileURL: URL) {
    guard fileURL.isFileURL,
          (try? fileURL.resourceValues(forKeys: [.isReadableKey]))?.isReadable == true
    else { return }
    open(fileURL)   // no video_id needed; the user IS the authority
}

// The two NEVER merge. A Recall URL never reaches Door 2's raw-path open;
// a Finder file never reaches Door 1's identity resolver. One app, two doors.

Exercise

List every way input gets into a system you've built — every entry point, not just the obvious one. For each, write the authority: who or what makes this input trustworthy? Find two entry points you're currently validating the same way, and check whether they actually deserve the same trust. Is one a human choice and the other a network stranger wearing the same data shape?

Hint

The tell is two entry points sharing one validation policy despite different authorities. A path from the user's own open panel and a path from a remote request are the same TYPE but not the same TRUST. Split the policy: strict for the stranger, permissive for the user.

The Other Door: User Intent Is Its Own Authority

Two Doors, Two Authorities

Why You Must Keep Them Apart in Code

The Rule, Generalized

Code

External links

Exercise

Progress

Comments 0