Security FAQ

Your files and most metadata are encrypted on your device before upload. DRIVUNO servers store opaque ciphertext and sealed key envelopes. We have no technical capability to read your content.

On your device only. Your password derives your master key locally via Argon2id. We never transmit, store, or escrow your password or master key.

Ciphertext, sealed envelopes, and operational metadata (account email, sizes, timestamps). Plaintext content cannot be recovered from a server-side breach because it is never on the server.

We can produce only what we hold: ciphertext, sealed envelopes, and metadata. A lawful request that asks for plaintext content cannot be technically fulfilled.

If you have a Recovery Key, secondary email, or SMS factor configured, you can recover. If all factors are lost, the vault is permanently unrecoverable — by architectural design.

Into a new vault, yes. Into your existing vault, no — that would require key escrow, which we deliberately do not implement.

Yes for sharing flows (sender device to recipient device, no readable intermediate). And the storage layer is zero-knowledge, which is the stronger property for stored data.

Argon2id for password-based key derivation, XChaCha20-Poly1305 for content encryption, X25519 for key agreement, Ed25519 for signing manifests, SHA-256 for ciphertext integrity, and HMAC-SHA-256 for blind-index search.

Yes. The share decryption key lives only in the URL fragment (after the #), which browsers never send to servers. Optional layers (password, expiration, one-time view, watermark) are enforced on top.

A maximum of 24 hours. Every public share link has a TTL capped at 24 hours and is destroyed on schedule; there is no way to configure a longer-lived link.

Yes. Messages, threads, mentions, reactions, calls, screen share, Notes, Documents, Flowboard, Tasks, and Calendar in Rooms are all encrypted end-to-end, with roles (viewer/creator/moderator/admin/owner) enforced at the database level.

Live Clone continuously and encryptedly replicates a local folder or drive, with SHA-256 integrity verification and folder-by-folder read-only sharing. It follows the same client-side encryption model as everything else.

Yes. A public REST API v1 with scoped, hashed API keys supports Zapier and Make via REST-hooks, plus HMAC-SHA256-signed webhooks with retries. The API only exposes metadata and lifecycle events — never decrypted content.

Yes. The installable PWA supports biometric unlock in addition to passkeys and TOTP MFA, with auto-lock on inactivity and progressive lockout on repeated PIN failures.

No. We cannot — your files are encrypted client-side. Even if we wanted to, we would have nothing readable to feed a model.

No. Scanning would require plaintext, which we do not have. Abuse handling for shares is metadata- and report-driven.

EU primary, with failover capacity. See the infrastructure page for details and the sovereignty page for the regional roadmap.

Yes. You can request a full GDPR export with a manifest at any time, and account deletion triggers a 30-day grace period followed by automatic purge via cryptographic erasure.

External cryptography review is in progress; a full penetration test follows on the roadmap. We publish dated commitments — see /security/roadmap.

Email security@drivuno.com or follow the coordinated disclosure policy at /security/disclosure. Safe-harbor terms included.

See the metadata policy for field-by-field retention. Operational logs 90 days, audit logs for the account lifetime, share view IP hashes 24 hours.

Yes. Messages are sealed to your keys on arrival and search runs entirely in your browser over data only your device can decrypt. Mailbox addresses live on a dedicated sending domain, deliberately separated from our corporate domain so reputation issues on one never affect the other.

Yes. They are decrypted only in your browser, previewed locally, and can be saved into your Drive or shared through the same zero-knowledge share flow — never through a server-side copy.

Secret items, custom fields and their attachments are encrypted with your vault keys and gated behind a dedicated PIN with progressive lockout on repeated failures. Imports from other password managers are parsed and encrypted locally; nothing readable reaches us.

No. Cached profiles, avatars, transcripts and previews are cryptographically bound to the account that produced them and are wiped when the vault changes. Any cache that cannot prove its owner is discarded instead of displayed.

A wrapped unlock secret protected by a non-exportable key held in the operating system's key store, plus an expiry. It renews while you keep using the device, can be revoked remotely from your sessions list, and if the key store drops the key the app falls back to your password — never to a weaker method.

Yes. Media is decrypted chunk by chunk in the browser during playback, so streaming starts immediately and no plaintext file is ever produced on our side.

Uploads resume from an encrypted local checkpoint, and every completed transfer is verified for integrity and duplicate detection using blind indexes — so a crash costs you time, never data, and never leaks file names.

Yes. Encrypted snapshots cover files, room transcripts and mailboxes, held off-site under an immutability window, with a one-click restore path. Every copy is ciphertext.

Storage failover is automatic and continuously monitored, with a public status indicator. Providers only ever hold encrypted blobs, so switching between them never changes who can read your data.

Capacity is validated with large-scale load campaigns ahead of demand. Cryptography runs on the client, so growth adds servers for ciphertext routing — it never creates a reason to move decryption server-side.

Yes. Exports are parsed and encrypted inside your browser before anything is uploaded, and imported content lands under the same access rules as native content, with isolation checks that fail closed.