RedactProof

The marker was 97% opaque. RedactProof read the SSN under it — in your browser — then burned a real fix and re-attacked.

Comment

Exhibit A: a screenshot that was "redacted"

Customer record — marker applied, ready to send Phone: ███ ███-████ · SSN: ███-██-████ · Card: ████ ████ ████ ████ · Email: ██████████ · ZIP: █████-████ · IP: ███.█.███.██

Same file, one browser tab and eight attacks later Phone: (416) 555-0177 · SSN: 078-05-1120 · Card: ████ ████ ████ ████ · Email: ██████████ · ZIP: █████-████ · IP: ███.█.███.██

That marker is 97% opaque. On screen it is a black bar. It still gave up a phone number and a Social Security number, because "97% opaque" means 3% of the text's contrast is still in the file — and 3% is enough for a contrast trick a bored attacker would try first.

Nothing was uploaded. No server saw the image. The data is fabricated. The leak is not.

RedactProof is the tool that tells you this before the recipient does. It then took two Fix passes, not one, to get that file to an A — C → C → A — and the second C is in the video on purpose.

And no, it did not get the email or the IP. We put that in paragraph four on purpose: the grade this tool prints is only as honest as the attacks behind it, so we show you exactly what those attacks could and could not recover.

What it is

A local-first web app that doesn't just redact screenshots — it attacks the result and grades how the cover-up survives. Two ways in:

  • Redact a screenshot. Local OCR + pattern detectors find PII, you review the boxes, it burns truly opaque rectangles onto a fresh canvas and re-scans the export.
  • Red-team an image somebody else redacted. Drop in any "already redacted" PNG/JPG. Eight recovery attacks run over the actual pixels. Whatever leaks is outlined and masked; one click burns an opaque fix and the fixed file is attacked again — until a pass comes back clean.

Everything runs in the tab. The only network requests are for the app's own vendored files.

The demo, with the real numbers

Hit "Try the marker-covered demo" on the live site and you'll see this, in this order:

  1. Identity pass (plain OCR) and six global transforms — contrast stretch, gamma up/down, invert, channel-max, 2× upscale-sharpen — recover nothing. The image looks safe.
  2. region-stretch, the localized attack we added after an independent review told us our old 55% marker was "readable to the naked eye": it finds the bands that look like cover-ups and stretches each one's own histogram. Phone + SSN come back. Grade C.
  3. Fix it. Opaque boxes burn over the two hits, the burned file is re-attacked — and region-stretch now peels card number + ZIP out of the remaining bands, because burning changed the image statistics. Still C. This is the moment we almost edited out of the demo. We kept it: it is exactly why a one-shot "redact and trust" is not enough.
  4. Fix it again. Zero hits. Grade A — printed next to the words "read the grade as 'untested', not 'clean'", because the re-check only saw 8 words of OCR-able text.
  5. Audit JSON: input SHA-256, grade, the eight attacks that ran, hit boxes and categories, a fix-provenance chain back to the flagged file's hash, and a container-metadata check (EXIF / GPS / XMP / PNG text chunks). Recovered strings and the filename are never written to it.

What we measured on the same engine (all fixtures synthetic, tests/redteam.test.ts): a 55% marker leaks all six categories to the plain contrast stretch; a 75% marker leaks four (phone, card, SSN, ZIP); 97% and 99% markers leak a partial set (two categories, measured) to region-stretch only; a fully opaque marker leaks nothing (correct); Gaussian blur and 8× pixelation stay unrecoverable by this engine — which is not the same as safe.

Why this is the product, not a feature

Every redaction tool trusts the editor. Screenshots then travel through support chats, job applications and AI assistants, and nobody re-checks a "redacted" image because it looks done. RedactProof makes the second look the product: attack, grade, fix, re-attack, and hand the reviewer a hash-chained audit that never contains the secret.

How we built it

Client-side TypeScript only. Tesseract.js OCR (WASM, vendored), deterministic regex + Luhn detectors, HTML Canvas for rendering and burning, Web Crypto for SHA-256. Attack transforms are pure per-pixel functions on raw RGBA; each of the eight variants gets its own OCR pass and hits are de-duplicated by category and box overlap. region-stretch reuses the region finder (flat areas that depart from the dominant background) and applies a [p1, p99] luma stretch per box — a padded or global stretch measured zero recovery on the 97% fixture, the tight per-box variant is what shipped. The metadata inspector walks JPEG/PNG chunks directly and records keyword names only. Static site on GitHub Pages; 96 tests, including real OCR recovery on synthetic fixtures.

Limits — read before trusting an A

Detectors cover emails, North-American phone numbers, Luhn-valid payment cards, Canadian/US postal codes, SSNs, IPv4 addresses and JWT-shaped tokens. They do not cover names, street addresses, dates of birth, account/SIN/IBAN numbers, OTP codes, non-NA phone formats, handwriting or QR/barcodes — draw manual boxes over those. Recovery is OCR-based and English-only; low-coverage scans are reported as inconclusive. An A means "none of these eight attacks recovered a supported pattern" — never "provably safe" — and the app says so on screen and in the report. On our own demo, two bands (email, IP) still sit under the 97% marker after the A; our attacks can't read them, a stronger one might. That is the point of printing the uncertainty.

What's next

More localized attacks (per-band binarization, colour-channel separation), more detector categories and languages, multi-page PDFs, batch review — and a public fixture set so anyone can measure a redaction tool the way we measure ours.

AI assistance

Devin SWE-2 implemented and tested the engine, UI and fixtures; Devin Max ran research, an independent strategy review and QA (its finding that our first hero fixture was visibly readable is why region-stretch and the 97% demo exist); Sharon directed scope, reviewed every PR and made the final calls. Everything above describes behaviour verified in the live build.

Built With

Share this project:

Updates