Privacy by architecture: what ZeroStorage never collects

Most privacy policies describe intentions. This one describes schema. Every row below is something the database does not have a column for.

Not collected

• Third-party analytics trackers — page measurement runs on our own host.
• Advertising profiles or cross-site identifiers.
• Content of your files — we store bytes, we do not read them.
• Payment cards — USDT TRC20 only, so no card data ever lands here.

Collected, with a reason

• Account email, for sign-in and abuse contact only.
• Upload metadata: filename, size, hash, timestamps.
• Rate-limiting counters, so one client cannot starve everyone else.

Where the line sits

Self-hosting moves the trust boundary to hardware you control. Operator sovereignty means the person running the server decides retention — and also means a bad operator can change it. Run your own instance if that trade suits you; read our privacy policy if you are using ours.

What a request can still learn

Deleting columns is the easy half. A request still arrives with an IP address, a user agent, and a timestamp, and those three facts are already a fingerprint if you keep them forever. Logs are rotated on a short window, keep only the fields needed to answer an abuse report, and drop the rest. The transparency portal publishes how long that window is, so the claim is checkable rather than promised. If a takedown arrives for a file, the record we answer with is the file’s own metadata — not a shadow profile of everyone who viewed it.

That is also the honest limit of the claim: network data exists while a request is in flight, and pretending otherwise would be a different kind of marketing. The promise is narrower and testable — nothing about you is joined to the files you upload, kept past the window, or sold when the window closes.

Storage without surveillance is not a feature flag. It is the absence of a column.

Transparency reports and DMCA outcomes are published rather than buried — see the transparency portal.