This page is the full truth. What we encrypt, who can see what, what happens when you delete, and what we are still building. No marketing fluff — every claim here is something we will honor at launch.
Read this first
We know .xyz sometimes raises eyebrows — the extension has been abused by spammers in the past, so being cautious is the right instinct. In our case it's purely coincidental: docutrackr.xyz was simply the clean, available name when we launched. There is nothing shady about it. The site is safe, served over HTTPS, and is the official home of DocuTrackr.
But the domain is honestly the least important thing here, because of how the product works: your document is read locally on your own device, and we don't save your documents or any sensitive data on our servers at all.
On-device OCR with Tesseract
Every scan is read locally by Tesseract, right inside your own browser, on your own device. The image never leaves your device. (A cloud reader is only ever touched in the rare case the on-device engine cannot run at all.)
No document images stored
The photo is processed in memory and discarded. There is no image on our servers, no S3 bucket, no backup — there is nothing for a breach to leak.
Only 5 plain fields kept
Name, document type, issue date, expiry date, issuing country — that’s all. No ID numbers, no addresses, no biometrics, no photos of you.
And those are encrypted
The sensitive fields we do keep are encrypted (AES-256-GCM) with a per-family key. Card details live with Stripe — we never see them.
This is the truth — not marketing. You can verify it yourself: open your browser's developer tools, watch the network tab while you scan, and you'll see the document image never leaves your device — the OCR runs locally in your browser via Tesseract. (Only if that on-device engine can't run at all do bytes pass, in memory and never stored, through a cloud reader — and even then no image is ever saved.)
How we encrypt
When you scan a document, the photo is processed in memory, five fields are extracted (name, document type, issue date, expiry, country), and the bytes are discarded. There is no Convex File Storage entry, no S3 bucket, no backup. A database breach finds no images because we never had them.
Free-form fields like document notes are encrypted with AES-256 in Galois/Counter Mode (authenticated — tampering is detected). Implementation lives in convex/encryption.ts. The other extracted fields are not encrypted at the database layer because they are what powers reminders and search.
Each family gets its own 256-bit data key, generated with crypto.randomBytes. A leak of one family's key never compromises another. The data key is currently wrapped by a static deploy-secret master key; moving that master key to AWS KMS is the next item on the security roadmap.
What this means in practice
A database-only breach leaks no images (we don't store them) and the encrypted fields as ciphertext (no use without the master key). A breach that also exfiltrates our deploy secrets could decrypt the encrypted fields today — that's the gap KMS integration is meant to close, and we're honest that it isn't closed yet. Decrypted data only ever lives in memory during your active session; nothing is persisted in plaintext.
Data flow
Snap a photo. Tesseract reads it locally, right on your device, and extracts 5 fields — the image is discarded and never uploaded.
Only the 5 extracted fields travel — encrypted in flight. Nobody on the network can read it.
Sensitive fields stored as ciphertext (AES-256-GCM). Useless without KMS-wrapped key. No image is ever written.
When you view a document
Access controls
| Role | Own docs | Others' docs | Audit log | Billing | Create share links |
|---|---|---|---|---|---|
| You (organizer) | |||||
| Family member (active) | — | — | — | — | |
| Caregiver-managed person | — | — | — | — | — |
| Our team | — | — | — | — | — |
| Convex (our infra provider) | — | — | — | — | — |
Access is enforced server-side in every Convex query and mutation, not just hidden in the UI. Our team can technically run admin queries against the database — but doing so writes to the same auditLog that you can see, and we hold the deploy-secrets that today still wrap the family encryption keys. (Closing that last gap with a hardware-backed KMS is on the roadmap.)
Audit log
The audit log is append-only. No edits, no deletions. If anything happens to your documents, you see it.
Document viewed
YouRecorded with timestamp, IP, and user agent.
Reminder sent
SystemEmail reminder dispatched via Loops — provider message ID stored.
Share link created
YouFamily-member invite link · 6-digit verification code · 90-day expiry.
Account deletion requested
YouSoft-delete begins — 30-day grace before automated hard-delete.
Sign-in method added
YouPassword linked to an existing Google-only account.
Deletion guarantee
When you delete your account, your data enters a 30-day grace period. After that, a daily cron permanently destroys your profile, documents, family record, reminders, share links, passkeys, and push subscriptions. We keep a non-identifying deletion-reason row + the audit log for compliance; everything else is gone.
You request deletion
Profile is soft-deleted (deletedAt set). Sign-in disabled.
Grace period
Want to undo? Email committed1@gmail.com — we can restore until day 30.
Warning email
We email you 7 days before the purge so day 30 isn't a surprise.
Automated purge
Daily cron deletes documents, family, reminders, passkeys, push subs. Encrypted-field key destroyed with the family row.
Compliance & roadmap
We don't fake security badges. Here's exactly where we are.
No image storage
We never store the document image. The photo is processed in memory, five fields are extracted, and the bytes are discarded. There is nothing on our servers for a database breach to leak.
TLS 1.3 in transit
Convex enforces HTTPS on every connection; we set HSTS preload + strict-origin headers on the Next.js layer.
AES-256-GCM field encryption
Free-form fields like document notes are encrypted with AES-256-GCM (12-byte IV, 16-byte auth tag) using a per-family 256-bit data key.
Append-only audit log
Every document view, share-link creation, sign-in, and admin action writes an auditLog row. The family organizer can read theirs from settings.
30-day deletion grace + automated purge
Delete your account and a daily cron permanently removes the profile, documents, family, reminders, share links, passkeys, and push subscriptions 30 days later.
Passkey sign-in
WebAuthn passkeys (Face ID / Touch ID / fingerprint / Windows Hello / hardware keys) registerable on every device — used as a sign-in factor alongside magic link, password, and Google. No post-sign-in re-prompt; the stored fields are non-identifying on their own.
KMS-wrapped key envelope
The per-family data key is currently wrapped by a static server-side master key. AWS KMS / GCP KMS integration is stubbed in code but not yet enabled — when it ships, a database breach plus a deploy-secrets leak still won't decrypt anything.
SOC 2 Type II audit
Planned for our first year of operation. Independent verification of our security controls.
Penetration testing
Third-party pen test planned post-launch. No bug bounty yet.
Regional data residency
Today: Convex US-region. Multi-region residency for GDPR / PDPL is under evaluation but not yet offered.
Responsible disclosure
We are a small team and we take security reports seriously. If you find something, please email committed1@gmail.com with details.
Please do not test on accounts you do not own. Do not access other users' data. Do not perform DDoS testing.
No. We do not store your document images. The scan runs entirely on your own device — a local OCR engine (Tesseract) reads the photo right in your browser, extracts exactly five fields (name, document type, issue date, expiry date, issuing country), and the image never leaves your phone or laptop. The only exception is the rare case where the on-device engine cannot run at all; only then do we fall back to a cloud vision model, and even then the bytes are processed in memory and never stored. Those five fields are the only thing we keep, and the sensitive ones are encrypted with family-scoped keys. No engineer, support agent, or admin can pull up your passport photo — because it does not exist on our servers.
More questions? committed1@gmail.com
Start tracking your family's documents with the security they deserve.