Your files.Your keys.Your tenant.

Your browser tokenises file names and text content, keys each token with a per-user search key and sends only those blind tokens to the index. A query is transformed the same way, so the server matches tokens it cannot read. The search key itself is stored hybrid-wrapped (RSA-4096 + ML-KEM-768) like every other key. What the server does learn: which blinded tokens occur in which file, how often they repeat and which files a query matched: patterns, not words.

Why it matters Search is where most “zero-knowledge” products quietly leak: a plaintext index on the server reveals every word in every document. Here the index is as blind as the storage, and we say plainly what it still reveals.

Before a document is encrypted, the client strips macros, scripts, embedded objects and active content from Office and PDF files and rebuilds a clean copy. Legacy binary Office formats that cannot be sanitised are refused, and if sanitising fails the upload stops rather than passing the original through.

Why it matters A server that only ever sees ciphertext cannot run a virus scanner. Cleaning documents where the plaintext exists, in the browser, closes the door on macro malware arriving through shared client files. It removes active content; it is not a malware scanner and does not detect every threat, so endpoint protection with up-to-date antivirus on every device that opens files remains part of the picture.

Every file is encrypted in 10 MB chunks with a unique nonce per chunk and the chunk index bound into the authentication tag, so a chunk cannot be reordered, dropped or swapped without the client noticing. The last chunk is padded to a size bucket, which hides exact file sizes from the storage provider. Files above 5 MB travel as independent parts through the storage provider's multipart API, and throttled requests are retried automatically with backoff, so bulk uploads survive rate limits instead of failing on the first rejected part. Downloads decrypt chunk by chunk as they stream, in the browser, in the sync client and in the macOS app.

Why it matters End-to-end encrypted storage is only useful if a 4 GB scan set from a client actually arrives. Chunking makes large uploads survive real networks, streaming means nothing has to be buffered in memory, and the authenticated chunk index turns a truncated or tampered object into a hard error instead of a silently corrupted document.

Write a note directly in the vault, in the folder it belongs to, without leaving the browser. Notes are stored exactly like files: encrypted client-side, versioned, classified, shareable with the same roles and covered by the same audit trail.

Why it matters The context around a document, such as a call summary, a decision or the reason a file was shared, usually ends up in e-mail or a chat tool where none of these guarantees apply. Keeping it in the vault keeps the whole record in one protected place.

Summarise a note or a document, translate it, or create a translated copy of a Word, PowerPoint or OpenDocument file that keeps its formatting: all of it with models that run inside your browser. NomadVault uses the on-device model and language packs built into Chrome (Gemini Nano): the browser downloads them once from the browser vendor and then runs them locally, so the text you process never reaches us, the browser vendor or any AI service. The translated copy is encrypted and saved next to the original like any upload. These actions only appear in browsers that ship such models (currently desktop Chrome); everywhere else they are simply absent rather than routed to a cloud.

Why it matters Every “AI assistant” in cloud storage works by sending your documents to a model somewhere else, which is the exact data path end-to-end encryption exists to close. In this architecture plaintext exists in one place, the browser, so that is the only place a model is allowed to run. We would rather offer no AI in a browser without a local model than open a side channel to keep up with a feature list.

Every upload of an existing file creates a new encrypted version with its own key. Earlier versions stay restorable by anyone with access to the file, and folder trees can be recovered after an accidental delete.

Why it matters Ransomware and human error overwrite files. A version history that the attacker cannot decrypt or purge is the difference between an incident and a restore.

When you share a file or folder, your browser re-wraps the key for the recipient and signs the grant with your Ed25519 key. Recipients pin the public keys of the people they work with on first use and reject grants that do not verify.

Why it matters The classic attack on end-to-end encryption is a server swapping in its own public key. Signatures and pinning turn that swap into a visible error instead of a silent compromise.

Hand an external party a link and they can drop files into a folder, or fetch a document, without an account. Files are encrypted in their browser before transfer and the link can carry an expiry and a password.

Why it matters Client intake by e-mail attachment is how confidential documents end up in mailboxes and backups you do not control. Links move that traffic into the vault.

Every access, share and admin action is written to a hash-chained log whose head is verifiable from the settings page. Retention is a tenant setting (365 days by default), purges are re-anchored and attested, and bulk-activity alerts flag mass downloads.

Why it matters Regulators and clients ask who saw what and when. An audit trail is only evidence if it can be shown that nobody edited it afterwards.

Sign in with passkeys or a password plus MFA, or through Microsoft Entra single sign-on. Automation uses service accounts with scoped API keys instead of a person's credentials, and every session carries its own post-quantum key material.

Why it matters Phishing-resistant login protects the one thing the architecture cannot: the user's device and password. Scoped keys keep integrations from becoming a back door.

When classification is enabled, the browser scans each text-based document before encrypting it and tags it with the categories it detects: personal data under the GDPR, health data, financial data, credentials and secrets, plus patterns you define yourself such as client numbers or project codes. The result is stored with the file, shown in the properties panel and the compliance report, and can be corrected by anyone with edit rights, with every change audited. Binary formats are not scanned, and nothing about the scan leaves the device except the resulting labels.

Why it matters You cannot apply retention, access rules or a DPIA to documents you have not identified. Server-side classifiers would need plaintext, which this architecture refuses to hand over, so the scan happens in the only place the plaintext exists. The labels then drive Flow rules automatically: a file tagged as health data can be moved, retained and flagged the moment it arrives.

Files and folders can carry an expiry date with an action: delete, archive or notify. Flow rules apply retention schedules by folder or by classification, and the compliance report lists every document with its classification, expiry and the action that will follow. Deletions run on schedule and are recorded in the audit log.

Why it matters Retention obligations cut both ways: keep records for the statutory period, and stop keeping them afterwards. Doing that by hand across thousands of client files does not happen; doing it by rule, with an audit entry for every deletion, is what an auditor wants to see.

Create groups such as “Tax team” or “Board” and share folders with a group the same way you share with a person, with the same viewer, editor and co-owner roles. Each group has its own key pair: a share to the group is one grant sealed to the group key, and members receive the group key wrapped for their own keys. Group leads manage membership themselves; adding someone gives them everything the group can see, and removing them rotates the group key so they are cryptographically cut off rather than merely hidden.

Why it matters Sharing with individuals does not survive staff changes: every join and leave means touching dozens of folders. Groups turn access management into membership management, which is how your organisation already thinks, and keep the encryption honest when people move on.

The native client for Windows, macOS and Linux shows your vault as a normal folder. Files appear as placeholders and are fetched and decrypted only when opened, so a large vault costs no local disk until you need it. Keys never leave the device, and an optional remembered login is kept in the operating system keystore.

Why it matters Encryption that only works in a browser gets bypassed the moment someone needs a file in Explorer or Finder. Sync brings the same guarantees to the place people actually work.

Optional and off by default. If you enable it, your organisation generates an escrow key pair in the browser and keeps the private half; file keys are additionally wrapped to it, and every use of the escrow key is recorded in the audit log. If you never enable it, no such key exists anywhere.

Why it matters Many products marketed as end-to-end encrypted quietly hold a recovery or escrow key themselves. It is how they reassign a leaver's files or reset a forgotten password, and it is rarely spelled out on their security pages. A key like that makes the provider able to read your data, whatever the brochure says. NomadVault has none. People still leave and passwords still get lost, so escrow exists as an option you create, hold and audit yourself.