A URL That Names a Thing, Not a Place

"Recall handoff is identity-only. A Recall URL contains video_id and time, never a path."

Two Kinds of 'Open This'

There are two fundamentally different ways one program can ask another to open a video. It can say "open the file at /some/place/movie.mkv" — naming a place. Or it can say "open the video Recall knows as v_8f3a…" — naming a thing. They look similar and they are worlds apart in what they let the caller do.

Naming a place hands the caller a lever on the whole filesystem. Naming a thing hands the caller exactly one right: the right to open this specific known video. Ashen Reel takes the second, always. The deep link carries an opaque video_id — a token that means something to Recall and nothing to anyone else — plus an optional timestamp. That's the entire vocabulary.

Opaque Means the Caller Learns Nothing

The video_id is deliberately opaque: it isn't a path, isn't a filename, and can't be reverse-engineered into one. A caller holding the id can ask to open that video, but learns nothing about where it lives, and can't mutate the id into a request for a different file. The knowledge of where stays locked inside Recall's database, where it belongs.

Hand out the right to open a THING, never the right to open a LOCATION. A capability names what the holder may act on. The moment your handoff names a place instead of a thing, you've handed over a key to the whole building instead of the one room you meant.

You can see the discipline in the request type itself — the interesting part is what it refuses to hold:

This is capability-based security in miniature. A capability is an unforgeable token that grants a specific, narrow right. The video_id is exactly that: it authorizes 'play this one video' and nothing else. Design your inter-app messages as capabilities — narrow rights over named things — and whole classes of abuse simply have no way in.

The Payoff Is a Smaller Blast Radius

When the worst a malicious link can say is "open a video Recall already knows about," the damage ceiling is low by construction. There's no path to traverse, no file outside the archive to reach, no way to smuggle a system file into the request. The design didn't add a check to block those attacks — it removed the vocabulary to express them. That's the strongest kind of security: not a guard on the door, but a door too narrow for the threat to fit through.

Code

The request type — the security is in what it refuses to hold·swift

/// What a Recall deep link is allowed to say. Note what is NOT here.
struct RecallOpenRequest {
    let videoID: String       // opaque: meaningful only to Recall
    let timestampMs: UInt64   // optional in the URL, defaults to 0

    // There is deliberately NO `path`, NO `host`, NO `recallBaseURL`,
    // NO `playerArgs`. The request names a video; it cannot name a file.
    // You cannot express 'open /etc/passwd' in this type -- there is no
    // field to put it in. The vocabulary itself is the boundary.
}

// A caller builds:  cwkashenreel://recall/open?video_id=v_8f3a&timestamp_ms=41000
// A caller CANNOT build: ...?path=/anything  -- the parser has no such field.

Exercise

Look at an API or message format in your own system that lets one component tell another what to act on. Does it name a THING (an id the receiver resolves) or a PLACE/RAW-TARGET (a path, URL, query, or file the caller supplies directly)? If it names a raw target, imagine the most hostile value a caller could send. Then redesign the message to carry an opaque id the receiver resolves instead. What attacks become unexpressible?

Hint

The test: can the caller name something the receiver would never have chosen on its own? If yes, you're passing a place. Replace it with an id the receiver looks up in its own trusted store — now the caller can only point at things that already exist and are already allowed.

A URL That Names a Thing, Not a Place

Two Kinds of 'Open This'

Opaque Means the Caller Learns Nothing

The Payoff Is a Smaller Blast Radius

Code

External links

Exercise

Progress

Comments 0