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 keep this in plaintext: file size (bytes), creation/modification timestamps, source IP (30-day log), access frequency, and user-agent. Linked together, these signals are enough to profile your usage. They can also help re-identify you. That is the principle of traffic analysis. The logic of zero-knowledge transparency reports confirms it. What they can hand over under a legal request is metadata (connection logs, IP, timestamps). They never hand over the encrypted content, because they cannot decrypt it.

The bottom line

Zero-knowledge protects the content of your files. The provider cannot read what you store. Neither can an attacker who breaks into its servers. Neither can a state that serves a warrant. That is the crypto promise of Proton Drive, Tresorit, pCloud Crypto, and Nextcloud E2E.

But around that encrypted content sits an entire layer of signals that stay 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. When they leak, in 2026, that is often enough to rebuild your usage, your profile, and sometimes your identity.

The quiet lie in zero-knowledge marketing is the hint that a "zero-knowledge" service knows nothing about you. The truth has more shades. It does not know what is inside your files. But it knows exactly when you upload, from where, in what volume, and how often. For most use cases, that is enough protection. For a high-risk profile (journalist, activist, whistleblower), it is the weak link.

This article breaks down what Proton Drive, Tresorit, pCloud Crypto, and Nextcloud E2E do not encrypt. It shows what can be guessed from that. And it lists 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 (you cannot encrypt this client-side by design).

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

Proton Drive audit: what leaks despite OpenPGP

The Proton Drive whitepaper from 2023 (updated 2024) clearly lists the data kept unencrypted on the server side:

File size in bytes, rounded to the encryption block (16 KB by default). It lets someone tell apart a photo (3-5 MB), a PDF (<5 MB), a film (700 MB+), and a ZIP archive (variable).
Timestamps of creation, change, and last access, in UTC down to the second. They let someone trace daily activity and link it to other signals.
Internal identifier (UUID) for each file and each user. It lets someone tie access logs to files.
Source IP of each connection, kept for 30 days for anti-fraud/anti-abuse goals. It lets someone roughly place the user or spot country changes.
User-agent and version of the client used. It lets someone profile the platform and maybe target weak spots.
Access frequency per file, kept for speed goals (cache, prefetch).

A hash of the encrypted content may also be kept, used for intra-user deduplication. Such a hash does not let anyone recover the content. But it does let the provider know whether two encrypted files from the same user are the same. That helps save storage space. It is a problem if the user uploads the same sensitive file across several accounts.

Tresorit audit: similar model, less transparency

Tresorit encrypts content and filenames client-side (independent security audits confirm the build). But its public whitepaper is less detailed than Proton's. It says it keeps size and timestamps "for operational purposes" but does not state how long. Access logs are kept "as long as necessary" - vague legal wording.

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

pCloud Crypto audit: partial zero-knowledge

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

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

Say a pCloud user puts sensitive documents in the Crypto Folder and everything else (music, holiday photos) outside it. Then the Crypto/non-Crypto ratio itself is a telling piece of metadata. If 90% of an account's files sit in the Crypto Folder, that points to a privacy-minded user. An authority could care about that.

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 build among the services audited here. But:

The Nextcloud instance is still a normal web server. So source IP, timestamps, and access logs show up in Apache/Nginx logs - unless you turn them off on purpose (and lose debug help).
The size of encrypted files stays readable, because the server sets aside storage for it.
The E2E module works only with desktop and iOS/Android clients - not the web client - which limits use.

On paper, a self-hosted Nextcloud E2E instance in a protective country is the most defensive choice. In practice, the running cost (admin, updates, backups, TLS certificates) and the risk of human error make it a choice for skilled, technical users only.

What can be reconstructed from metadata

Three concrete mechanisms. These are not named cases. They show what metadata alone can reveal.

User profile reconstruction

From the upload/download timings, sizes and frequencies of a cloud account, you can sort a user into typical profiles - without ever decrypting the content. This is the principle of behavioral fingerprinting. Groups 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 shows up through burst uploads of even sizes (1-3 MB per file, which points to scanned PDF documents). They happen at odd hours (outside the 9 a.m.-6 p.m. office pattern). They come from varied IPs (which points to mobility or VPN). And they bring very spaced but recurring read accesses on the same file UUIDs. None of these guesses needs the content to be decrypted.

Identification by correlation

Identification by correlation means cross-checking 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 a legal request, be cross-checked with other sources to place a person. Proton's 2021 public case shows it. Under a Swiss court order, Proton had to log and then hand over an account's IP address - without ever decrypting any content.

In this kind of case, no content is decrypted. It is neither doable nor needed: connection metadata alone is enough to steer an investigation. That is exactly 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 spread of file sizes within a folder is telling. A folder with 30 files of 1.5 MB each points to PDF scans of black-and-white A4 documents - typical admin archiving. A folder with one 4 GB file points to a film. A folder with 200 files of 50-200 KB points to emails exported as .eml.

Paired with timestamps, this lets someone rebuild when the user archived what, without knowing anything about the content itself. For an investigation, that is more than enough to steer further requests or to guide a physical search.

Seven steps to limit leakage in 2026

None of these steps is costly or technically hard. Most take under an hour to set up.

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. To the cloud, the container looks like a single blob of fixed size (which you set). The provider sees "a 5 GB file" instead of "237 PDFs of 200 KB to 4 MB." The inner folder structure turns invisible.

Step 2 - Multi-hop VPN or Tor for access. Mask your source IP. A standard VPN (Mullvad, Proton VPN, IVPN) is enough for most cases. For high-risk profiles, use Tor and reach the cloud through their onion service if there is one (Proton runs its official onion service at protonirockerxow.onion).

Step 3 - Avoid uploads at set times. If you always upload at 6 p.m. after work, that is a signature someone can use. Vary the timing. Batch your uploads into uneven 1-2 hour windows.

Step 4 - Delete past versions. Zero-knowledge clouds often keep earlier versions of changed files. Each version has its own timestamp and size, so the time tree gets telling. Set your service to keep history for 7 days only, or clear it by hand.

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. That way a single leak does not expose your whole digital life.

Step 6 - Pay in cryptocurrency or cash voucher where you can. Proton accepts Bitcoin, pCloud accepts BitPay. Splitting your payment identity from your cloud account lowers traceability. For the most careful, pay with tumbled Bitcoin or Monero.

Step 7 - Read the yearly transparency reports. Proton, Tresorit, and pCloud publish numbers on government requests. Check each year: how many requests came in, how many were partly met, which countries asked. If your provider's numbers spike with no clear word about it, switch providers.

Our 2026 verdict

For most privacy-minded cloud users in 2026, the winning combination is still the one we documented in E2E vs zero-knowledge cloud storage: Proton Drive or Tresorit for content, access through native clients, paper recovery key. The metadata that leaks fits a threat model of "business rivals" or "passive state surveillance."

For high-risk profiles (journalist looking into state surveillance, whistleblower, exposed activist, dissident), plain 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 setup at the start and 5 minutes of friction per session. That is the price of standing up to metadata correlation in 2026 - a tiny cost next to the fallout of a successful de-anonymization.

Frequently asked questions

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.

Choix éditorial

4.5 / 5

Store your files privately → pCloud

Swiss privacy · 10 GB free · optional zero-knowledge Crypto

Société suisse depuis 2013Satisfait ou remboursé 10jFree 10 GB

Voir l'offre