Threat Model

What DRIVUNO is designed to protect against

• Provider staff reading user files or messages
  Content is encrypted client-side before upload. The server never receives keys.
• Database leaks
  Database contains ciphertext, sealed key envelopes, and minimal operational metadata. Plaintext content is not present.
• Storage backend compromise
  Object storage holds opaque encrypted blobs. Sealed file keys live in a separate scoped table.
• Lawful access for plaintext content
  We cannot produce material we do not possess. We can only hand over ciphertext and account metadata.
• Server-side scanning, AI analysis, or moderation
  There is no plaintext on the server to scan. We do not, and architecturally cannot, run content analysis on user files.
• Cross-tenant data leaks via RLS misconfiguration
  Every table is scoped by owner_id / recipient_id; sensitive RPCs are SECURITY DEFINER with explicit revocations. Audited regularly.
• Public share URL leaks (server-side)
  The share decryption key lives in the URL fragment and is never sent to the server.

What DRIVUNO does not fully protect against

• Endpoint malware on the user's device
  Keyloggers, infostealers, and remote-control malware can capture passwords and master keys at unlock time. No web cryptography defends against this.
• Malicious or compromised browser extensions
  Extensions with access to the page can read decrypted content. We minimize exposure but cannot eliminate it.
• Phishing of password and recovery factors
  If a user is tricked into entering both their password and a recovery code on an attacker's site, the attacker can unlock the account.
• Screenshots and physical photos of the screen
  Once content is rendered to a screen, an external camera can capture it. Watermarks are deterrence, not prevention.
• Active manipulation of a delivered frontend build
  If an attacker can swap or alter our JavaScript bundle, they can exfiltrate keys before encryption. We mitigate with strict CSP, self-hosted assets, code review, and reproducible builds — these reduce, not eliminate, risk.
• Loss of all recovery factors
  We deliberately have no backdoor. A user who loses their password, Recovery Key, and secondary channels cannot be helped.
• Password reuse across sites
  If a user reuses their DRIVUNO password and another site leaks the password in plaintext, brute force becomes the attacker's bottleneck. The Argon2id work factor is calibrated to be expensive even then, but we cannot reverse a leaked password.
• Sophisticated targeted endpoint attacks
  Targeted state-level malware on the user's device defeats all client-side cryptography. Sensitive operations should run on hardened devices.

Phase 10 hardening — what we are doing about the residual risks

The cryptography neutralizes the server. The biggest remaining risk is the client — the JavaScript your browser executes. We treat this as the most important class of threat for a zero-knowledge product and address it on several fronts.

• Recovery Key freshness Shipped
  Recovery Keys older than 365 days trigger a soft in-app reminder to rotate. The previous key is invalidated as soon as a new one is generated. Limits exposure if a stored copy is ever leaked.
• Admin second-factor reminder Shipped
  Admin accounts without a passkey or TOTP factor see a persistent banner in the operator console. Enforcement remains soft to avoid locking the sole admin out of their own infrastructure; hard enforcement with multi-admin recovery is on the roadmap below.
• Release transparency log Shipped
  Every release is published with date, channel, and release notes at /security/releases. High-stakes users can compare what their browser loads against the published list.
• Subresource Integrity (SRI) on JS chunks Roadmap
  SRI hashes on every dynamic chunk would make CDN tampering impossible. Not shipped yet — the current Vite build pipeline does not emit per-chunk integrity attributes for TanStack Start SSR-rendered preloads. We are pursuing this in a dedicated build-tooling change rather than a half-working stopgap.
• Offline-signed releases (GPG) Roadmap
  Hashes signed by an offline key elevate the release log from operational transparency to cryptographic proof. The signing key generation ceremony is scheduled; until then we say so plainly on the releases page rather than imply a stronger guarantee than we provide.
• Stricter CSP in Report-Only mode Shipped
  Every response now carries a second Content-Security-Policy-Report-Only header that forbids unsafe-inline for styles and requires Trusted Types for DOM-sink scripts. The browser does not block — it only reports violations to our collector. This lets us measure the real cost of promoting the policy to enforced before we ship a change that could break the UI.
• CSP without unsafe-inline for styles (enforced) Roadmap
  Promoting the Report-Only policy above to enforced requires migrating our component library's runtime style injections to per-request nonces. Tracked on the security roadmap.
• Public bug-bounty program Shipped
  Scope, rewards (€50–€5,000+), and safe-harbor terms are published at /security/bug-bounty. Reports go to security@drivuno.com.
• External penetration test Planned
  Independent review by a reputable cryptography firm is planned once the bounty program has had time to surface obvious issues.