What this tool guarantees, and what it cannot

The promise, and its scope

Two claims, and everything below exists to support them. First: what you redact is removed from the file, not covered by a rectangle. A page carrying a redaction is turned into an image, the zones are painted on that image, and the image replaces the page — so that page has no text layer left to select, search or copy. Second: no file ever leaves your browser. The processing runs on your own device, and there is no server to send a document to.

Pages with no redaction are copied through untouched and stay selectable. Annotations, attachments, thumbnails and metadata are stripped from the file that is produced.

What the tool checks by itself

Before handing anything back, the application reads its own output file again and searches it for every string it just redacted — including any surviving run of four characters or more, compared without regard to whitespace or letter case. If one is still extractable, nothing is handed back: the export is refused, with a message naming what survived. There is no path in this product that returns a file when that check did not pass.

The reverse check runs on anything added to a page — text you typed onto the document, and the generated labels that replace a value when pseudonymisation is on. Those must be present in the produced file, and the export is refused when they are not. An addition found in half is not half an addition; it is a different text from the one the screen showed.

What that check cannot prove

This is the limit worth reading twice, and it is stated here rather than buried in the list below. The verification proves that a string is no longer extractable from the file. The page has been turned into an image by then, so the check cannot see a rectangle painted in the wrong place — one that lands short of the digits it was meant to cover passes verification while leaving them perfectly readable to the eye.

That is why every fallback in this codebase paints wider than it was asked to rather than guessing narrower: over-redacting is annoying and bounded, under-redacting is a leak. And it is why the application asks you to look at the produced file, page by page, before you send it. That is the one check it cannot perform on your behalf.

Check it yourself

Three things you can do without taking our word for any of it:

• Open your browser's developer tools on the Network tab, then redact a document. Nothing carrying your file goes out. Some documents do fetch a font or a character table from this site while they are read — fixed files named by the PDF, carrying nothing of your document — and you will see those.
• Turn off your network entirely and use the tool. Everything works, with one exception stated below: the first optical recognition needs to download its engine.
• Run the produced file through the redaction checker. It is the same reading code, pointed at the output, and it lists whatever text is still extractable.

About the source code: it is under the MIT licence, and the repository is closed for the time being. So the "audit it yourself" argument does not hold today, and saying otherwise would be the first thing on this page you could not check. The three gestures above are what remains verifiable without us, and they are worth more than a promise.

Known limits, by name

• Encrypted files that also use object streams are refused, not decrypted. Refusing is the honest outcome: parsing them anyway produces noise that looks like a document.
• Offline, a document naming a predefined character table loses part of its text. That table can only come from the network. The application says so on screen and warns that its final verification proves nothing about the part it never read.
• Optical recognition writes no text layer into the produced file, on purpose: it would add a way for a value to be written beside the rectangle meant to remove it. A misrecognised value is never proposed either, and the screen cannot tell you which ones those were — which is why the banner asks you to read the preview over.
• A saved profile outlives the session, with its terms in clear text in your browser's local storage. It is the one place in this product where data taken from a document survives closing the tab, and it narrows the claim that nothing is left behind.
• A custom pattern can hang the processing of a document. A regular expression cannot be interrupted once it is running, and JavaScript offers no timeout. The tab stays responsive; that document does not come back.
• US Social Security numbers have no checksum to validate against, so only the separated form is detected. A bare nine-digit run is left alone rather than reporting every order reference in every document.
• A composite font with no embedded program draws nothing, and is not substituted: its codes address glyph indices into the missing program, so a substitute would draw confidently wrong letters instead of none.
• Right-to-left text, and text drawn with non-default character spacing, word spacing or horizontal scaling, are redacted whole fragment rather than cut at the character. That paints more than was selected, never less.

Reporting a vulnerability

Write to mmanseur@gmail.com, with caviardeur security as the subject line. Expect an acknowledgement within a week. Please do not publish it before it is fixed.

Do not attach a real document. Whatever triggered the problem, rebuild it with made-up data and send that instead — a report about a leak should not itself be one.

What counts as a vulnerability here, rather than as a bug:

• A redacted string still extractable from the exported file, in any form — content stream, annotation, attachment, thumbnail, metadata, an incremental update, an object the sanitiser missed.
• A redaction rectangle that leaves the text it covered readable on the rasterised page. This is exactly the case the final verification cannot catch.
• Any network request carrying document bytes, or anything derived from them.
• Any path that returns a file to the user when verification did not pass.