Visual RFC.
ALL RFCs / RFC 8674
Read the RFC ↗
RFC 8674 / CACHE AND TRUST BOUNDARIES

Limits: identity and visibility

05

The field cannot prove someone’s age or force a site to cooperate. HTTPS protects transport but the receiving site still learns the expressed preference.

DIAGRAMRead RFC section 3 ↗
RFC 8674 · § 3EXAMPLE
3 / 3
Limits: identity and visibilityThree independent limit examples reject unsafe inferences rather than blocking network traffic. A request and response can travel while the server ignores safe, so the content-guarantee inference stops. Presence and absence each leave age unknown. HTTPS then protects the transport to the origin, but the origin still reads the preference, which can contribute to fingerprinting or targeting. No age classifier or anonymity guarantee is defined.The signal cannot establish safety or identityHTTPS clientReceiving originprotected transportOrigin reads: Prefer: safeThe endpoint learns the preferenceCan add fingerprinting or targeting informationHTTPS does not hide fields from their recipient
03
Keep endpoint visibility distinct from transport protection.

HTTPS protects the connection in transit. The receiving origin still reads Prefer: safe, which can add identifying information; privacy-sensitive omission is discussed in chapter 2.

Source for this drawing: RFC 8674 · Read RFC section 3 ↗

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

RFC 9110 HTTP RFC 9111 Caching

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

Terms in this drawing
Best effort
A request that depends on voluntary cooperation and site-specific interpretation.
Fingerprinting
Using observable traits to distinguish a user or client; the hint can add one more trait.
Related RFCs and changes

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

KEY POINT

Treat the hint as a preference, never as proof of safety or identity.

  • A server can ignore the preference, interpret it differently or even respond maliciously. A best-effort signal cannot replace other techniques when actual content guarantees are needed.
  • Presence is not evidence that the user is a child, and absence is not evidence that the user is an adult. No reliable age classification follows in either direction.
  • The receiving origin can use this extra information for fingerprinting or targeting even over HTTPS. The conditional SHOULD NOT guidance in §3 reduces disclosure when the user has expressed a desire to avoid those attacks; it does not promise anonymity.
DETAILS

These are independent limit examples, not an attack script or an age-detection feature. No real personal data is collected. The publication describes the preference and its limitations, not a standards-track content moderation or age-verification system.

Read the RFC section ↗

All chapters in RFC 8674

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 ↗