Make the File Smaller, Not the Boundary

On September 7, Simon Willison described a small tool built for a small problem. He had recorded a demo of his Equal Earth animation on his phone and wanted an optimized version for his blog. His video compressor uses FFmpeg, the media-processing software, compiled to WebAssembly so it can run in a browser. It generates versions at different quality settings and sizes for comparison.

The important part is where that work happens. His description says all processing is local, with no uploads to external servers.

A modest convenience. Also a useful separation: the machine that delivers the tool does not have to become the machine that receives your material.

---

The extra participant in a simple task

Imagine you need to send a short equipment demonstration to a colleague. The recording is too large for the destination. There are two jobs here: prepare a suitable copy, then deliver it to the intended person.

An upload-based converter introduces a third party before delivery. That may be an acceptable choice. But it is a choice about custody, not merely compression. The service receives material because it performs a transformation, even though receiving that material was never your purpose.

I want to keep those decisions separate.

That is the practical sovereignty question underneath this tool. Not whether every server is hostile. Not whether using somebody else's software is a moral failure. Whether the dependency you accept is necessary for the job you actually need done.

The familiar advice is to become a more careful uploader. The more useful design question is whether an upload needs to occur at all.

---

Smaller is not the whole measure

There is another good decision in the design: it produces alternatives and lets the person compare them. The job is not simply to minimize a number. It is to make a smaller file that still does its work.

For that imagined equipment demonstration, a tiny output is a failure if the colleague cannot read the control labels. For a spoken explanation, preserving intelligible audio may matter more than preserving every visual detail. The purpose sets the threshold. The file size does not get to set the purpose.

This is coherenceism at workbench scale: align the arrangement with the real need rather than force the need through the arrangement. Keep enough information for the recipient to understand. Keep unnecessary recipients out of the preparation step. Neither maximum fidelity nor minimum size wins by default.

And widen the circle when deciding what counts as unnecessary. If a recording includes someone else's face, voice, home, or workplace, your convenience is not the only interest in the file. Local compression can avoid one additional disclosure. It cannot grant permission to share the result.

A smaller file is not a redacted file. A private processing step is not consent.

---

Local is a claim to check

There is a limit to what this example establishes. Willison's September 7 post describes local processing; it is not an independent security audit. I am treating it as a documented design, not certifying the tool for confidential material.

A page delivered over the network still asks you to trust the code it delivers. “Runs in your browser” tells you where computation can happen. By itself, it does not prove that nothing leaves the browser. Nor does a local-processing claim establish that a tool will remain available offline or that tomorrow's delivered code will match today's.

That distinction matters because sovereignty is not a reassuring label. It is an arrangement you can examine.

For sensitive work, use an approved local application or a reviewed version you control rather than making an unfamiliar page your experiment with real data. For ordinary work, read the tool's documentation and test it with a harmless sample. That tests whether the output serves your purpose; it does not verify that nothing was transmitted.

The ambition is narrower than absolute independence: reduce the number of parties that need the original, while being honest about the trust that remains.

---

Put a preparation step before sharing

Here is the method to reuse tomorrow. It does not require adopting this particular compressor.

Pick one recurring file-sharing task. Before choosing a tool, write a sentence describing what the recipient needs: “They must be able to read the labels and hear the explanation.” Add the destination's actual size limit, if there is one. Now you have a test instead of an optimization contest.

Keep the original unchanged. Use a trusted local tool to prepare a separate copy. For the compressor Willison describes, the useful pattern is generating several candidate versions and comparing them—not assuming the smallest one is good enough.

Inspect the copy as the recipient would. Play it through. Read the text. Listen to the speech. Check for content that should not be shared; compression is not the tool for removing it. If none of the smaller versions passes, change the settings or reconsider the delivery route rather than silently sacrificing the point of the recording.

Then send only the version you intend to disclose. Save a short preparation note: tool and version, settings, destination size limit, and what you checked in the result. Reuse those settings as a starting point, not a guarantee that the next file will pass.

The durable capability is not finding a compressor. It is keeping preparation separate from disclosure.

Make the file smaller. Keep the decision about who receives it yours.