The File Picker Is the Most Important Security UI Ever Built

Every permission prompt you have ever clicked through is a symptom. “App wants to access your Photos.” “App wants to access your Documents folder.” You click Allow, because the alternative is the app not working, and the prompt told you almost nothing anyway. You did not read it. Nobody reads it. The prompt is theater, and you know it.

The fix has been sitting on your screen for forty years: the file-open dialog. The boring one you use to pick report.pdf and never think about again. It is the most important security UI ever built, and we never noticed, because the systems underneath it threw away the only interesting thing it does.

The disease is ambient authority

On a normal desktop OS, an app runs as you. Not “as an app with a list of things it may touch.” As you, the human, with all of your authority, all the time. The moment a program runs under your account, it can read any file you can read. Your tax returns. Your SSH keys. Your browser cookies. It does not ask. The ability is just there, attached to the process because of who launched it.

This is ambient authority: power you wield because of who you are, not what you are currently holding. It is the water the whole desktop swims in.

The permission prompt is a desperate patch on it. The app already has everything, so the OS bolts a checkpoint in front of a few especially scary doors (your camera, your contacts, your photos) and makes the app ask before walking through. But the asking is bolted on after the fact, the app initiates it, and the grant is enormous: say yes to “Photos” and you have handed over all your photos, forever, until you dig into a settings panel and take it back.

What the picker actually does

Use a file picker instead. You click Open, a dialog appears, you navigate to report.pdf, you double-click it, the app receives the file.

Notice what the app did not receive. Not your Documents folder. Not the file next to report.pdf. Not a standing right to come back tomorrow and read whatever it likes. It got one file, because you pointed at one file. The scope of the grant was exactly the scope of your gesture.

The picker has been doing least privilege this whole time, quietly and correctly. And on a legacy OS, all of that precision is thrown away the instant the dialog closes, because the app could have read report.pdf directly anyway. It already had ambient access to your entire disk. The picker was decoration on top of power the app already held.

That is the tragedy. The single best permission gesture humans have ever invented, reduced to a fancy way of typing a filename.

The picker as an authority mint

A capability operating system flips this. The app has no ambient access to your disk. It runs holding only what it was explicitly handed. So the picker stops being decoration and becomes the thing that hands it something.

In Cathedral, the operating system I am building, the file picker is an authority mint.

A capability is an unforgeable value that confers one specific, narrow power: the right to do a named thing to a named object. Think of it as a typed key. When you pick report.pdf, the OS mints a capability that reads, roughly:

Capability<File::Read("report.pdf")>

and hands that single value to the app. That value, and nothing wider, is the app’s entire authority over your filesystem. It cannot widen it. There is no surrounding folder to walk, no sibling files to discover, no namespace to enumerate, because the app was never holding the namespace. It holds one key to one file.

The gesture is the grant. You did not answer a prompt about a category, you pointed at an object, and pointing minted authority over exactly that object. No prose to read, no Allow button that means more than you think. The thing you already do for ordinary reasons (choosing which file you meant) is the thing that moves the power.

The same gesture, everywhere

The file picker is one shape of a general move, and once you see the shape you see it everywhere.

Every one is a principled authority-transfer: the user’s intent, expressed as a physical gesture, mints or narrows a capability for exactly the chosen object and moves it to exactly the chosen recipient. They feel like different features. Underneath they are one operation wearing four costumes.

And because authority rides on gestures people already perform, the explicit prompt becomes rare. You see a modal dialog only when there is genuinely no natural gesture for what the app wants, and when one does appear it means something, because it is no longer the default way authority moves.

Being fair to UAC and TCC

It would be cheap to call the existing systems stupid. They are retrofits, honest attempts at a hard problem.

Windows User Account Control (UAC) and macOS Transparency, Consent, and Control (TCC) were both real efforts to drag least privilege onto an OS built from the ground up on ambient authority. Neither team got to start over; they had to add restraint to a system whose entire premise was that your process is you. They did real work, and they got one deep idea genuinely right.

That idea is the un-spoofable surface. UAC’s secure desktop is serious engineering: when the elevation prompt appears, the OS takes over the screen so a malicious program cannot draw a fake dialog on top and trick you into clicking Yes. That instinct, that the consent surface must be drawn by the OS and impossible for an app to forge, is exactly correct, and Cathedral keeps it. The picker, the share target, and the app identity shown all run on a trusted path the compositor guarantees, so a hostile app cannot paint a fake picker or dress itself up as a trusted one.

(Cathedral takes one thing further: the trusted path does not require UAC’s full screen-dimming takeover, only an OS-drawn surface the compositor guarantees is focused and cannot be covered up. The dramatic takeover is reserved for session-level events like login. The core instinct, OS-drawn and un-forgeable, is inherited straight from UAC.)

The surface is fine. These systems fall short in two other places.

First, who initiates. On UAC and TCC, the app asks: it decides when to throw the prompt, and you react. In Cathedral the user’s gesture is the common case, and a prompt appears only when no gesture fits.

Second, the scope of the grant. TCC, bolted onto a filesystem with no narrow handle to hand out, can mostly grant by category: “all photos,” “the whole Documents folder.” It was the granularity available. The picker already proved finer granularity is usable by ordinary humans every day. The capability model lets the grant be as small as the gesture, because there is finally a narrow value to hand over: one key, one object.

The sudo hole, closed

The picker model fixes one more thing, the one that bites professionals.

On a Unix-derived system, you elevate once and the power flows downhill. You run sudo, authenticate, and now that shell, every command it spawns, and every command those spawn inherits the elevated authority. You wanted to do one privileged thing; you got a privileged shell whose children all inherit everything. The grant is broad and sticky.

Cathedral’s command line works like the picker, in text. The shell runs as your session principal, so it wields your authority, but typing a path is the gesture. When you run cat ./report.pdf, the shell resolves the path, mints Capability<File::Read("report.pdf")> for that one object, and hands it to cat. The arguments are the grants. A spawned command gets the files named on its line, the current directory as a scoped working delegation, and whatever its own manifest declares and policy allows. Nothing ambient beyond that.

So rm a.txt b.txt gets a delete capability for a.txt and b.txt and nothing else. It cannot read your photos, because nobody named your photos. “It needs everything” turns into “you can name anything you already hold.” Reaching the system realm is a per-operation, trusted-path mint for the specific object you named, not a blanket elevated shell every child inherits forever. The elevate-once-inherit-everything hole has no place to exist, because there was never an ambient pool of authority to inherit.

The one-sentence version

The file-open dialog was always an authority mint pretending to be a filename chooser. Build the OS so the gesture is the grant, and the prompt you stopped reading years ago mostly disappears.