Security

This page describes Driive's security model at a technical level. It is not a certification claim.

Account isolation

Each account receives a separate storage area identified by a random internal identifier. The application verifies ownership on relevant requests, while the storage gateway restricts the account to its own storage area.

Authentication

Sign-in uses Firebase Authentication with email and password or Google. API requests that require authorisation are verified server-side against the user's identity token. Client-provided data is not treated as the source of truth for roles, quota or ownership.

Desktop devices

Each computer generates its own key pair. The private key is stored locally in the operating system's secure key store and is not sent to Driive. Driive receives the public key. Removing a device revokes that device's access without affecting other devices. The desktop app also verifies Driive's server identity against a preconfigured server key and rejects the connection if the identity does not match.

Storage and encryption

Files are stored in a private object-storage bucket under EU jurisdiction, with public access disabled. Traffic is encrypted in transit and the storage provider encrypts objects at rest. Driive is not end-to-end encrypted and is not zero-knowledge. Provider-side encryption at rest is not the same as client-side encryption.

What we log

Driive records security-relevant events such as failed sign-ins, device enrolment and revocation, changes that affect storage access, administrative actions and account deletion. File contents are not logged. Where an internal identifier is sufficient for troubleshooting or a security investigation, full file paths should be avoided.

How the system is put together

An overview of the main security layers without unnecessary operational detail.

  • Storage. A private, EU-jurisdiction object store with no public address. Nothing reads from it without a credential held only by our servers, and that credential is scoped to this one bucket.
  • Gateway. Every read and write — from the desktop app, your phone or the web — passes one gateway that owns your quota. That is why the number you see is the real number, and why there is a single place where access is decided rather than several that can disagree.
  • Application. Requests are authenticated against an identity token verified on our side. Nothing a client sends can name a different account, change a quota, or grant itself a role.
  • Desktop. A per-device key kept in your operating system’s keychain, and a pinned server identity so the app refuses an impostor rather than asking you to judge.

We deliberately build on proven infrastructure for the parts where mistakes are catastrophic, rather than writing our own. The engineering worth doing is the experience around it.

Performance in practice

Files held in the local cache can open from your computer's disk. Other files need to be fetched over the network first, so speed depends on your connection.

Large transfers are handled in chunks rather than loading the entire file into memory at once.

What we have deliberately not built

  • No zero-knowledge encryption yet. Driive does not currently use client-side zero-knowledge encryption.
  • No public sharing links yet. Sharing features will not be released until the access model is complete and security-tested.
  • No file-content analysis. Driive does not index or analyse file contents for advertising or AI training.

Reporting a vulnerability

If you believe you have found a security issue, please contact us before disclosing it publicly. We will confirm receipt and keep you updated while we investigate.

security@driive.cloud