Client Hints

Client Hints is a collection of HTTP operations that are sent from a server to a client to request details that can be used to proactively select the most appropriate resources.

Usage

A server can request one or more of several HTTP request headers that each represent an inquiry to the client about their environment. This includes hardware details about the device or the network and user-specific or client-specific details such as their configuration and preferences.

HTTP fingerprinting and privacy concerns

The Client Hints feature has been the focus of privacy concerns because of what is referred to as passive fingerprinting. This occurs when a server collects enough information about the client during each request to be able to later identify requests as originating from the same source.

Originally, much of the information available by using the Client Hints infrastructure was supplied in the User-Agent header. This included details about the type and version of the operating system the client was running, the type and model of the device, and similar information about the browser. From this, it was possible to infer even more, such as whether it was being run from a mobile device or set up in an embedded system. To combat this potential for abuse, several things have been considered, starting with securing the connection.

One of the measures put in place is that Client Hints requires a secure (HTTPS) connection. This helps to alleviate concerns with third parties that have access to the traffic, although, the larger concern is that servers not be able to identify specific clients using only data gleaned during otherwise anonymous and possibly unrelated requests.

The fact that this is an opt-in mechanism is one of the privacy-protecting aspects of the infrastructure. Clients can choose to send only certain hints or in the alternative, not use them at all. Also, as part of the specification, the responses to some of the hint requests are intentionally coarse, indicating a range rather than a specific value.

The overall goal of Client Hints is to proactively optimize content by adapting as much as practical to each client while mitigating privacy concerns brought upon by passive fingerprinting. This implies that HTTP requests for hints will only be made by a server that will use these details to conserve or optimize bandwidth consumption. That said, there is a distinction between high entropy hints and low entropy hints.

High entropy versus low entropy hints

The User-Agent string is being replaced because of privacy concerns, yet some of the information is less problematic and still useful. This has led to two divisions of HTTP headers referred to as high entropy and low entropy. High entropy headers are not sent by default and instead, require prompting from the server. Low entropy headers are sent by default during each request, even if the server did not ask for them.

Accept-CH

When a server supports the Client Hints functionality, it advertises that by including the HTTP Accept-CH (Accept Client Hints) header in the initial response to the client. Included with the HTTP header is a comma-delimited list of the hints that it is requesting. There are different categories of hints that include specifics about the device, network, and the user’s preferences.

Modern hint headers

It is important to take note that as of this writing, Client Hints is experimental and a work in progress. There have been iterations that included, for example, implementing a Width header that corresponded to the number of physical pixels, and then later deprecating it due to privacy concerns. The currently proposed replacement is Sec-CH-Width, which now represents the number of device pixels and is more resistant to passive HTTP fingerprinting. According to the current version of the specification, Client Hints must have the Sec-CH prefix.

Vary

The Vary header is sent by the server so that caches will understand what decisions the server made during any Content Negotiation. This is required so that the cache can recreate the steps and deliver the appropriate content. Without being able to reproduce the message body, caching the response is not possible.

When a cache receives a message that includes the Vary header, it must ensure that all of the fields specified in the HTTP header match that of the cached request.

The asterisk * is used to inform the cache that additional information, not included in the HTTP header, was used in the process. In this case, caching is not possible.

Vary: Sec-CH-DPR

In this example, the server informs any cache that the Sec-CH-DPR was used during the negotiation process. With this information, caches will ensure that the correct data is indeed considered before serving the content.

Device hints

The device hints include the following:

Device-Memory

Device-Memory or Sec-CH-Device-Memory: This header indicates approximately how much RAM the device has, in gigabytes. The possible values are 0.25, 0.5, 1, 2, 4, and 8.

DPR

The Device Pixel Ratio (DPR) is the ratio between the physical pixels and the CSS pixels, specified as the number of physical pixels to every CSS pixel. If the server acts on this hint then it will respond with the Content-DPR header.

Content-DPR

Content-DPR is sent by the server to confirm the image’s device to pixel ratio that is in use for HTTP requests that include the DPR header.

Sec-CH-DPR

Sec-CH-DPR is an integer greater than zero that indicates the device pixel ratio. For example, if the default representation of an image is 200x100, and the client has sent a value of 2 then the server will return an image that is 400x200. It will include the appropriate Exif metadata with the image to indicate that the original image is 200x100.

Width

Width refers to the number of physical pixels, which is helpful because the client can request the representation for the best fit with the density-corrected screen.

Sec-CH-Width

Sec-CH-Width is an integer value that is greater than or equal to zero, and it is used to inform the server about the width of the image in device pixels. This used to be specified in CSS pixels but has been updated for improved cache reusability.

Viewport-Width

Viewport-Width corresponds to the number of pixels wide the client’s layout is.

Sec-CH-Viewport-Width

Sec-CH-Viewport-Width is an integer value that is greater than or equal to zero, and informs the server about the width of the client’s viewport. If this header is omitted then it is assumed to be 1000 pixels wide.

Sec-CH-Viewport-Height

Sec-CH-Viewport-Height is an integer value that is greater than or equal to zero, and it informs the server as to the height of the client’s viewport. If this header is omitted then it is assumed to be 1000 pixels in height.

Network hints

The network hints include the following:

Sec-CH-Save-Data

Sec-CH-Save-Data indicates the client’s preference for a reduced data usage mode. It is less of a hint and more of a request because it simply informs the server that the client wants minimal data sent.

Sec-CH-RTT

Sec-CH-RTT is the approximate length of a Round Trip Time, measured in milliseconds. This includes any time that the server spends processing the request. It is helpful because it allows clients to make decisions based on network performance, such as latency. This can help to improve the overall user experience because select resources and responses can be included or omitted accordingly.

Sec-CH-Downlink

Sec-CH-Downlink indicates the client’s approximate downstream speed, measured in megabits per second. When considered with RTT, Downlink can be used to help select appropriate content for the client.

Sec-CH-ECT

Sec-CH-ECT or Effective Connection Type describes a connection that is defined by specified ranges of RTT and Downlink values. It does not have information about what the physical connection is but rather, it relies on the network performance information to determine what it most closely matches. The following values were determined through the analysis of real user data:

• Slow-2g: Min RTT 2000ms, Max Downlink 50Kbps. Well suited for small data exchanges such as a text document.

• 2g: Min RTT 1400ms, Max Downlink 70Kbps. This level of network performance is suitable for transferring small image files.

• 3g: Min RTT 270ms, Max Downlink 700Kbps. This type of network can support high-quality audio and video transmission.

• 4g: Min RTT 0ms, No Max Downlink. A network with this performance can handle HD video and real-time streaming.

User hints

User hints enable servers to obtain information about the client's preferences so that they can fine-tune responses for best performance. For example, transmitting only preferred resources can significantly reduce the bandwidth required to satisfy the client’s request. The valid user hints are as follows:

Sec-CH-Prefers-Color-Scheme

Sec-CH-Prefers-Color-Scheme indicates the client’s preferred color scheme. Valid options are “light” and “dark”.

Sec-CH-Prefers-Reduced-Motion

Sec-CH-Prefers-Reduced-Motion indicates the client’s preference for the level of motion to appear within media on the page. Valid parameters are “no-preference” and “reduce”.

Sec-CH-Prefers-Transparency

Sec-CH-Prefers-Transparency indicates the client’s preference for how much transparency is applied within media. Valid parameters are “no-preference” and “reduce”.

Sec-CH-Prefers-Contrast

Sec-CH-Prefers-Contrast indicates the client’s preference for increased or decreased color contrast for media on the page. Valid parameters are “no-preference”, “less”, “more”, and “custom”.

Sec-CH-Forced-Colors

Sec-CH-Forced-Colors indicates the client’s preference for the forced colors mode. It is intended to make screen text more readable and relies also on the setting for Sec-CH-Prefers-Contrast. The value must be “active” or “none” and it has an effect on several properties including color, fill, stroke, text-decoration-color, text-emphasis-color, border-color, outline-color, column-rule-color, scrollbar-color, -webkit-tap-highlight-color, background-color, caret-color, flood-color, lighting-color, and stop-color.

Sec-CH-Prefers-Reduced-Data

Sec-CH-Prefers-Reduced-Data indicates the client’s preference for the server to transmit minimal data, thus conserving bandwidth.

Sec-CH-UA

Sec-CH-UA contains details about the user agent’s brand and version.

Sec-CH-UA-Full-Version

Sec-CH-UA-Full-Version indicates the user agent’s full version number.

Sec-CH-UA-Platform

Sec-CH-UA-Platform indicates the brand of the user agent’s platform.

Sec-CH-UA-Platform-Version

Sec-CH-UA-Platform-Version indicates the version of the user agent’s platform.

Sec-CH-UA-Mobile

Sec-CH-UA-Mobile indicates whether the user agent is requesting a mobile layout.

Sec-CH-UA-Full-Version

Sec-CH-UA-Full-Version indicates the user agent’s full version number.

Sec-CH-UA-Full-Version-List

Sec-CH-UA-Full-Version-List provides the server with details about the full version for each of the brands listed in the Brands list.

Sec-CH-UA-Arch

Sec-CH-UA-Arch contains information about the architecture’s instruction set.

Sec-CH-UA-Bitness

Sec-CH-UA-Bitness provides details concerning the bitness of the architecture. For example, the size of a datatype in bits or a memory address.

Sec-CH-UA-Model

Sec-CH-UA-Model identifies the user agent’s device model.

Sec-CH-Lang

Sec-CH-Lang indicates the user agent’s preferred language.

Takeaway

Client Hints are a set of HTTP headers that can be used by a client to give the server information about its environment, capabilities, and preferences. There are high entropy and low entropy Client Hints, which are distinguished by the type of information they send. Based on this information, a server can select the best representation and optimize the response. This has the potential to save significant bandwidth. Over time, Client Hints has been updated to mitigate the risk of passive client fingerprinting, which can erode the anonymity that is typically offered through web browsing.

See also

• HTTP Headers