Your incident screenshot has your account ID in it.

on security, screenshots, workflow

Every incident produces screenshots. You paste them into the incident channel, into the ticket, into the postmortem document that three teams will read next week. And the screenshot always contains more than you were looking at when you took it — the account ID in the console header, the customer email in the table, the internal hostname in the URL bar, the two lines of terminal scrollback above the error.

The default tool for making those screenshots presentable is a screenshot beautifier website. You drag the PNG in, pick a gradient, get rounded corners and a soft shadow, and copy the result back out. Which means you just uploaded a picture of your production console to a server belonging to someone you have never met. Most of those sites are probably fine. From the outside there is no way to tell the difference between the ones that are and the ones that are not.

The upload habit

The habit persists because it usually does not matter. Most of the screenshots I take are for documentation, a slide, or a blog post — nothing in them is sensitive, and a hosted editor is genuinely the fastest way to make them look decent.

The rest is incident work, and that is the part where the default is wrong. Not because hosted editors are malicious, but because “we do not keep your images” is a promise, and a promise is not something you can verify by looking at a web page.

What local-first actually means

The one I have been using is ScreenHello. It is a browser-based screenshot and image editor that does not upload anything: “Everything runs in your browser. There is no account, no upload and no cloud sync, so a screenshot never leaves your device.” No account, no upload backend, MIT licensed.

The feature that made me keep it is that it does not ask me to take that on faith. There is a running egress readout in the interface that reports external requests measured at runtime for the session — uploaded 0 this session with 0 external request(s). That turns a privacy claim into an observation, which is a much better class of evidence. I can watch it while I work.

It is also honest about the edges of the claim: “Local-first does not mean that loading the website makes no network requests.” Your hosting provider still sees your IP address and user agent, and the encoders load from the site on first use. Plenty of vendors would have left that sentence out.

Underneath the privacy angle it is a competent editor, which matters — a tool you avoid because it is clunky does not protect anything. Backgrounds, padding, rounded corners, shadows, browser chrome and device frames, plus the annotations I actually need: rectangle, arrow, text, step numbers, blur, mosaic and spotlight. Export to PNG, JPG, WebP or AVIF at 1x/2x/3x, copy straight to the clipboard, or batch up to twelve images into a ZIP. It installs as a PWA, and the core editor opens offline once it has loaded.

The honest trade-offs

The rule I actually follow

Anything that touches production does not go to a service I cannot audit. That was already true for logs, configs and database dumps. Screenshots were the hole in it, because the screenshot is the one artefact that leaves through a browser instead of a shell.

The workflow is unglamorous: capture with the OS tool, annotate locally, export, paste the export. And the thing that took me too long to internalise — an annotation is not a redaction. A black rectangle drawn over a token is a rectangle. Use blur or mosaic, which actually destroy the pixels, and assume the original file is still on your disk and in your clipboard history.

I keep a local-first editor around for the same reason I keep a password manager. Not because I distrust any particular vendor, but because the cost of not needing to trust one is close to zero, and the failure mode of trusting the wrong one is not.