Web push is the mechanism behind those notifications a site can send even when its tab is closed. The plumbing has three parties: the application server (the site sending the alert), the push service (a relay operated by the browser vendor, such as Mozilla's or Google's endpoint), and the user agent (your browser, which runs a service worker to receive and display the message).
The awkward fact at the center of this is the push service. It has to receive every message and route it to the right browser, which means it sits in the middle of every notification. If notifications were sent in plaintext, that relay would see the contents of every push every site ever sent you: order confirmations, chat previews, two-factor prompts. The standard's job is to make the relay a blind courier.
The Subscription Sets Up the Keys
It starts when you grant a site permission to send notifications. Your browser generates a subscription, and crucially that subscription includes a fresh public key. Under the hood the browser creates an elliptic-curve key pair on the P-256 curve, keeps the private key on your device, and hands the public key to the application server, along with a second random value called the auth secret.
From that point the application server has what it needs to encrypt to you and nobody else: your public key. The matching private key never leaves your browser. The push service that will carry the message is never given any key material that would let it decrypt.
The push service is trusted to deliver bytes to the right device. It is not trusted with the contents. That separation is enforced by cryptography, not policy: the relay simply never holds a key that can open the payload. This is the same shape as a sealed envelope, the carrier handles it but cannot read it.
Encrypting the Payload: RFC 8291
The encryption itself is specified in RFC 8291, "Message Encryption for Web Push," which builds on the more general encrypted-content-encoding scheme in RFC 8188. When the application server wants to send you a notification, it runs through this sequence:
- It generates a brand-new ephemeral P-256 key pair just for this one message.
- It performs an elliptic-curve Diffie-Hellman exchange between its ephemeral private key and your subscription's public key, producing a shared secret only the two of you can compute.
- It mixes that shared secret with your auth secret and both public keys through HKDF to derive a content-encryption key and a nonce.
- It encrypts the notification body with AES-128-GCM, an authenticated cipher, and attaches its ephemeral public key to the message so you can reconstruct the same shared secret.
Your browser receives the ciphertext, reads the sender's ephemeral public key from it, runs the same Diffie-Hellman with your private key, derives the identical content-encryption key, and decrypts. The push service, lacking your private key, can compute none of this. It forwards an opaque blob.
Why a Fresh Key Every Time
The ephemeral key pair generated per message is doing real work. Because every notification uses a new sender key, every message has a unique shared secret and therefore a unique encryption key. One message's key tells an attacker nothing about the next. This gives push notifications a measure of forward secrecy: compromising the key for one notification does not unravel the others.
The auth secret adds a second ingredient that the push service never sees, mixed into the key derivation so that knowing the public keys alone is not enough to derive the content key. It binds the encryption to the specific subscription in a way an outsider cannot reproduce.
| Party | Holds | Can read the notification? |
|---|---|---|
| Application server (the site) | Your public key, auth secret | Yes, it composed it |
| Push service (the relay) | Encrypted blob, routing info | No, no decryption key |
| Your browser | Subscription private key | Yes, it decrypts |
What Web Push Encryption Does Not Hide
This is the part marketing tends to skip, so it is worth being plain about. The payload is protected from the relay. The metadata is not.
The push service still sees that a message was sent to your subscription endpoint, when it arrived, and roughly how large it was. It knows which of its endpoints are active and how often each receives pushes. Over time that is a meaningful metadata trail even with the contents sealed. The endpoint URL is also a long-lived identifier tied to your browser instance, and a site that sends frequent, distinctly sized notifications creates a recognizable pattern. Encryption of the body does not erase the shape of the traffic.
There is also the obvious point that the application server, the site you subscribed to, composed the notification and therefore knows its contents. Web push encryption protects you from the relay in the middle, not from the sender you chose to trust. And once a notification is decrypted and displayed, it lives in your browser and operating system like any other on-screen content.
Web push encryption is genuine end-to-end protection of the message body between the sending site and your browser, with the relay cryptographically locked out of the contents. It does not anonymize you to the relay, and it does not hide that messages are flowing. Knowing exactly which threat a control addresses is the whole game in threat modeling.
The Pattern Worth Taking Away
Web push is a clean example of a recurring design move: when a message must pass through infrastructure you do not control, encrypt it so that the infrastructure carries it without reading it. The relay becomes a delivery mechanism, not a confidant. The same instinct shows up in sealed sender, in onion routing, and in any system that assumes the network is hostile and pushes trust to the endpoints.
That assumption is the one Haven is built on too. We treat the transport as something to protect against, not something to trust. Your messages are encrypted on your device before they touch any server, and the keys that open them live with you. Web push gets to do this for one notification at a time; a messenger has to do it for an entire conversation, with group membership changing underneath. If that interests you, our explainer on the MLS protocol covers how modern group encryption keeps the relay blind even as people come and go.