a cron that writes secrets it can’t read

This site used to record my net worth as a nightly time series (a sparkline needs history), but the financials are end-to-end encrypted, and the nightly job runs on the server with no passphrase and no master key. The way out is old and underused: encrypting needs only the public half of a keypair. Each night the job sealed the day’s figure to my stored public key — ephemeral key, ECDH agreement, authenticated envelope, ephemeral secret discarded on the next line. What landed in storage could only be opened by the private half, which sat in the same store itself encrypted under the master key, unwrapped only in my browser. The server appended, forever, to a history it couldn’t open.

The honest part is the boundary. One dashboard row still needed to render server-side, so the index of which days have snapshots deliberately stayed plaintext — drawn on purpose and written down. E2EE isn’t a switch you flip; it’s a boundary you choose, and the claim should say what’s outside it.

The shape fits anything that must log sensitive events without being able to read them: audit trails, health data, location pings. Recording and reading don’t have to be the same privilege. Many things may record; one thing may read.

Postscript, days later: the mechanism is already retired. The last server-side read of the figure went away, so history now reconstructs client-side from dated entries and no nightly writer is needed. The lesson stands; the machinery became unnecessary, which is the best outcome a design can hope for.