The Dashcam — Without Touching a Single Frame

A dashcam holds the most sensitive thing in the vehicle. And yet everything except the footage is ordinary operational data. How many trips today, how much card is left, whether the impact sensor is so twitchy it fires at every speed bump. Things a fleet manager looks at daily.

There is one common way to build this. One API that returns everything, with a permission check standing in front of the video endpoint.

That check disappears the day someone deletes it. In a rushed deploy, mid-refactor, to make a test pass. Everything else keeps working afterwards, so nobody notices.

The tool list is the surface

Everything this sample's dashcam offers:

the dashcam offers: trips.list, camera.settings, camera.set_sensitivity
  trips.list — Trips recorded today, with duration, distance and impact counts
  camera.settings — Read the impact sensitivity and the card space
  camera.set_sensitivity — Set impact sensitivity, 1 (least) to 5 (most)

Three. The tool that returns video isn't locked — it isn't there.

That is different in kind from a permission check. A check is code, and code can be deleted. An absent tool has nothing to call. However badly the front end is written, however far a token leaks, what isn't on the list doesn't get called.

Only handles travel

So what happens to the footage? Every trip row carries a handle.

clips referenced: clip:8841, clip:8842, clip:8843, clip:8844

clip:8842 is not a filename; it is an opaque handle. This server cannot open anything with it. It is for someone standing at the vehicle with the right to view, and at the same time it is evidence that this server never read the footage.

A handle travelling and content travelling are entirely different events. The log distinguishes them — that is what the handle is for.

Footage leaks through sentences too

One step further. Footage does not leak only as files.

"A summary of what the camera saw" is the video, laundered through a sentence. Reading a plate and returning it as text is not withholding the video. Counting how many pedestrians passed is the same thing.

So the server blocks its own output.

/// Words this server must never emit. Footage leaks by being described as
/// much as by being served: a "summary of what the camera saw" is the video,
/// laundered through a sentence.
static const forbidden = [
  'plate', 'licence', 'license', 'face', 'pedestrian', 'frame',
  'thumbnail', 'preview', 'snapshot', 'image', 'footage of',
];

Hit this list and the response throws while being built. It does not quietly strip — strip it and it goes back in next time.

The check sweeps every string the server emitted.

no footage-describing vocabulary in anything the server returned

The camera clamps itself

Sensitivity runs 1 to 5. One button on the screen deliberately asks for 9.

{ "type": "button", "label": "More sensitive",
  "onTap": { "type": "tool", "tool": "camera.set_sensitivity",
             "params": { "level": 9 } } }

asked for level 9 -> 5 of 5 ("sensitivity now 5")

The camera clamped it.

// The camera clamps to its own range. A fleet console asking for 9
// gets 5, and is told so.
if (v < 1) v = 1;
if (v > 5) v = 5;

A min/max could have been put on the screen side. That is manners, not safety. The screen is JSON, JSON changes with every deployment, and a day comes when the changed screen sends the wrong value. What catches it last must always be the frozen side.

And it says it clamped. Set it silently to 5 and the manager lives believing it is at 9.