Why Client Hints Require a Secure Context

Client hints are restricted to secure contexts. The restriction is not incidental hardening; it follows directly from what the hints carry and how they are requested.

The hints carry more than the reduced header

High-entropy hints expose exact versions, platform versions and device details that the legacy header no longer includes. On the wire this is more precise information, not less.

Delivering that over a connection any intermediary can read would move information from a reduced broadcast into an equally exposed one. The reduction would be undone in transit.

Requiring encryption keeps the detail between the client and the origin that asked for it, which is the whole premise of a request-based model.

The request itself must be trustworthy

Hints are requested through a response header. On an unprotected connection, an intermediary can insert or alter that header and cause a browser to send detail no origin asked for.

Authentication of the response is therefore a prerequisite for honouring it. Without it, the mechanism's consent step can be forged by anyone on the path.

This is the stronger of the two arguments. Confidentiality protects the data; integrity protects the decision to send it.

Stored preferences would be poisonable

Because the browser stores the request against the origin, a forged header would have lasting effect rather than affecting one request. The poisoning would persist across sessions.

Persistent state derived from an unauthenticated instruction is a familiar hazard. Restricting the mechanism to secure contexts removes the injection point entirely.

The same reasoning governs other origin-scoped state in browsers, which is why the restriction feels consistent rather than arbitrary.

The legacy header has no such restriction

The old header is sent regardless of transport, because it predates any expectation of encryption and removing it from unprotected requests would break too much.

That asymmetry produces an odd result. On an unprotected connection a site receives the reduced legacy string and no hints, which is less information than the same site gets over a protected one.

Detection quality is therefore a function of transport security. That is an incentive working in the right direction, and it was intended.

Practical consequences for development

Local development over an unprotected connection will not receive hints, which regularly appears as a bug. Browsers generally treat local addresses as secure to avoid it.

Staging environments on plain connections show the same symptom without the exemption. Testing hint-dependent code requires the same transport as production.

Any detection path that must work everywhere needs a fallback for the case where no hints arrive at all. Transport is one of several reasons that case occurs.