Privacy is a different product

A privacy setting implies that the product on either side of it is the same product. Flip it on, keep everything you had, lose only the part where a company can read your files. That implication is false wherever the intelligence runs on a server, and it is false for a reason no engineering budget reaches.

Server-side intelligence has to read what it works on. An embedding model reads the text before it makes a vector of it. A search index reads the text before it can rank it. A database cannot match a pattern inside a blob it holds no key for, and a distance operator cannot measure between two things it cannot decode. End-to-end encryption is precisely the decision that the server holds no key. So the mechanism is a subtraction rather than a dial: encryption removes the readable text that server-side intelligence consumes, which makes the private version and the capable version two products rather than two settings of one, and the control between them a boundary.

Proton ships the honest form of this and documents it in public. Message content search in Proton Mail is built in the browser and the index never leaves the device, because the server holds every message in a mailbox and no key to any of them, while the client can decrypt anything it holds but never holds the whole mailbox at once. The consequences appear in Proton’s own support pages rather than in someone else’s review. The index is bounded by what the browser will store, so a large mailbox displays a date past which its own contents cannot be searched, and a person on an older machine waits while the index builds. None of that is a defect. It is the product that end-to-end encryption makes possible, described accurately by the people who built it.

Our own architecture notes reach the same finding in blunter language, that end-to-end encryption and server-side processing are mutually exclusive and cannot be had at once, alongside a figure for how far on-device search would fall short of the server-side path. We grade that figure as what it is. It is an engineering estimate written down before anyone measured it, and the capability it describes is not something we ship; the design sits in our documentation under an explicit ruling that it is not an active product claim. That is the part worth keeping. A fork you have not built is still a fork you can describe honestly, and describing it honestly now is what stops a flattering sentence from being written about it later.

The trade underneath is not really cryptographic. Someone choosing the private version is exchanging search that finds the thing they half remember for the certainty that nobody else can find it at all, and both of those are real goods whose prices move with what a person is carrying that year. The dishonesty is never in the tradeoff. It is in the checkbox, because a checkbox is a claim about size, and it says the thing on the other side is small. Price the fork out loud, name the capability that degrades and by roughly how much and on whose word, and the choice stops being something done to a person and becomes the thing it always was, someone deciding what their own words are for.