Search Is Editing

"The hit isn't the answer. The hit is the door. The answer is the video, at that second, open in front of you."

Closing the Circle

Track 1 opened with the claim that search here is an editing workflow, not a text lookup. Now that you've seen the machinery — the evidence, the releases, the timestamped segments — you can see what that claim actually buys. A hit doesn't end at the words. From a single result you can open the video detail at that exact segment, open the source in the default player, open it in a specific player, open it in QuickTime and seek to the absolute hit time, or reveal it in Finder to drag into Final Cut Pro. The whole pipeline exists so that a question — 'where did I say that?' — ends with the clip open, ready to cut.

The Seam: The Browser Never Names a File

Now look at how that handoff is built, because it's a small masterclass in a security principle. The obvious implementation is to send the file path from the browser: 'open /path/to/video.mov at 12:34.' It's the shortest path to working code, and it's a trapdoor. The moment the browser can name a path, the server becomes a confused deputy — a process with real filesystem authority, doing whatever a much less trusted caller told it to. Anyone who can reach that endpoint can now ask a privileged process to open arbitrary files.

So Recall's browser submits only three things: a database-owned video id, an action from a fixed enum (default / movist / quicktime / reveal), and a timestamp. No path. No command. No arguments. The control plane then does the trusted work itself: it resolves the media path from its own database, canonicalizes it, verifies it sits below an allowlisted root, and executes a fixed argument list. The client names what it wants by reference; the server decides how, from data only the server owns. That's capability-by-reference, and it makes an entire class of path-traversal and injection bugs structurally impossible rather than merely filtered.

Two Notes From the Working Engineer

The realism in this corner is worth stealing. First: those GUI actions run in bounded background threads, because a cold network mount or an unresponsive application could otherwise pin the HTTP request open. The same instinct as the killable child in Track 6 — never let something whose latency you don't control sit on a caller's critical path. QuickTime, for instance, is opened first, then the exact seek is retried for a few seconds while the document becomes available, because 'open' and 'ready to seek' are not the same moment.

Second, and more human: one player has no usable scripting interface on the installed version, so Recall can't seek it programmatically. The tempting move is to pretend — open it at zero and hope. Instead Recall opens the file and displays the target timecode for the human to seek manually. That's an honest degradation: the feature admits exactly what it can't do and hands you the one piece of information you need to finish the job yourself. A tool that tells you the truth about its limits is worth more than one that quietly does the wrong thing.

Code

The client asks by reference; the server resolves with its own authority·typescript

// What the BROWSER is allowed to send. That's all of it.
type InspectRequest = {
  video_id: string;                                  // DB-owned id
  action: "default" | "movist" | "quicktime" | "reveal";  // fixed enum
  timestamp_ms: number;
};
// No path. No command. No arguments. Nothing the client invents.

// Server side (has real filesystem authority):
//   1. resolve the media path from ITS OWN database, by video_id
//   2. canonicalize the path
//   3. verify it sits below an allowlisted root   <- or refuse
//   4. execute a FIXED argument list for the enum action
//
// The client names WHAT by reference; the server decides HOW.
// Path traversal and command injection become unrepresentable.

Exercise

Find an endpoint in your own work where a client asks a privileged process to act on a resource — open a file, fetch a URL, run a report, export a record. Look at the payload: does the client supply a path, a URL, a query fragment, or a command? Redesign it so the client sends only an opaque id plus an action from a closed enum, and the server resolves the real target from its own data and validates it against an allowlist. Note which bug class just became impossible.

Hint

The question to ask of any request payload is: 'what could a hostile caller name here?' If the answer includes a filesystem path, a URL, a table name, or anything that becomes an argument, you have a confused deputy waiting to happen. Replace the caller-supplied resource with a caller-supplied *reference*, and keep the resolution — and the allowlist check — entirely on the side that holds the authority.