The Walled Garden Approach

A category of email services has emerged over the past decade marketing itself as the solution to email surveillance. They promise end-to-end encryption, zero-knowledge architecture, and increasingly quantum-safe security. The marketing is polished, and the appeal to people who care about privacy is genuine.

These services are commonly called walled gardens: closed ecosystems where the full security promise only holds when both the sender and the receiver are inside the same garden, using the same provider's software, trusting that provider's key management. Step outside the wall, send to a Gmail address, receive from an Outlook account, use a third-party client, and the model changes substantially.

Most of the confusion around these services comes from loose use of three phrases: zero knowledge, zero trust, and zero access. They are not interchangeable, and they are not marketing adjectives. Each has a precise meaning, and once you hold them precisely, the walled garden's claims sort themselves out quickly.

The question is never whether a service encrypts. They all do. The question is where in the path the encryption happens, who controls the code and the keys, and whether the provider sits in the decryption path.

Three Phrases That Are Not Interchangeable

Zero knowledge is the strongest claim and the easiest to dispose of, because it is impossible for any email system regardless of how honest the provider is. Email runs on SMTP, and SMTP cannot move a message without exposing a stack of metadata in the clear: the To and From addresses, the routing path stamped header by header, the Message-ID, the message size, and the date and time down to the time-zone offset. Most clients volunteer still more, such as the mailer name and version and the originating IP. Every one of those fields is knowledge. A provider that can see who you correspond with, how often, from where, and when cannot be zero knowledge, even if it never reads a word of the body. We cover this at length in The Truth About Zero Knowledge / Zero Trust / Zero Access.

Zero trust is a threat-model property. It treats the provider as the adversary, not as a moral judgment but as a planning assumption, because a provider can be compromised, compelled, or can simply change its own code on the client or the server. The rule that follows is that code controlled by the adversary cannot be part of the trusted computing base. You cannot outsource zero trust to a provider, because no provider can be the party that guarantees it for you. That is not the same as saying every provider operation is suspect.

Zero access is the practical target for email. It means the provider is never in a position to read your mail, because it is never in the cryptography path that matters. It stops being absolute the moment the provider becomes part of that path in any way, and the moment the provider generates or stores your private key, even encrypted. The single most important part of the path is decryption: a provider kept out of the decryption path cannot read your mail no matter what it is later compelled to do.

One more distinction runs through everything below. Encryption can be end-to-end in form, encrypted on a device and decrypted on a device, and still not be trustless. If the software doing the key generation, encryption, and decryption is supplied by the provider, the math is sound but you are trusting the provider's code rather than the protocol. Trustless end-to-end encryption requires that the tools themselves be independent of the provider.

How Email Actually Works: The Four-Hop Path

Before evaluating any encryption claim, you need the path a message travels. Despite decades of complexity layered on top, the underlying architecture has not changed. Every message passes through four points: the sender who composes it, the sender's provider that accepts and forwards it, the receiver's provider that accepts and stores it, and the receiver who retrieves and reads it.

The two providers in the middle are where the model either holds or breaks. End-to-end encryption means the two ends do the cryptographic work and the two middles see only ciphertext they cannot decrypt. For that to be true in a trustless sense, the sender must encrypt before the message leaves their machine, using the receiver's public key, and the receiver must decrypt on their own machine with their own private key, using software outside the provider's control. Neither middle ever holds the means to decrypt.

That is the standard. Here is what actually happens with walled gardens.

Receiving Mail From Outside the Garden

This is the most common case. Someone on Gmail or Outlook sends you a message at your walled garden address, and like most people they did not encrypt it. Their provider handles it in plaintext and transmits it over SMTP wrapped in TLS for transit. Your walled garden provider receives it in plaintext, encrypts it for storage, and hands it to you to read.

Both providers saw your message in plaintext, and there is no way around that. The sender did not encrypt before transmitting, so the message arrives unencrypted at the receiving server. What the walled garden does next, encrypting it before writing it to disk, is correctly called zero-access storage encryption, not end-to-end encryption. A more accurate name for it is middle-out encryption: the middle of the chain encrypts the message and hands the result to the end, rather than the end doing the encrypting.

It is worth being precise about where the weakness actually is, because it is not the encryption-on-receipt itself. The provider seeing the message as it arrives is unavoidable, and encrypting an already-plaintext message for storage is harmless on its own. The weakness is what the typical walled garden does next: it encrypts to a key it generated and holds, and it lets you read by decrypting through software it controls. That places the provider inside the decryption path, which is where the trust actually lives.

This is the weaker of two possible forms of zero-access storage. In the weaker form the provider holds the key and decrypts for you, so you trust it on both ends. In the stronger form, which most walled gardens do not offer, the provider encrypts incoming mail to a public key you generated independently, holds only that public key, and stays out of the decryption path entirely. We return to that form below, because it is the whole difference between trust-us and trustless.

The storage encryption is still meaningful. If someone breaches the provider's servers, seizes them by legal order, or works there with bad intent, they cannot read your stored mail without also holding the decryption key. The last hop to your client is already protected by TLS in any modern setup, so the added transport value is narrow; the real benefit is encryption at rest. That is a genuine protection. It simply is not end-to-end encryption, and it does not protect you against the provider itself.

Sending Mail Outside the Garden

Now the reverse: you are inside the garden and you send to someone at a standard provider. Your provider has to deliver something that ordinary email infrastructure can process, and SMTP does not speak the garden's proprietary format. One of two things happens.

The provider can decrypt and transmit in plaintext. The message goes out over standard SMTP, either decrypted by the provider for delivery or composed in plaintext to begin with. The receiver's provider gets plaintext, and the receiver reads plaintext. This is not end-to-end encryption in any direction; the provider handled plaintext at every step required to send it.

Or the provider can send a link. Some gardens handle external recipients by emailing them a notice that says, in effect, someone has sent you a secure message, click here to read it, and we offer this as a feature too. The recipient clicks through to a page hosted by the provider and reads the message, or downloads the attachment, through the provider's web interface, after authenticating or entering a password the sender shared separately.

This second option is worth naming plainly: it is a web portal with a password. The message never left the garden's infrastructure, and the recipient reads it through the provider's software on the provider's servers. It is the same trust-us shape as taking a file, locking it with a passphrase, and telling the other person the passphrase, only dressed in a browser window. There are no ends involved in any cryptographic sense, and it remains trust-us even when the locking and unlocking run in the browser, because the provider wrote and serves that code.

Both Parties Inside the Same Garden

This is where the E2EE claim is most plausible. When both sender and receiver use the same service, the provider has both public keys and can encrypt the message to the recipient's key before it is ever stored, so neither transmission nor storage exposes plaintext, especially since the path is often the same server. This can be end-to-end encryption in form, and it is the closest most walled garden users ever get.

Whether it is also trustless end-to-end encryption is a separate question, and it turns entirely on key custody and code control. Trustless encryption requires that the provider cannot decrypt, not that it chooses not to. That depends on whether the provider generated your keys, stores your private key, and controls the software that performs the decryption. We have written separately about why provider-generated and provider-stored keys undermine the model.

Most walled gardens generate your key pair for you, encrypt your private key with a passphrase you give them, store that encrypted private key on their servers, and serve the code that unlocks it every time you log in. A provider in that position can generate weaker keys, capture your passphrase through the code it serves, deliver modified code to a single targeted user, log your private key at the moment it is used, or quietly comply with an order to do any of the above.

These are not alarmist hypotheticals. They are the direct consequence of the provider being inside the trusted computing base for both key generation and decryption. Code delivered by the party you are trying to exclude cannot be the code performing your encryption and decryption. This is the line between end-to-end in form and end-to-end that is actually trustless.

This Has Already Happened

In 2007, Hushmail was one of the most trusted encrypted email providers, and it was compelled by court order to modify the Java applet it delivered to a specific user's browser so that it captured the plaintext before encryption and passed it to law enforcement. The cryptography was never broken. The provider simply changed the code it controlled, for one targeted user, under an order it could not disclose.

Any service that delivers your encryption code can be made to do the same, and you would have no way to know. This is exactly why trustlessness is an architectural property and not a promise: a provider that is capable of changing your decryption code is a provider whose good behavior you are forced to trust.

The Quantum-Safe Marketing Angle

Several gardens now advertise quantum-safe or quantum-resistant encryption. Quantum computing is a genuine long-term threat to certain algorithms, specifically the factoring and discrete-logarithm problems behind RSA and classical elliptic-curve cryptography, and post-quantum algorithms such as those NIST standardized in 2024 are designed to resist quantum machines that do not yet exist at scale. Adopting them is a reasonable forward-looking decision, and we default to AES-256-GCM, which NIST considers quantum resistant.

What we dispute is the implication that quantum-safe addresses the actual threat for ordinary email users. A quantum-safe algorithm protects data stored today against a powerful quantum computer years from now. It does nothing about the provider seeing your message in plaintext when it arrives over SMTP, the provider capturing your passphrase through code it serves, a legal order compelling the provider to alter its client code before encryption, as happened to Hushmail, or outbound mail leaving as plaintext SMTP.

In every scenario where the garden's E2EE already breaks down, the strength of the algorithm is irrelevant. Quantum-safe encryption of data the provider can already reach is not meaningfully safer. It is the same access, with a harder lock on a door the provider already holds a key to. The near-term threat for nearly everyone is provider access, legal compulsion, data breach, and insider risk, and post-quantum marketing addresses none of them. It just sounds impressive, which is why it works.

The Structural Costs

Beyond the encryption limits, walled gardens impose costs that rarely appear in the marketing.

There is vendor lock-in. Gardens tend to use proprietary encryption formats, APIs, or storage schemas, so taking your encrypted mail elsewhere is often difficult or impossible without the provider's cooperation and software. Your encrypted mail is readable only through their tools. The garden protects you, and it also contains you.

There is correspondent lock-in. The full promise applies only when both parties are inside the same garden, so to communicate securely with an outsider you must persuade them to join, accept the degraded link experience, or fall back to plaintext SMTP like everyone else. The model depends on network effects the provider has every incentive to expand.

There is client lock-in. Because decryption is tied to the provider's software, its web interface, its app, its browser extension, you cannot freely choose how you read your mail. Connecting a standard IMAP client, which would remove the provider's software from the trust equation, typically breaks the encryption model. You depend on the provider's software continuing to exist, to work, and to stay trustworthy.

And there is the web-delivery risk. Many gardens deliver their encryption through Progressive Web Apps or browser JavaScript. A PWA is, in functional terms, a browser tab presented as a standalone application. The code that handles your private key is downloaded from the provider every time you open it, the provider can change that code at any moment, including under an order you will never hear about, and you cannot audit what is actually running when you use it.

What Standards-Based Encryption Gives You Instead

The alternative to walled garden encryption is not weaker security. It is standards-based encryption, today PGP/GPG or S/MIME, used independently of any provider.

When you generate your own key pair with GnuPG, Kleopatra, or any other independent tool and hand your provider only the public key, the structure changes. The provider never touched your private key, not during generation and not ever. It cannot decrypt mail encrypted to your public key, regardless of what it is compelled to do or what happens to its servers. You decrypt with software you chose, that the provider did not write and cannot update. And you can leave your provider and take your encrypted mail with you, because it decrypts the same way with the same key.

This matters most of all on the receiving side. Your correspondents can encrypt to your public key from any service with any standards-compatible tool, and when a correspondent encrypts before sending, the message reaches your provider already encrypted. The provider never sees the plaintext at any point, not even for the instant it takes to encrypt on receipt. That is full trustless end-to-end encryption, the ideal case, where the provider has no part in the cryptography at all and is reduced to a dumb store-and-forward. It is a stronger position than the encryption-on-receipt described earlier, which still has to touch plaintext once because the sender did not encrypt.

This works with any provider that supports IMAP. It is not a proprietary capability; it is the natural result of using an open standard correctly.

Removing the Provider From the Path

The difference between a walled garden and an open, standards-based approach is clearest in what happens to the provider's role. In a walled garden the provider is inside the cryptographic process. It generated your key, it stores your private key, it supplies the code that uses your private key, and it is present in some form at every stage.

In a properly configured open architecture the provider can be removed from the cryptographic process entirely, or removed from just the decryption side to keep the convenience of automatic storage encryption. Our most secure configuration shows how this works. You generate your own PGP key pair with independent software, upload only the public key, enable automatic PGP encryption of incoming mail, and read with a third-party client such as Thunderbird.

Mail that arrives unencrypted reaches us in plaintext, exactly as it does at any provider including walled gardens. If you have enabled PGP auto-encryption, we encrypt it to your public key first. Then, whether or not PGP is enabled, the message and its headers are wrapped in AES-256-GCM before being written to disk, so with PGP on, what lands on disk is an AES-256-GCM-wrapped PGP message: two independent layers, the outer one quantum resistant by NIST guidelines.

What is different is what happens next. Because we never generated your keys, never stored your private key, and play no part in the decryption software you use, we are architecturally incapable of reversing the PGP layer. We locked the message with a lock only your private key opens, and your private key has never been near us. You decrypt in Thunderbird, K-9 Mail, or any PGP-capable client, software we did not write, cannot update, and do not control. We cannot modify the decryption path, capture a passphrase, or reach the plaintext after encryption.

This is the stronger form of zero-access storage, and it is genuinely trustless on the decryption side. Even if we were compelled, compromised, or otherwise forced to act against you, we have nothing to betray, because we do not hold the key and we do not control the software that decrypts. When mail arrives unencrypted, the encryption-on-receipt is the only point where we touch it at all, and that step is harmless on its own because the message was already plaintext when it reached us.

When the sender encrypts the message before sending it, even that single touch disappears. The message arrives as ciphertext, we store it as ciphertext, and we hand it back as ciphertext. We are nothing more than a blob store, an opaque container holding bytes we cannot read and have no key to open. There is no plaintext moment to capture, no decryption path to subvert, and nothing for a court order or an attacker to extract. This is the ideal case, and it is the plain store-and-forward role email servers were always meant to play, except that here the contents stay sealed from us from end to end.

You can apply this automatic encryption to all incoming mail, to mail for specific aliases only, or to mail matching a filter rule, because PGP encrypt is available as a filter action. The algorithm strength matters less than the marketing suggests; the path is the weakness, not the cipher. What matters is whether the provider can decrypt at all, and in this configuration we cannot.

None of this is proprietary. It works with any provider that supports IMAP and PGP, it does not depend on your correspondents joining anything, it does not lock you into a client, and it lets you leave without losing access to your mail. The walled garden can only credibly promise as much when both parties are inside it and you trust its key management, code delivery, and storage to be exactly as described, which is a load-bearing assumption, not a cryptographic guarantee.

Published March 2026. Updated June 2026.