Position · v1.0

Security Philosophy

A short, plain-English statement of how DRIVUNO thinks about your data — and what we refuse to ask you to trust us with.

The premise

Traditional clouds rely on provider trust. You hand over your files, and you trust the provider's staff, processes, jurisdictions, and partners not to read them. We think that model is the wrong default for sensitive work. DRIVUNO is built so the provider does not have to be trusted with the content itself.

Principles

Privacy by architecture, not by policy

A privacy policy can change. An encrypted blob cannot suddenly become readable. Our guarantees are wired into the cryptography, not just the legal terms.

Encryption before upload

Content is sealed on your device before it leaves the network boundary. The server only ever sees ciphertext and sealed envelopes.

User-controlled keys

Your password derives your master key locally. Recovery factors wrap (not escrow) that key. We have no key custody role.

Minimal trust assumptions

We design for the case where parts of our own stack are compromised: hostile DBA, malicious storage, leaked logs. Each layer is treated as untrusted by default.

Transparency over reassurance

We publish what we do, what we cannot do, and the dates we are working towards. If a security event happens, we say so publicly and quickly.

Calm, not fear

We do not sell anxiety. We document the architecture and let it stand on its own. No "unhackable," no "absolute security," no anti-government rhetoric.

Verifiable, not just promised

A claim about privacy is only as good as the mechanism that keeps it true after the next code change. So we treat "no plaintext leaves the client" as an engineering invariant to be checked automatically, not a statement to be trusted on faith:

A CI privacy gate

A browser-level test suite runs on every change and fails the build if any sensitive payload — an upload, a download, a key rewrap — would ever cross the network or hit disk unencrypted.

RLS fuzzing

Automated fuzzing exercises our Postgres Row-Level Security policies, RPCs, and triggers with adversarial inputs, looking for the one path that would let a query token read another user's row.

Release transparency

Security-relevant changes are logged on a public changelog with dates, so the history of what shipped — and when — is independently checkable, not just asserted after the fact.

No escrow, ever

Key escrow — any mechanism that lets a third party unwrap your master key without your password or your own recovery factors — is the single feature we refuse to build, under any pressure: business, legal, or convenience. Every recovery path we offer (Recovery Kit, Recovery Key, optional email or SMS factors, backup master key) wraps your master key; none of them store it in a form anyone but you can open. The consequence is symmetric: we cannot help you if you lose every factor, and we cannot be compelled to help anyone else either.

What this rules out

Some product decisions are easy because they violate the philosophy:

No server-side scanning, AI analysis, or content moderation of user files.
No server-side password reset. The cryptography does not allow it; neither do we.
No silent metadata expansion: every field we collect appears in the Metadata Policy.
No telemetry of file contents, even aggregated.
No marketing claims that exceed what the architecture actually delivers.

What this commits us to

A public threat model describing what we protect and what we don't.
A public security roadmap with dated commitments.
A coordinated vulnerability disclosure policy with safe harbor.
An incident response playbook and a public changelog.
External cryptography review on the roadmap, followed by a full penetration test.

“The encrypted vault for the files you cannot afford to expose.”