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.
- HTTP fingerprinting and privacy concerns
- High entropy versus low entropy hints
- Modern hint headers
- Device hints
- Network hints
- User hints
- See also
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.
Client Hints is an experimental technology that is not supported by all servers.
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.
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.
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.
* 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.
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.
The device hints include the following:
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.
Device-Memory has been deprecated and the proposed replacement is Sec-CH-Device-Memory.
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.
DPR has been deprecated and the proposed replacement is Sec-CH-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.
Content-DPR has been deprecated and in its place, the Exif metadata is included in HTTP responses to 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 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.
Width has been deprecated and the proposed replacement is 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 corresponds to the number of pixels wide the client’s layout is.
Viewport-Width has been deprecated and the proposed replacement 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 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.
The network hints include the following:
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 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.
The value is rounded to the nearest 25 milliseconds to mitigate passive fingerprinting concerns.
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.
This value is rounded to the nearest 25Kbps to mitigate passive fingerprinting concerns.
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 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 indicates the client’s preferred color scheme. Valid options are “light” and “dark”.
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 indicates the client’s preference for how much transparency is applied within media. Valid parameters are “no-preference” and “reduce”.
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 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 indicates the client’s preference for the server to transmit minimal data, thus conserving bandwidth.
Sec-CH-Prefers-Reduced-Data is similar to the Network Hint Save-Data, and these two hints probably have the same value.
Sec-CH-UA contains details about the user agent’s brand and version.
Sec-CH-UA-Full-Version indicates the user agent’s full version number.
Sec-CH-UA-Platform indicates the brand of the user agent’s platform.
Sec-CH-UA-Platform-Version indicates the version of the user agent’s platform.
Sec-CH-UA-Mobile indicates whether the user agent is requesting a mobile layout.
Sec-CH-UA-Full-Version indicates the user agent’s full version number.
Sec-CH-UA-Full-Version is deprecated and Sec-CH-UA-Full-Version-List is expected to be used instead.
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 contains information about the architecture’s instruction set.
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 identifies the user agent’s device model.
Sec-CH-Lang indicates the user agent’s preferred language.
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.