What end-to-end encrypted storage hides from the server, and what it still sees

End-to-end encrypted storage means the server keeps your files in a form it cannot read; only your own devices hold the keys that open them. It does not mean the server learns nothing: depending on the design, it can still see when you sync, how much you store, which device is talking and, if the design is careless, it can even tamper with what you get back.

This post separates the two halves: what end-to-end encryption hides from the server, and what it still sees. It ends with three questions to ask any storage that calls itself "zero-knowledge", and shows how Havenfold answers them today. Havenfold is pre-alpha: do not use it for real data.

What end-to-end encryption hides

In ordinary cloud storage, your files are encrypted on the way to the server and again on its disks, but the company holds the keys. That protects you from someone stealing a disk; it does not protect you from the company, from anyone who breaks into its systems, or from a request it must answer.

End-to-end encryption moves the keys to your devices. A file is encrypted before it leaves your phone and decrypted only on another device you approved. The server stores sealed data:

• Content: the text of a note, the pixels of a photo, the pages of a document.
• Usually names and structure: good designs also encrypt file names and folder names, so the server does not see "medical-report.pdf".
• Sharing secrets: when you share with a family member, the key is passed between your devices, not handed to the server.

What the server can still see

This is the part product pages tend to skip. Even with perfect encryption of content, a server that stores and relays your data is in a position to observe:

• Timing: when you upload, when another device downloads, how often you sync.
• Size: how big each item is, and how much you store in total. A sealed file still has a size.
• Network addresses: the IP address each device connects from, unless traffic goes through something that hides it.
• Who you are: if the service needs an account with an email or phone number, the server knows whose sealed data it holds.
• Who shares with whom: if sharing goes through the server, it can often see which accounts are linked.

None of this reveals what your note says. Together, though, it can reveal patterns: that a family syncs every evening, that a large file appeared on the day of a hospital visit, that two accounts belong to the same household.

When the server is not just curious

A further question is what happens if the server is malicious rather than merely curious. In 2024, researchers at ETH Zurich analysed several end-to-end encrypted cloud storage services under exactly this assumption, in a paper titled "End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem". Their lesson was not that end-to-end encryption is pointless, but that the details matter: how keys are protected and whether the client checks that data was not swapped, injected or altered. The attacks they describe include a server injecting files into a user's storage and tampering with file data. A design that encrypts content but lets the server inject or alter files still leaves a real attack.

Three questions to ask any "zero-knowledge" storage

• Who holds the key, and how is it recovered? If the company can reset your password and give you back your files, it can reach the key. Real end-to-end recovery depends on something you or people you trust hold.
• What does the server still see? Ask specifically about timing, size, network addresses, identity and the sharing graph. An honest answer is never "nothing".
• What if the server lies? Are changes signed by the device that made them, and does every device check those signatures before accepting data?

How Havenfold answers these today

Havenfold turns the devices a family or a small business already owns into their own end-to-end encrypted cloud, with no accounts and no centre. Here is how it handles the three questions, and where it is honest about limits.

• Keys live on devices. Each device makes its own keys; there are no accounts. Shared data lives in collections, and each change is an encrypted, signed operation. Keys that must survive a lost phone are split into shares held by family members and devices with a security chip; no single holder can open them alone. That vault is not released before an independent audit.
• The box holds what it cannot read. A Family Box is a spare machine that stays on and keeps sealed copies so devices can catch up while others are offline. In the project's demo, which runs the real core on a local test network, the output says: "The box keeps a sealed copy of the note but has no key for it (reading it on the box returns nothing)". A later line shows a phone that was switched off getting the note from the box when it came back.
• The box still sees traffic. Havenfold's design principles state it plainly: "The box sees traffic metadata, the worker sees the content of the jobs it runs." Separating roles separates knowledge, but it does not make metadata disappear.
• Changes are signed. Every change is signed by the device that made it and checked against the family's signed membership record, so a member who was removed cannot keep writing.

Where it stands: Havenfold is pre-alpha. It has not yet run in a real home, and there has been no independent security audit. Do not use it for real data. The design and code are open, so you can check every claim above in the repository.

Summary

• End-to-end encrypted storage hides content, and in good designs file names, from the server.
• It has limits: timing, size, network addresses, identity and sharing links can remain visible, depending on the design.
• A malicious server is a harder test than a curious one; the details of key protection and integrity checks decide whether the encryption holds.
• Ask who holds the key, what the server still sees, and what happens if the server lies.
• Havenfold keeps keys on devices, signs every change and says openly that its box sees traffic metadata. It is pre-alpha and not for real data.