End-to-end encryption, explained without the jargon

A fiduciary office in Chur sends out the same form once a year: income, property, children, deductions. The form tool’s website says “encrypted”. That is reassuring, and it does not answer the question that matters — who ends up with the answers in plain text?

The word appears on almost every product page now, and it means something different depending on where it is applied. The difference is not a technicality for specialists. It decides who can read the content. And it has a flip side that explanations usually skip: what do you give up when nobody except the recipient can read anything? That second part is the more interesting one.

Three meanings of “encrypted”

Term	What is protected	Who can decrypt
In transit	The path between a device and a server	Both endpoints: the browser and the provider’s server
At rest	The storage media the data sits on	The service that manages the key
End to end	The content itself, from entry to reading	Only whoever holds the key

In transit is the normal case today: the padlock in the address bar stands for TLS. The TLS 1.3 specification puts the property plainly — data sent over the channel after it is established is only visible to the endpoints. That is exactly the point: the server is one of those endpoints. There the content is in plain text again, before anything else happens to it.

At rest means the data does not sit on the disks as readable text. The key for that is managed by the service that serves the data. It protects against a stolen or decommissioned drive. It does not protect against the software that uses the key anyway.

End to end moves one single thing: the place where encryption happens. Not on the server, but on the device of the person typing — and it is decrypted again only on the device of the person allowed to read it. In between, the content is nowhere in plain text.

Where the encrypting happens — and who holds the key

Browsers can do this out of the box. The Web Cryptography API has been a W3C Recommendation since 26 January 2017; it describes a JavaScript interface for basic cryptographic operations — hashing, signatures, encryption and decryption — along with managing the key material they need. The encryption itself usually uses AES, specified in the US standard FIPS 197 in the variants AES-128, AES-192 and AES-256, where the number gives the length of the key.

In a common design there are two matching keys. One is public and sits in the form; the responding person’s browser uses it to encrypt what they typed. The other is private, stays with the recipient, and is the only one that makes the result readable again.

That shifts the question of trust. Whether a provider reads along stops being a promise and becomes a matter of construction: it does not have the private key, because it never received it. That is a difference — but not a guarantee. Whoever holds the key reads; whoever loses it no longer reads; and the software that does the encrypting in the browser still comes from the provider. Which is why providers who build this way normally document how they do it.

One thing end-to-end encryption explicitly does not do: it protects the content, not the circumstances. That a form was submitted, when, how often, and how large an attachment was — all of that still accumulates. Anyone who thinks those details are irrelevant should write them down once: on an internal reporting form, the timestamp alone says something.

One registration form, step by step

A music school in Thun takes registrations: the child’s name, address, instrument, details for a possible reduced rate. Here is the path when it is encrypted end to end.

1. The school creates the form. A key pair comes into being. The public half belongs to the form, the private half belongs to the school.
2. A father opens the link. His browser loads the form together with the public key.
3. He fills it in and submits. Before sending, his browser encrypts the answers. What leaves the line is no longer readable text.
4. The server receives the result and stores it. It can file it, count it, stamp it with a date — it does not see the content.
5. The school secretary opens the overview. Her browser fetches the stored entries and decrypts them locally with the private key.
6. The registration appears on her screen. Since step 3 it was readable nowhere else.

For the father, nothing about using the form changes. For the secretary, a good deal changes — and that is the actual subject.

What you give up for it

A lost key stays lost. In a system like this the password is not the same thing as the key, and resetting the password does not restore access to the data. Proton describes this openly for its own accounts: after a password reset you need a recovery option that was set up beforehand — a recovery phrase, a recovery file, a device backup or the old password — otherwise you risk permanently losing access to the account and its data. The provider cannot take that off your hands; that is precisely what the design is.

The server cannot search, sort or preview. Everything that otherwise runs over the content server-side either disappears or moves into the browser. Google describes this explicitly for its own client-side encryption in Workspace: the content of such files cannot be searched, cannot be filtered by file type and cannot be shown in the preview; data loss prevention scans have no access to the content; and client-side encrypted files and emails are not scanned for phishing and malware, because the servers do not see the content. That is not a quirk of one provider but the logical consequence of the design.

The notification email carries no content. “New registration received” — that is as much as it can say, because it is sent by a server that cannot read the answer. Anyone used to skimming the content straight from their inbox works differently.

Analysis happens in the browser. Statistics across 4000 answers are not computed on the server but on your own device after decryption. With a handful of registrations you notice nothing. With very many entries you do.

Access for several people is a task of its own. If three people in the office are to read answers, all three need to get at the key. That is solvable, but it is one step more than creating an account — and when someone leaves, it is one step more again.

When it is the wrong effort

Not every form gains from this. A public survey about a staff canteen’s lunch menu, anonymous and without personal data, pays the price without getting anything for it. An order form whose details are meant to flow automatically into the accounts or to a shipping service needs software somewhere that can read the content — at which point the chain is broken anyway. And wherever answers have to be reachable in an emergency even when the one person with the key is unavailable, key management is the real work, not encryption.

The calculation changes the other way round as soon as the answers contain things that concern nobody outside: medical histories, job applications, internal reports, tax documents.

What Swiss law says about it

The Data Protection Act prescribes no technology. It requires controllers and processors to ensure data security appropriate to the risk through suitable technical and organisational measures, and leaves the minimum requirements to the Federal Council (Art. 8 FADP). The Data Protection Ordinance then names goals rather than tools: according to their protection needs, the data processed should be accessible only to authorised persons (confidentiality), available when needed (availability), not altered without authorisation (integrity) and processed traceably (traceability) (Art. 2 DPO). In choosing measures, the state of the art and the cost of implementation are among the factors to be taken into account (Art. 1 para. 4 DPO).

The word “encryption” does not appear in those provisions. What is telling is that confidentiality and availability stand side by side — and that the ordinance also requires that access to the data can be restored quickly after an incident (Art. 3 para. 2 let. d DPO). The decision this article is about sits exactly between those two goals.

What it comes down to

“Encrypted” is not a property but a question about two things: at which point does the encrypting happen, and who holds the key? Both are either in a provider’s documentation or nowhere. End to end is the answer with the smallest readership — and with the most day-to-day restrictions. The two belong together; telling only the first half tells half the story.

We are building Forms, an app in which the answers are encrypted in the responding person’s browser and the private key stays with the receiving side. The app is planned and not yet available; how the encryption is built in detail, and what it means in daily use, we will set out before launch.