EMZETT.End-to-End Connection
In short: A direct logical connection between sender and recipient in which intermediate stations (routers etc.) can’t change or read the content.
In more detail: The principle (“end-to-end”) states that tasks such as error correction or encryption should ideally take place at the endpoints of a connection, instead of relying on intermediate network nodes. With end-to-end encryption (e.g. in messengers), not even the transmitting servers can see the content of the messages.
In Depth
Origin of the architectural principle
The “end-to-end principle” is a fundamental architectural principle of the internet, formulated in 1984 in an influential paper by Saltzer, Reed and Clark: intelligence and complex logic belong at the endpoints of a communication; the network in between should forward data as simply, “dumbly” and transparently as possible instead of making decisions about its content itself. The reasoning: only the endpoints really know reliably whether a transmission was actually complete and correct — an intermediate node can in principle never fully take over this guarantee, even if it tries, because it doesn’t know the endpoints’ application logic. This explains, for example, why real error correction in TCP takes place primarily at the end-device level (via ACKs between exactly the two communicating ends) and not at every single router along the way, even though intermediate solutions would technically be conceivable.
End-to-end encryption as the best-known example
With end-to-end encryption (E2EE), the best-known practical example of this principle, a message is already encrypted on the sending device and only decrypted again on the receiving device — all intermediate stations, including the messenger provider’s own servers, only see the encrypted content and technically can’t read it, even if they wanted to or were forced to (e.g. by an official order). This differs fundamentally from pure transport encryption such as HTTPS/TLS, in which the connection is only encrypted between client and server — the server itself sees the data in plain text before it processes it further, stores it or delivers it to other recipients. Popular messengers such as Signal or WhatsApp use established, publicly documented protocols for this (e.g. the Signal protocol), which additionally offer “perfect forward secrecy”: even if a key is compromised later, previously exchanged messages remain protected, because new, independent keys are negotiated for each session.
Technical implementation: key exchange
For E2EE to work at all, the endpoints have to exchange secure cryptographic keys beforehand (or when the connection is established) without an eavesdropper in between being able to read this exchange and thereby undermine the actual encryption — usually via asymmetric methods with public key/private key pairs, where only the public part has to be transmitted at all.
The trade-off: missing intermediate functions
The trade-off of true end-to-end design: since intermediate stations fundamentally don’t know the content, they can’t offer any content-related additional functions either — server-side full-text search within encrypted messages, automatic spam/abuse filtering based on the actual content, or central recovery of lost messages, because the provider itself doesn’t have a plain-text copy at all. This is a deliberate, often controversially discussed trade-off between maximum privacy on the one hand and range of functions or moderation options on the other — a topic that keeps coming up politically, especially in the regulation of messenger services.
See also: Encryption, Tunnel, TLS, Public key