Trust at DRIVUNO
Trust Center
DRIVUNO is engineered so the people who run it cannot read what you store on it. This page is the canonical entry point to our architecture, policies, and transparency commitments.
DRIVUNO is a zero-knowledge Dropbox + Slack: files, chat and mail are encrypted on your device, the keys never leave it, 1 GB free, paid plans from $9.99/month. Business is $14.99 per user per month with 400 GB pooled per user, from 5 users.
Argon2id derives your master key from your password locally. Every file is sealed with XChaCha20-Poly1305 before it ever leaves your device.
Our servers store ciphertext, sealed envelopes, and minimal metadata. No password, no master key, no plaintext is ever transmitted.
Large uploads and downloads are encrypted and decrypted in chunks (secretstream), with progressive reads — never a full plaintext buffer sitting in memory.
WebAuthn passkeys, TOTP, and step-up re-authentication protect access. Sessions lock on inactivity and wipe in-memory keys when they do.
Keys are derived and stored on your device. Recovery factors wrap (not escrow) your master key, so only you can ever unwrap it.
Team and folder keys are sealed individually to each member with X25519, and rotate automatically whenever a member is removed.
Chat, calls, screen share, Notes, Documents, Flowboard, Tasks, and Calendar in DRIVUNO Rooms are all encrypted end-to-end, not just files.
Encrypted snapshots are taken before data leaves our perimeter and held under a 30-day immutability lock, with their own wrapped backup key.
If the delivered scripts do not match the published build manifest, the vault refuses to unlock and no key is derived. A warning you can click past is not a control.
Before anything is encrypted for someone else, their key is checked against a signed, append-only history. A key that cannot be authenticated is rejected rather than trusted.
Per-user rules are enforced by the database itself, not only in the interface, so a bug in one screen cannot become a way to read another account's rows.
Encryption hides content, but exact lengths are a fingerprint. Message content is padded into buckets before storage, and we keep operational metadata to the minimum the service needs.
Strict CSP with violation reporting, Row-Level Security, append-only audit log, ciphertext integrity hashing, signed manifests, and rate limiting on unauthenticated surfaces.
Storage providers see encrypted blobs only. Failover playbooks let us switch providers without exposing user content.
Hundreds of automated tests run on every change: Row-Level Security isolation, RPC and trigger fuzzing, and a browser-level gate that blocks CI if plaintext would ever leave the client.
Incoming mail is sealed to your keys on arrival and searched entirely inside your browser. A dedicated sending domain keeps mailbox traffic isolated from our corporate domain.
DRIVUNO Secrets stores logins, custom fields and attachments under your vault keys, behind a separate PIN with progressive lockout — and imports from other managers without ever sending them to us.
Every cached profile, avatar and transcript is cryptographically bound to the account that created it and discarded on vault change. A cache that cannot prove its owner is thrown away, not reused.
Trusted devices wrap unlock material under a non-exportable key held by the operating system's key store, with an expiry you choose, sliding renewal, and remote revocation from your session list.
Large media is decrypted chunk by chunk during playback, so multi-gigabyte videos stream instantly and no plaintext copy is ever produced outside your browser.
Room transcripts and mailboxes are snapshotted alongside files, off-site and immutable, with automatic monitored failover between storage providers — always as ciphertext.
Capacity is validated with large-scale load campaigns before it is needed, so security controls stay enforced at peak instead of degrading when traffic spikes.
Public security changelog, signed advisories, vulnerability disclosure policy, and a roadmap with dates we hold ourselves to.
Browse the Trust Center
Every commitment we make is documented in plain English. Pick a topic — we wrote each page for someone who wants to verify, not just be reassured.
Frequently asked
What does zero-knowledge mean at DRIVUNO?+
Your files and most metadata are encrypted on your device before upload. DRIVUNO servers store only opaque ciphertext and sealed key envelopes. We have no technical capability to read your content.
Can DRIVUNO recover my password?+
No. We do not store, derive, or escrow your password. Account recovery is only possible through factors you set up yourself: a Recovery Key, a secondary email, or SMS — wrapped against your master key on the client.
What happens if DRIVUNO is hacked or compelled to hand over data?+
We can only produce what we hold: encrypted blobs, sealed envelopes, and minimal operational metadata. Plaintext content is never on our servers and cannot be retrieved by us, an attacker, or any third party.
Is DRIVUNO end-to-end encrypted, or zero-knowledge?+
Both. End-to-end describes the transport (encrypted in your browser, decrypted in the recipient's browser). Zero-knowledge describes the architecture (the server has no keys, ever). See our Encryption Explained page.
Is DRIVUNO Rooms (chat, calls, documents) end-to-end encrypted too?+
Yes. Room messages, threads, calls, screen shares, Notes, Documents, Flowboard, Tasks, and Calendar are all encrypted client-side, the same as files. The server routes and stores ciphertext; it cannot read collaboration content either.
Do the API and webhooks expose decrypted content?+
No. The REST API and HMAC-signed webhooks only ever expose metadata and lifecycle events (e.g. a file was uploaded, a share expired). They cannot carry plaintext content, because the API server has no more access to it than any other part of our stack.
How do backups work without giving DRIVUNO a way to read my data?+
Backups are encrypted snapshots taken before data leaves our security perimeter, stored under a 30-day immutability lock, and protected by a backup master key that is itself wrapped with Argon2id. There is no escrow at any point in the pipeline.
What happens if I lose my password and my Recovery Kit?+
The vault becomes permanently unrecoverable. This is an intentional consequence of not holding any escrow: without your password, Recovery Key, or a configured secondary factor, no one — including DRIVUNO — can unwrap your master key.
What stops a modified version of the app from being served to me?+
On every page load, your browser re-fetches and re-hashes the delivered scripts and compares them against the published build manifest. On a confirmed mismatch the vault refuses to unlock and no key is derived. This is a detect-and-refuse control that runs inside the page it checks — it makes a tampered or targeted build visible and blocks it, but it is not a browser-enforced guarantee the way SRI would be; our integrity page says exactly where the line is. Being offline or hitting a cache miss is treated as "unverified", not "tampered", and never locks you out.
Could DRIVUNO swap someone's key to insert itself into a conversation?+
No. Before content is encrypted for another person, their key is verified against a signed, append-only history, and your device keeps its own record of keys it has already seen. A key that cannot be authenticated is rejected instead of being used.
Does encryption hide the size of my files and messages?+
Encryption alone does not, which is why exact lengths are worth protecting on their own. Message content is padded into buckets before it is stored, so the server observes a range rather than an exact size. File sizes are necessarily approximate rather than hidden, and we say so on the Metadata Policy page.
How do you know your access rules actually hold?+
Access rules are enforced by the database itself, not only in the interface, and hundreds of automated tests re-attack them on every change — attempting cross-account reads, privilege escalation and isolation breaks. If one of those attacks succeeds, the release is blocked.
Is DRIVUNO Mail readable by DRIVUNO?+
Mail stored in your DRIVUNO mailbox is sealed to your keys on arrival, and search runs entirely in your browser on data only your device can decrypt. Mail addresses live on a dedicated sending domain that is kept separate from our corporate domain, so reputation problems on one cannot contaminate the other.
Is the built-in password manager (Secrets) protected separately?+
Yes. Secrets are encrypted with your vault keys and gated behind a separate PIN with progressive lockout on repeated failures. Attachments stored alongside a secret follow exactly the same client-side encryption path as any other file.
If two people use the same computer, can one see the other's account?+
No. Every cached artefact — profile, avatar, message history, previews — is bound to the account that produced it and is discarded the moment the vault changes hands. Caches that cannot prove their owner are rejected rather than reused.
How does "trust this device" work without weakening my vault?+
Trusting a device wraps your unlock material under a key held by the operating system's secure key store, which the browser will not export. The record has an expiry you choose, renews itself while you keep using the device, and can be revoked remotely from your session list. If the key store loses the key, the device simply asks for your password again — it never falls back to a weaker path.
Can I stream a large encrypted video without downloading it first?+
Yes. Playback is decrypted chunk by chunk inside your browser as you watch, so nothing plaintext is ever written to our servers or to disk, and you do not have to wait for a multi-gigabyte download to finish.
What happens to my chats and mail if a storage provider fails?+
Encrypted snapshots of files, room transcripts and mail are replicated off-site under an immutability lock, and storage failover is automatic and continuously monitored. Every copy is ciphertext, so redundancy never widens who can read your data.
Report a vulnerability: security@drivuno.com · security.txt
