Security, without the flattery
This page summarises our threat model in plain language — including the parts we'd rather not lead with. A privacy product that overstates its guarantees is worse than one that states modest guarantees accurately.
What we protect
- File content. Files are encrypted on your device before upload. The server, the database, and object storage hold ciphertext only.
- Filenames and folder names. Names are encrypted too. On the server, every file and folder is an opaque identifier.
- Key material. Your passphrase, and every key derived from it, never reaches the server. What we store is wrapped key material that is useless without your passphrase.
The consequence: an attacker who steals our object storage gets encrypted chunks under meaningless names. An attacker who steals our metadata database additionally gets folder-tree shape and wrapped keys — still no content, and no names.
What we can't protect
The browser is the weakest way to use Drive. The web app's JavaScript is delivered by our server on every visit. A malicious or coerced server could serve modified JavaScript that steals your passphrase — and then the encryption protects nothing. This is an unavoidable limitation of end-to-end encryption delivered through a browser, and it applies to every competitor in this space.
The desktop app is the trust anchor. Its code is a build you install once and verify, not a page that can change silently between visits. If the stakes are high, use the desktop app. Subresource integrity and reproducible, verifiable builds for the web app are on the roadmap; today, desktop is the answer.
- Metadata shape stays visible. We can see file sizes, file counts, folder-tree shape, timestamps, and sharing relationships between account IDs. A 4 GB file modified nightly is identifiable as a pattern. Padding sizes is a possible future mitigation; it is deliberately not built yet.
- Our identity provider sees you sign up. Authentication runs through Clerk. Clerk sees your signup email address and your IP addresses — and so do we, in access logs. Anonymous signup is a documented goal, not a shipped feature.
- A compromised device is out of scope. If malware is on your machine, your unlocked data is on it too. No end-to-end encrypted system defends against that.
- Sharing requires trust in key exchange — for now. A malicious server could substitute public keys while a share is being set up, inserting itself as a recipient. Shares are cryptographically signed from day one, so a future client can verify history retroactively, but fingerprint-verification UX is still ahead of us.
Under legal compulsion
We can produce
- Account email address
- IP addresses and access timestamps
- File sizes and folder-structure shape
- The sharing graph between accounts
- Ciphertext
We cannot produce
- File content
- Filenames
At any price, under any order. Not a policy — an architectural fact. We hold no keys.
The short version
Drive makes it impossible for us — or anyone who compromises or compels us — to read your files. It does not hide that you use the service, how much you store, or when. Those are real, accepted limits, and we'd rather you know them than discover them.