What metadata does a zero-knowledge cloud provider still see — and can it identify you?

Even Proton Drive and Tresorit retain in plaintext: file size (bytes, block-rounded), creation/modification timestamps, source IP (logged 30 days), access frequency, and connection user-agent. Through correlation, these usage signals (upload timing, file sizes, frequency, IP) make it possible to profile an account and can help re-identify a user — this is the well-known principle of traffic analysis and metadata correlation. Zero-knowledge hides content but does not hide usage patterns. For high-risk profiles, this residual layer requires additional mitigation: VPN, Cryptomator containers, irregular upload schedules.

What exactly is metadata in the cloud context?

Metadata is data about data. In a cloud environment, it covers all the information that describes a file without revealing its contents: size in bytes, creation date, modification date, MIME type, name (sometimes), folder path, hash, internal identifier, uploader IP, client user-agent, timestamp of each access. A zero-knowledge service encrypts the content and ideally the name, but almost always retains size, timestamps, and access logs in plaintext on the server side for operational reasons (billing, performance, deduplication, debugging).

Does Proton Drive really encrypt everything, including filenames?

Proton Drive encrypts both file content and filenames/folder names client-side using OpenPGP. However, Proton's 2023 whitepaper explicitly states that the following remain unencrypted: the size of each file (in bytes, rounded to the encryption block), creation and modification timestamps (UTC), the internal identifier (UUID) of each file and user, the source IP of each connection (logged for 30 days for anti-fraud purposes), and access frequency. These data points allow Proton to provide the service and would remain readable under a Swiss warrant — even though the content itself stays out of reach.

Do Tresorit and pCloud Crypto have the same leaks?

Tresorit encrypts content and filenames client-side (the implementation is confirmed by independent audits), but retains size, timestamps, and access logs. pCloud Crypto only encrypts the Crypto Folder; the rest of the pCloud account (files outside that folder) is managed with server-side keys. Size, timestamps, and modification history are also retained in plaintext for all files. No mainstream zero-knowledge service encrypts timestamps or sizes in 2026 — it is a fundamental trade-off between privacy and usability.

Can someone really de-anonymize me from metadata alone?

Rarely from a cloud's metadata alone, but it contributes heavily through correlation. Traffic analysis and metadata correlation (timing, sizes, frequency, IP) are recognized techniques for profiling or helping to re-identify a user without accessing content. One public case illustrates it: in 2021, Proton confirmed it had been legally compelled by a Swiss court to log and then disclose the IP address of an account — proof that connection metadata can be obtained by legal process even from a zero-knowledge provider, while the encrypted content itself stays out of reach. For ordinary use the threat stays limited; for a targeted profile, it is precisely why you must go beyond simple zero-knowledge.

Does self-hosted Nextcloud solve the problem?

Partially. Self-hosting Nextcloud on a VPS moves you from the 'provider sees the metadata' model to the 'VPS host sees the metadata' model — you shift the problem rather than solve it, unless you rent your VPS from an operator outside the 14 Eyes (1984 Hosting Iceland, Njalla Nevis, BuyShared Bulgaria) and pay in cryptocurrency. You can also harden things technically: a Tor hidden service for access, disabling access logs, LUKS disk encryption — but maintenance cost and operational responsibility explode. For most users, Proton Drive or Tresorit remains safer in practice than a poorly maintained Nextcloud instance.

What concrete steps should I take in 2026 to limit metadata leakage?

Seven accessible actions, ordered by impact: (1) access your cloud via a multi-hop VPN or Tor to mask your source IP; (2) bundle sensitive files into encrypted containers (Cryptomator, VeraCrypt) before upload — the provider sees only a single blob of uniform size; (3) avoid uploads at predictable times (same daily schedule enables correlation); (4) periodically delete historical versions to reduce the temporal tree; (5) encrypt filenames via an anonymous prefix (Cryptomator does this); (6) separate cloud archive from cloud collaboration — don't centralize everything; (7) read transparency reports to know how many and which metadata your provider has already handed to authorities.

Cloud metadata: what your zero-knowledge provider still sees (2026)

What metadata does your zero-knowledge cloud still expose?

Zero-knowledge encrypts file content but not usage signals. Proton Drive, Tresorit, and pCloud Crypto all retain in plaintext: file size (bytes), creation/modification timestamps, source IP (30-day log), access frequency, and user-agent. Through correlation these signals are enough to profile usage and can contribute to re-identification — that is the principle of traffic analysis. And the logic of zero-knowledge providers' transparency reports confirms it: what they can hand over under legal request is metadata (connection logs, IP, timestamps), never the encrypted content they cannot technically decrypt.

The bottom line

Zero-knowledge protects the content of your files: neither the provider, nor an attacker who breaches its servers, nor a state that imposes a warrant can read what you store. That is the cryptographic promise of Proton Drive, Tresorit, pCloud Crypto, and Nextcloud E2E.

But surrounding that encrypted content orbits an entire layer of signals that remain in plaintext on the server side: the size of each file, creation and modification timestamps, access logs, source IP, connection frequency, and sometimes folder structure or the hash of the encrypted content. These signals are metadata — and their leakage, in 2026, is enough in many cases to reconstruct your usage, your profile, and sometimes your identity.

The implicit big lie in zero-knowledge marketing is the suggestion that a "zero-knowledge" service knows nothing about you. The reality is more nuanced: it doesn't know what is inside your files, but it knows precisely when you upload, from where, in what volume, and at what frequency. For the vast majority of use cases, that is sufficient protection. For a high-risk profile (journalist, activist, whistleblower), it is precisely the weak link.

This article breaks down what Proton Drive, Tresorit, pCloud Crypto, and Nextcloud E2E do not encrypt, what can be inferred from that, and the seven concrete steps to limit leakage without blocking your workflow.

What does a zero-knowledge cloud provider actually see despite encryption?

Server racks lit in blue in a data center

To understand what leaks, you need to distinguish three data zones in any cloud:

Content zone — the raw bytes of the file (text, image, video). Encrypted client-side by zero-knowledge services.
File metadata zone — name, size, MIME type, timestamps, internal identifier. Partially encrypted depending on the service.
Technical metadata zone — source IP, user-agent, client version, latency, request frequency, session duration. Never encrypted (impossible to encrypt client-side by construction).

Serious zero-knowledge protects zone 1 and encrypts part of zone 2 (names, folder structures). Zone 3 remains systematically in plaintext because servers need it to function.

Proton Drive audit: what leaks despite OpenPGP

The Proton Drive whitepaper from 2023 (updated 2024) explicitly lists the information retained unencrypted on the server side:

File size in bytes, rounded to the encryption block (16 KB by default). Allows distinguishing a photo (3–5 MB), a PDF (<5 MB), a film (700 MB+), a ZIP archive (variable).
Timestamps of creation, modification, and last access, in UTC at second resolution. Allows tracing daily activity and correlating with other signals.
Internal identifier (UUID) for each file and each user. Allows joining access logs to files.
Source IP of each connection, retained for 30 days for anti-fraud/anti-abuse purposes. Allows approximately locating the user or detecting country changes.
User-agent and version of the client used. Allows profiling the platform and potentially targeting vulnerabilities.
Access frequency per file, retained for performance purposes (cache, prefetch).

A hash of the encrypted content may also be retained, used for intra-user deduplication. Such a hash does not allow recovering the content, but it does let the provider know whether two encrypted files belonging to the same user are identical — useful for saving storage space, problematic if the user uploads the same sensitive file across multiple accounts.

Tresorit audit: similar model, less transparency

Tresorit encrypts content and filenames client-side (independent security audits confirm the implementation). But its public whitepaper is less detailed than Proton's: it mentions retaining size and timestamps "for operational purposes" without specifying retention periods. Access logs are retained "as long as necessary" — vague legal language.

Tresorit publishes a transparency report, but with less granularity than Proton. By construction, what a zero-knowledge service can hand over under legal request is limited to metadata (logs, IP, timestamps): the encrypted content stays out of reach. The precise detail of the metadata handed over is generally not made public.

pCloud Crypto audit: partial zero-knowledge

The pCloud Crypto model encrypts only the Crypto Folder — a separate folder activated via the paid add-on. The rest of the account (files outside Crypto) is managed with server-side keys. For the Crypto Folder:

Content and filenames are encrypted client-side (key derived from the Crypto password).
The size of Crypto files remains in plaintext, as with the rest of the account.
Timestamps are retained in plaintext.
The hash of the encrypted content is used for deduplication.

For a pCloud user who places sensitive documents in the Crypto Folder and everything else (music, holiday photos) outside it, the Crypto/non-Crypto ratio itself is a revealing piece of metadata. If 90% of an account's files are in the Crypto Folder, that suggests a privacy-conscious user — information that could be of interest to an authority.

Nextcloud E2E audit: best granularity, maximum friction

Nextcloud's End-to-End Encryption module, since version 25, encrypts content, names, and folder structure client-side. It is the most complete implementation among the services audited here. But:

The Nextcloud instance remains a traditional web server, so source IP, timestamps, and access logs are visible in Apache/Nginx logs — unless you explicitly disable them (losing debug capability).
The size of encrypted files remains readable because the server allocates storage.
The E2E module is only compatible with desktop and iOS/Android clients — not the web client — which restricts usage.

On paper, a self-hosted Nextcloud E2E instance in a protective jurisdiction is the most defensive solution. In practice, the operational cost (administration, updates, backups, TLS certificates) and the risk of human error make it a solution reserved for technically sophisticated profiles.

What can be reconstructed from metadata

Three concrete mechanisms. These are not named cases but illustrations of what metadata alone can reveal.

User profile reconstruction

From the upload/download timings, sizes and frequencies of a cloud account, one can reasonably classify a user into typical profiles — without ever decrypting the content. This is the principle of behavioral fingerprinting: categories such as "amateur photographer," "creative freelancer," "office employee," "university student," or "activist / journalist with high document load" show different usage signatures.

The "activist / journalist" profile is signaled by burst uploads of homogeneous sizes (1–3 MB per file, suggesting scanned PDF documents), at irregular hours (outside the 9 a.m.–6 p.m. office pattern), from varied IPs (suggesting mobility or VPN), with very spaced but recurring read accesses on the same file UUIDs. None of these inferences requires decrypting the content.

Identification by correlation

Identification by correlation means cross-referencing one service's metadata with other traces (another provider's logs, location data, various records). A zero-knowledge provider cannot hand over content, but its connection logs (source IP, timestamps) can, under legal request, be cross-referenced with other sources to place a person. Proton's 2021 public case illustrates it: under a Swiss court order, Proton had to log and then disclose an account's IP address — without ever decrypting any content.

In this kind of scenario, no content is decrypted — neither technically feasible nor necessary: connection metadata alone is enough to steer an investigation. That is precisely what a journalist covering sensitive topics must guard against.

Folder structure deduction from size and structure

Even when filenames are encrypted (as in Proton Drive and Tresorit), the size distribution within a folder is revealing. A folder containing 30 files of 1.5 MB each suggests PDF scans of black-and-white A4 documents — typical administrative archiving behavior. A folder containing one 4 GB file suggests a film. A folder containing 200 files of 50–200 KB suggests emails exported as .eml.

Combined with timestamps, this allows reconstructing when the user archived what, without knowing anything about the content itself. For an investigation, that is more than enough to direct further requests or to guide a physical search.

Seven steps to limit leakage in 2026

None of these steps is expensive or technically complex. Most can be implemented in under an hour.

Step 1 — Local encrypted container before upload. Instead of uploading file by file, place sensitive documents in a Cryptomator container (free, cross-platform) or a VeraCrypt volume. The container appears to the cloud as a single blob of fixed size (which you configure). The provider sees "a 5 GB file" instead of "237 PDFs of 200 KB to 4 MB." The internal folder structure becomes invisible.

Step 2 — Multi-hop VPN or Tor for access. Mask your source IP. A standard VPN (Mullvad, Proton VPN, IVPN) is sufficient for most cases. For high-risk profiles, use Tor with access to the cloud via their onion service if available (Proton exposes its official onion service at protonirockerxow.onion).

Step 3 — Avoid uploads at predictable times. If you always upload at 6 p.m. after work, that is an exploitable behavioral signature. Vary the timing, batch your uploads into irregular 1–2 hour windows.

Step 4 — Delete historical versions. Zero-knowledge clouds often retain previous versions of modified files. Each version has its own timestamp and size — the temporal tree becomes revealing. Configure your service to limit history to 7 days, or purge manually.

Step 5 — Separate archive and collaboration. Don't put sensitive archives and shared documents on the same cloud account. Use two providers or two accounts to ensure a single leak doesn't expose your entire digital activity.

Step 6 — Pay in cryptocurrency or cash voucher where possible. Proton accepts Bitcoin, pCloud accepts BitPay. Decoupling your payment identity from your cloud account reduces traceability. For the most cautious, pay with tumbled Bitcoin or Monero.

Step 7 — Read annual transparency reports. Proton, Tresorit, and pCloud publish statistics on government requests. Check every year: how many requests received, how many partially fulfilled, which jurisdictions are requesting. If your provider's numbers spike without transparent communication, switch providers.

Our 2026 verdict

For the majority of privacy-conscious cloud users in 2026, the winning combination remains the one we documented in E2E vs zero-knowledge cloud storage: Proton Drive or Tresorit for content, access via native clients, paper recovery key. The metadata that leaks is compatible with a threat model of "commercial competition" or "passive state surveillance."

For high-risk profiles (journalist investigating state surveillance, whistleblower, politically exposed activist, dissident), classic zero-knowledge is not enough. You need to stack:

Cryptomator container before upload (layer 1)
Access via Tor or multi-hop VPN (layer 2)
Swiss provider outside the 14 Eyes (layer 3)
De-anonymized crypto payment (layer 4)
Account isolated from other nominal accounts (layer 5)

This stack costs 1–2 hours of initial setup and 5 minutes of friction per session. That is the price of resistance to metadata correlation in 2026 — a trivial cost compared to the consequences of a successful de-anonymization.