Security

Account isolation

Every account is assigned a private storage area identified by a random internal identifier. Access is enforced in two independent layers: the application checks ownership on every request, and the storage gateway confines each account to its own area at the protocol level. A request that tries to reach another account’s files is refused by both.

Authentication

Sign-in uses Firebase Authentication with email and password or Google. Every API request is verified server-side against the identity token; nothing in the browser is trusted as permission. Paid storage is activated only after an email address is verified.

Desktop devices

Each computer generates its own key pair. The private key never leaves that device and is never sent to us — we only receive the public half. Removing a device from your account removes exactly that device’s key; your other computers keep working. The desktop app also verifies our server’s identity against a pinned key, so it will refuse to connect to an impostor.

Storage and encryption

Files are stored in an EU-jurisdiction bucket that is private, with public access disabled. The storage provider encrypts objects at rest, and all transfers use TLS. Driive is not end-to-end encrypted and is not zero-knowledge. Provider-side encryption at rest is not the same thing, and we will not describe it as though it were. If we ever add client-side encryption, we will say so explicitly and describe what happens if you lose your key.

What we log

We record security-relevant events — sign-in failures, device enrollment and revocation, subscription changes that affect storage access, administrative actions and account deletion. We do not log file contents. Where an identifier is enough for an investigation, we store that instead of a full file path.

How the system is put together

Described at the level that lets you judge it, without publishing a map of where to attack.

• 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.

Speed, honestly

Files you have opened before are cached on your own machine and open from local disk. Files you have not opened are downloaded when you ask for them, so that depends on your connection. Driive is not a local SSD, and we will not describe it as one.

Transfers stream in pieces rather than loading a whole file into memory, so a large video behaves like a small photo, and a cancelled transfer stops immediately instead of finishing invisibly.

What we have deliberately not built

• No zero-knowledge mode. Claiming it without a reviewed client-side encryption design would be worse than not having it.
• No public sharing links yet. Sharing is where file services most often leak data, and it is not worth shipping carelessly to fill a feature list.
• No scanning of your files. We do not index, analyse or train on your content. The system does not have a component that reads it.

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