Cheapshot: Everything to Save, Nothing to Trust

A wide countertop photo, uploaded to a chat assistant for an unrelated reason: identifying pantry contents for how to prep baby back ribs sitting in the fridge. Even in New York, ordering delivery at 2am is embarrassing. I had food, I needed to eat. A big bottle hit the counter. BACHAN’S. The biggest 34-ounce bottle I’ve seen. What is this thing?

Somewhere in the frame, a prescription bottle. Label legible. Nobody intended to share it. It was in the shot because it was on the counter, which is where it lives, in a covered wooden throwaway IKEA box.

Congratulations, you played yourself.

1. Photo captured on a phone. EXIF written: GPS coordinates, timestamp, device identifier.
   Congratulations, I know where I live!
2. Photo uploaded. Full frame, full metadata, unmodified.
   Yep, sure do love the iPhone 14 Pro Max line! Still kills in 2026.
3. The image travels straight to the cloud! The beans, the detergent, the prescription.
   I pay for state of the art, I get state of the art!
4. Only now does anything resembling privacy handling occur.
   WAIT. What did I just send to the cloud?

By step 3 the exposure has already happened. You don’t know what happens to your data the second it leaves your computer. Those packets aren’t coming back home after a little campout. They are hopefully gone after the mandatory retention period. What is left is a trust relationship with terms of service, and get real, who reads those? They change every few weeks anyways.

Deletion is real. But deletion is an act, not an oath.

Why this is a design problem and not a user problem

I am the person who uploaded that photo of Bachan’s Japanese BBQ sauce. I am the guy who reads scopes and specs and understands OAuth grants. Why would I possibly need to know what a QSFP28 cable is? Why do I have one in my cart? And yet… I uploaded it anyway. Not through ignorance. Through ordinary attention economics. I was thinking about calories and protein, the stuff you need to stay alive next to air and water. The bottle was in the room the way a coffee maker is in the room.

Any design whose safety depends on the user noticing has already failed, and it fails hardest on informed users, because they are the ones moving fast and confident.

So I built a tool that works the other way around, on any Mac running macOS 13 or later

cheapshot does OCR through Apple’s Vision framework. It’s fast and it’s totally capable, and nothing left my machine.

The speed comes from a trick: it only reads the frames where the screen actually changed, so the runtime of a video barely matters. The number in the band up top is real: a 58-minute, 7.9 GB screen recording, scanned and redacted in 2 minutes 36 seconds. But the reason it flies is that the screen sat mostly still. That hour of video was three frames that differed enough to bother reading. Point it at a screen that never stops moving and it slows down to match. What it saves you tracks how much is on the screen, not how long the recording runs.

Apple introduced the Vision framework in 2017, bringing computer-vision APIs to macOS 10.13 and later. In 2019, Apple added VNRecognizeTextRequest, enabling on-device OCR that can locate visible text for a local PII-redaction workflow. Don’t believe me? Here’s the WWDC 2019 deck! That 2019 date is the API’s, not the download’s: cheapshot itself targets macOS 13 and up.

That is not a feature I bolted on. It is the entire reason the thing exists. A screenshot pasted into an agent session is words rendered as pixels, sent somewhere to be turned back into words, and everything else in the frame goes with them.

Because the extracted text still reaches a model, it redacts before handing anything over: keys, card numbers, account numbers. On by default.

It started as a token bill

cheapshot began as a cheapskate move, not a privacy tool. The words were all the agent ever needed and the pixels were just expensive, so I taught it to read the screen and hand over text instead. Privacy came second and then became the whole point: once the thing was already reading every screenshot before it left the machine, stripping the secrets out was a few rules away, and the part I actually needed.

Then it did its own version of the same thing

I fed it a Subfolio session I had salted with every kind of secret I could think of, a deliberate test of how the redaction would hold up, and read the output against the screen it came from. One line was wrong:

…516a0d4d[BANK_ACCT]af6df3d8…

That is a SHA-256 with a bite taken out of the middle. Eight digits, 02126931, replaced by a label claiming they were a bank account number. The full string was 96817c4d87e7c5bf7854371cbc2353516a0d4d02126931af6df3d875061ef4d6, and a hash with a hole in it is worth exactly nothing.

The rule that did it:

(?<![\d\-/])\d{8,}(?![\d\-/])

The lookarounds exclude digits. They do not exclude letters. A hex hash is digits and letters, so any run of eight or more digits fenced by two hex characters reads as a free-standing account number.

Worse, in the same output, a path had become [TOKEN]. The catch-all secret rule included / and . in its character class and fired on any twenty-plus-character mixed-case run, which describes every absolute path on macOS. It had been doing that the whole time.

I only caught it because one surviving path was truncated three characters under the threshold, and seeing one path intact beside one path missing is what made me look.

The fix was not “redact less”

Loosening the rules trades a false-positive problem for a false-negative one, and a false negative here is a leaked key.

What the catch-all needed was a way to know it was guessing. Every secret with a recognizable prefix (AKIA, ghp_, sk-, xoxb-, eyJ) already has a dedicated rule ahead of it, so the catch-all only ever handles secrets with no shape at all. It can afford a high bar.

So I measured entropy over real input:

Paths and filenames top out at 4.14. Prefix-less secrets start at 4.66. The gap is real because of what the two things are: a path is words, and words are low-entropy.

Same lesson as the bottle, one level down. The question was never whether to automate. It was which part still needs a human, and how the machine signals that it is unsure. My redactor had no way to be unsure. It matched or it didn’t, and when it matched it destroyed.

What should ship, and not as a setting

Metadata first, because there is no excuse for that tier. EXIF carries GPS, timestamp, device ID. It is deterministic, free to remove, and worth nothing to a model identifying chickpeas. Strip it client-side, every image, no toggle. Keep the orientation tag, drop the rest.

Pixels are harder and still tractable. Both mobile platforms already ship fast on-device text detection. Detect regions locally, classify against high-risk layouts (pharmacy labels, name-and-address blocks, card numbers, ID documents), and show what was found before the upload fires.

The interaction is the actual contribution, because every privacy UI fails the same way: it blocks, so people learn to dismiss it.

1. Never modal. A dialog between someone and their task gets tapped through unread inside a week.
2. Show, don’t ask. Redaction boxes drawn on the thumbnail. Glanceable, ignorable.
3. Default to protected. The safe state takes no action. The unsafe one takes a deliberate tap.
4. Undo, not confirm. One tap to un-redact. Reversal is cheap; interrogation is expensive.
5. Silent when clean. No “0 items found” toast. Most photos are fine, and noise on the common path destroys signal on the rare one.

Cost to the user in the common case: zero taps, zero dialogs, nothing to read.

Where this stops being theory

The kitchen-inventory idea has this as a core requirement, not an edge case. It asks people to photograph the rooms they live in. Counters, cabinets, fridges. Mail, medication, mounted screens, and other people are in those frames by default.

A privacy paragraph in a signup flow is not a response to that. The guarantee has to be architectural: non-food objects are dropped on-device, before upload, and the crop of the prescription bottle never leaves the phone.

The demo is showing the counter photo, and showing the app return nothing for that object. Not blurred. Not flagged. Not redacted after the fact. Absent, because it was never sent.

Then showing the version that already happened: the same photo, uploaded whole, read whole. Not a hypothetical failure. A real one, and the person it happened to knew better.

Be honest about the limits

False negatives are certain

Handwriting, unusual layouts, non-Latin scripts, partial occlusion. This raises the floor. It does not close the hole, and it should not be marketed as a guarantee.

Sometimes the label is the point

“What is this medication?” is a legitimate request. Redaction has to be reversible in one tap, and the model should be able to say something is covered rather than silently receiving a hole.

Detection runs on the unstripped image

On-device, never transmitted, discarded after. But the client does momentarily process the sensitive pixels. That is an enormous improvement over transmitting them, and the claim should be stated that precisely rather than overclaimed.

OCR mangles exactly what secrets are made of

In my own test, a planted credential came back with Cyrillic homoglyphs substituted (А, М, Х, р), plus l→1 and O→0. The substitutions break the character run a secret rule needs. Redaction over OCR text is best-effort and cannot be a guarantee. Saying so is more useful than shipping one that isn’t.

cheapshot is public and licensed. So is proton-drive-backup, which came out of the same instinct: its README documents what actually happens when you kill an upload mid-flight, verified by reading the vendor’s SDK source rather than its marketing.

Two blocks to hand your own agent

Copy either one into your coding agent. They are written for it, not for you.

Wire up cheapshot so screenshots reach the model as redacted text, not raw pixels:

Stand up Tailscale so your devices reach each other privately and you can share one service with a friend, no ports opened: