Your library never leaves. Here's exactly how.
No hand-waving. This page is the whole mechanism — including the parts we can't promise — so you can decide whether it's right for your documents.
- On your device
Add & extract
Adding a document reads its bytes locally and pulls out plain text — pdf.js for PDF, mammoth for Word, a plain decode for text and Markdown. The extracted text is stored in your browser's IndexedDB. The raw file is never sent anywhere, and no server of ours ever sees it.
- On your device
Seal, on ask
When you ask a question, request a summary or a redline, a WebAssembly tokeniser and a multilingual name model scan the question plus the document text and stamp a realistic surrogate over the names, emails, phones, addresses, cards and national IDs they recognise. Structured identifiers match by rule; free-form names depend on the on-device model, so an unusual one can survive the seal — the ledger shows exactly what leaves. This step makes zero network connections — watch the monitor stay flat.
- Leaves your device
Sealed-only relay
Only the sealed text is sent to a model, through the CloakAPI gateway, carrying a cryptographic pre-tokenisation proof (a MAC over the exact bytes). The gateway relays those bytes verbatim. Your real values, and the map back, are never in the request.
- Back on your device
Restore & receipt
The answer returns still carrying the seals. cloak-docs maps them back to your real values locally, then signs a receipt: category counts, the engine's identity, the SHA-256 of the exact bytes that egressed, and the document's file name. The receipt records that the cloaking pipeline ran for that send. It does not measure how much the detector missed: text the engine did not flag — person names outside its dictionary, single-word company names, reference numbers in unfamiliar formats — went as written.
What is guaranteed
- A strict Content-Security-Policy hard-limits every network connection to this origin plus the CloakAPI gateway — nothing else can be contacted, by construction.
- Your library — every document you add — lives only in this browser's IndexedDB. There is no upload endpoint anywhere in this product; a document you add is never sent, in any form, until you ask a question about it, and even then only the sealed text goes.
- The sealing step runs before any relay and makes no network calls. The relay is fail-closed: if it can't obtain the privacy proof, nothing is sent.
- Only sealed text is ever transmitted; the re-identification map stays in your browser's memory.
- Every ask can mint an offline-verifiable receipt you (or anyone you show it to) can check without trusting us.
What we don't claim
- Detection is very good, not omniscient. An unusual identifier the models don't recognise stays in the text — always glance at the "preview what leaves" view before you ask.
- The prose around a name still travels. If the document itself identifies someone ("our only left-handed violinist"), sealing can't hide that — write with that in mind.
- Surrogates are realistic, gender- and locale-matched where the engine can; for scripts it can't morph, it falls back to a safe neutral stand-in. They preserve fluency, not always exact nationality.
- If the model re-spells a seal, that altered token simply stays as a safe placeholder in the answer — never your real value.
- The reading itself is performed by a third-party model via the gateway. It sees fluent sealed text, and it is billed. That's the one thing that leaves — on purpose.
- Your library survives only in this browser's storage. Clearing site data, switching devices, or using private browsing means it's gone — there is no server backup to recover it from, by design.
Verify a receipt
Paste any cloak-docs receipt JSON to check its signature offline. This runs the same on-device verification a recipient would — no server involved.