What happens on your device
When you paste a CV, a WebAssembly detection engine — shipped inside this page, running in
your tab — looks for identifying values: names (a multilingual model covers Latin,
Cyrillic, Arabic, Devanagari, CJK and more), emails, phones, postal addresses, birth
dates, national IDs, IBANs and payment cards. Each detected identity value is swapped for a
realistic, locale- and type-matched stand-in: a Norwegian name becomes another Norwegian
name, an address another address, so the document still reads like a real CV and the
review stays useful. The mapping table — stand-in back to real value — exists only in
this tab's memory.
What happens to cards and secrets
When the on-device engine detects a payment-card number, account credential or similar secret, it
uses an opaque, digit-free marker instead of a realistic stand-in. A marker is derived from the
value itself with no secret key: it cannot be turned back into the number, but anyone who already
holds a candidate number can check whether it matches. The link from marker to real value exists
only on this device.
The audition can proceed with a detected secret sealed; a value the engine misses may remain as
written. If the reply repeats a marker, your device shows the matching real value in its place.
What actually leaves the browser
Each review sends one same-origin POST to /api/cv: the reviewed text,
with stand-ins for detected values; detector misses may remain as written. The relay checks the
privacy-engine version and fingerprint, then sends the exact request to the CloakAPI gateway for a check
before forwarding it to the AI service.
This check does not prove that this caller tokenised the text. Known limit in Release 1: a caller on this same origin can bypass this page and submit text without client-side tokenisation. The CV server forwards
this text to the CloakAPI gateway when the request is accepted and bills the tokens. The gateway is content-blind;
it has no mechanism to reverse the stand-ins because the map stays in this tab. The reply comes
back carrying the same stand-ins and is un-cloaked on your device.
What is enforced, not promised
This app's Content-Security-Policy sets connect-src to three
destinations: this origin, api.cloakapi.io and app.cloakapi.io. The browser enforces that list for page-script
connection APIs. The live monitor below counts main-thread fetch, XHR, beacon and resource
requests; it does not include worker or WebSocket traffic. Check your browser's Network
panel for the full request list.
Egress monitor 0 known-value bytes found
- On-device
- 0
- CV server /api/cv
- 0POSTs
- Gateway direct
- 0requests
- Third-party
- 0
The receipt
After each audition, this browser signs a device receipt (ECDSA P-256). If signing fails, you are told
and no receipt is shown. The receipt records detected identity counts and categories, the SHA-256
of the reviewed user-message body, and the engine's version and hash. It contains the digest and
metadata, not the reviewed text; it verifies offline as a signed record made by this browser.
It records that cloaking ran for that send, but does not prove gateway delivery or measure detector
misses. Text the engine does not flag — such as an unusual name or an unfamiliar identifier format —
may go as written.
What we don't store
cloak-cv's server serves these pages and relays reviewed audition text to the CloakAPI gateway without
storing the text. Detected values may have stand-ins; detector misses may remain as written. The
server counts requests for free-tier limits and logs gateway status, a request reference and a safe
error code when available, without logging the reply body. CVs, job ads and saved projects are kept
in this browser's local storage. Deleting a saved project removes its browser copy; it cannot recall
text already sent to the gateway and model. The CV audition uses a service key held by cloak-cv's
server; this page does not send a browser-stored CloakAPI key to the gateway. There are no analytics and no
tracking pixels — the CSP above makes that checkable rather than a promise. Two first-party cookies exist: your sign-in session, and a random id that counts free uses; neither holds your CV.
The honest limits
Detection is strong, not perfect. Rule-based checks look for supported formats
for email, phone, card and IBAN values; unfamiliar formats can slip through. Names are
best-effort — an unusual name, a nickname or a rare script can slip through. That's why the
casting sheet lists the values it detected and their stand-ins before anything is sent: check it.
Cloaked is not anonymous. The free text of a CV — a rare job title at a
small company, a one-of-a-kind project — can itself identify you even with every name
swapped. Stand-in text is still personal data in the GDPR sense while you hold the map.
cloak-cv strengthens a data-minimisation posture; it does not make a CV legally anonymous,
and we won't tell you otherwise.
The relayed model sees the stand-in document. Content-blind means the
gateway and model do not see the identifying values the engine detected — not that your document's substance stays on
the device. The substance is exactly what you're asking to have judged.