Visual RFC.
ALL RFCs / RFC 8291
Read the RFC ↗
RFC 8291 / WEB PUSH ENCRYPTION

Budget the body and keep the privacy limits

06

Encryption protects message content, while the relay still sees clear headers, sizes, timing and routing relationships. Padding also consumes the message budget.

RFC 8291 · § 7EXAMPLE
4 / 4
04
The relay still observes metadata.

The push service sees communication timing, message lengths, the subscription and the communicating endpoints. The message content stays protected under the scheme’s assumptions; encryption alone is not anonymity or a delivery guarantee.

Budget the body and keep the privacy limitsThe push service sees communication timing, message lengths, the subscription and the communicating endpoints. The message content stays protected under the scheme’s assumptions; encryption alone is not anonymity or a delivery guarantee.The relay still observes metadataPush service observes144 B164 BTiming · lengths · subscription · endpointsProtected content ≠ anonymity

Source for this drawing: RFC 8291 · Read RFC section 7 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Content confidentiality is not metadata anonymity or trusted HTTP headers.

  • A push service is not required to support payload bodies over 4096 bytes. At that supported baseline, subtract 86 header bytes, 16 tag bytes and 1 delimiter byte: at most 3993 plaintext bytes without extra padding. This is not a universal prohibition on larger supported payloads.
  • Each extra zero-padding byte reduces that baseline plaintext budget by one. Padding can obscure length clues, but cannot guarantee anonymity or hide all timing and routing information.
  • The content coding protects no HTTP header fields. The user agent MUST consider them to come from the push service; an application must not treat them as authenticated application-server statements.
  • A receiver depending on the coding’s data-origin authentication MUST reject messages lacking aes128gcm (RFC 8188 § 4.1). Requiring the coding is a processing guard, not proof that all accompanying HTTP headers are authentic.
DETAILS

RFC 8030 § 7.2 prohibits a 413 size rejection for bodies of 4096 bytes or less, but does not guarantee delivery. The displayed arithmetic uses the fixed 86-byte Web Push header and a 16-byte tag. The displayed fixed values are public RFC test data, not keys to reuse for real messages. These illustrations do not send notifications or implement a production encryptor.

Read the RFC section ↗

All chapters in RFC 8291

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗