index.bs

<pre class='metadata'>
Title: Client Hints Infrastructure
Shortname: ClientHintsInfra
Level: 1
Status: CG-Draft
Group: WICG
URL: https://wicg.github.io/client-hints-infrastructure
Editor: Yoav Weiss, Google, yoav@yoav.ws, https://blog.yoav.ws
Abstract: Specification of the Client Hints infrastructure and its integration with Fetch and HTML
Markup Shorthands: markdown yes
Repository: WICG/client-hints-infrastructure
</pre>

<pre class="link-defaults">
spec:html; type:element; text:link
spec:html; type:element; text:script
spec:fetch; type:dfn; for:/; text:fetch
spec:fetch; type:dfn; for:Request; text:request
spec:fetch; type:dfn; text:client
spec:ServiceWorker; type:dfn; for:/; text:
spec:url; type:dfn; for:url; text:origin
spec:html; type:element; text:style
spec:infra; type:dfn; text:user agent
spec:html; type:dfn; text:navigable
</pre>

<pre class="anchors">
spec: HTML; urlPrefix: https://html.spec.whatwg.org/multipage/
    urlPrefix: browsing-the-web.html
        type: dfn;text: populating a session history entry; url: populating-a-session-history-entry
    urlPrefix: semantics.html
        type: dfn; text: standard metadata names; url: standard-metadata-names
spec: STRUCTURED-FIELDS; urlPrefix: https://www.rfc-editor.org/rfc/rfc8941.html#name-
    type: dfn
        text: sf-lists; url: lists
spec: clear-site-data; urlPrefix: https://w3c.github.io/webappsec-clear-site-data/#
    type: dfn
        text: Clear-Site-Data Header; url: header
</pre>

<pre class=biblio>
{
    "PERMISSIONS-POLICY": {
        "authors": [
            "Ian Clelland"
        ],
        "href": "https://w3c.github.io/webappsec-permissions-policy/",
        "publisher": "W3C",
        "title": "Permissions Policy"
    },
    "CLIENT-HINT-RELIABILITY": {
        "authors": [
            "David Benjamin"
        ],
        "href": "https://datatracker.ietf.org/doc/html/draft-davidben-http-client-hint-reliability",
        "publisher": "W3C",
        "title": "Client Hint Reliability"
    }
}
</pre>

<style>
table, th, td { border: 1px black solid; }
thead {background-color: yellow; }
</style>

Introduction {#intro}
=====================

Client Hints is collection of HTTP and user-agent features that enables
privacy-preserving, proactive content negotiation with an explicit third-party
delegation mechanism:

* Proactive content negotiation at the HTTP layer enables servers to request
    delivery of specific hints, in order to enable optimized and automated
    selection of resources based on a user's device, conditions and preferences,
    and lets clients decide which hint requests they want to grant, with
    per-hint and per-origin granularity.
* Integration of said mechanism with web concepts, defined in this document,
    enables browsers to benefit from content adaptation, and have it play nicely with
    current web restrictions (e.g. same-origin policy).
* The opt-in nature of the mechanism enables browsers to advertise requested
    hint data (e.g. user agent and device characteristics) selectively to
    secure-transport origins, instead of appending such data on every outgoing
    request.
* Origin opt-in applies to same-origin assets only and delivery to third-party
    origins is subject to explicit first party delegation via Permissions Policy,
    enabling tight control over which third party origins can access requested
    hint data.

The goal of Client Hints is to **reduce passive fingerprinting** on the web
while **enabling scalable and privacy preserving content adaptation** between
client and server, via a standardized set of content negotiation primitives at
the HTTP and user agent levels.

Infrastructure definition {#definition}
=========================

The specification of the Client Hints **infrastructure** is divided between the
following specifications and proposals:

* IETF [[!RFC8942]]
     - Provides the motivation for Client Hints.
     - Defines the `Accept-CH` response header, which servers may use to advertise
         support for certain Client Hints.
     - Provides both general guidelines, and formal requirements, about Client
         Hints’ impact on caching, security, and privacy.
     - Does *not* define any actual, particular hints – or say anything about how
         Client Hints works in web contexts.
* Client Hints infrastructure - this document
     - Defines how web clients should process the `Accept-CH` headers sent by servers.
     - Defines the environment settings object state related to `Accept-CH`,
         which stores information about which servers should get which hints.
     - Defines how, and when, web clients should actually go about sending hints,
         based on the state of their environment settings object.
        - More specifically, it integrates the HTML web concepts with Fetch's
            algorithms to make sure that opted-in hints are added to requests for
            same-origin or delegated-to cross-origin requests. It also makes sure
            hints are removed from not delegated-to cross-origin requests after
            redirections.
     - Defines the `Critical-CH` response header, which servers may use to request a restart
         to include critical Client Hints missing in the initial load.
     - Integrates those concepts with the [[!HTML]] and [[!FETCH]] specifications,
         by patching various concepts there.
* [[PERMISSIONS-POLICY|W3C Permissions Policy specification]]
     - In order to perform third party Client Hint delegation, Permissions Policy has
         been extended to control features within fetch requests (rather than just Documents). See [[permissions-policy#algo-should-request-be-allowed-to-use-feature]]
* [[CLIENT-HINT-RELIABILITY|Client Hints Reliability]]
     - See <a href="#interaction-with-accept-ch-frame">Interaction with `ACCEPT_CH` frame</a>.

Environment settings object processing {#environment-settings-object-processing}
==============

<h3 id=concept-client-hints-set>Client hints set</h3>

<p>A <dfn>client hints set</dfn> is a
<a for=/>set</a> of [=client hints token=]s.

`Accept-CH` cache {#accept-ch-cache-definition}
----------------

An <dfn export>Accept-CH cache</dfn> is owned by the user agent and is an [=ordered map=],
[=keyed=] on <dfn for="accept-ch-cache">origin</dfn> (an [=url/origin=]),
with a value of <dfn for="accept-ch-cache">client hints set</dfn> (a [=/client hints set=]).

The Accept-CH cache can effectively act as an alternative cookie store,
since sites can use each of the hints as a bit set on the client, and that information will be
communicated to them on every request. As such, a user agent MUST evict that
cache whenever the user clears their cookies or when session cookies expire.
A user agent also MUST clear the Accept-CH according to the rules of the
[=Clear-Site-Data Header=].

A site can clear the browser's `Accept-CH` cache for its origin by sending an empty `Accept-CH` header in a response. This sets the origin's [=/client hints set=] to an empty set.

There MAY be multiple `Accept-CH` headers per-response and <a>sf-lists</a> can be split across lines as long as each line contains at least one token.

Note: As the cache can only be modified by the top-level frame, it is considered to be partitioned.

When asked to <dfn>update the client hints set from cache</dfn> given a |settingsObject|:

<ol>
 <li>Let |hintSet| be an empty [=ordered set=].
 <li>Let |originMatchingEntries| be the entries in the [=Accept-CH cache=] whose [=accept-ch-cache/origin=] is [=same origin=] with |settingsObject|'s [=environment settings object/origin=].
 <li>For each |entry| in |originMatchingEntries|, for each |token| in |entry|'s [=accept-ch-cache/client hints set=], [=set/append=] the |token| to |hintSet|.
 <li>Let |frameHintSet| be the [=ordered set=] of hints requested by the `ACCEPT_CH` Frame (if any).
 <li>For each |hint| in |frameHintSet| [=set/append=] the |hint| to |hintSet|.
 <li>For each |hint| in |hintSet|, [=set/append=] |hint| to |settingsObject|'s [=environment settings object/client hints set=].
</ol>

When asked to <dfn abstract-op>create or override the cached client hints set</dfn> given a |settingsObject| and |response|:

<ol>
 <li>If |settingsObject| is a [=non-secure context=], abort these steps.
 <li>Let |browsingContext| be |settingsObject|'s [=environment settings object/global object=]'s [=Window/browsing context=].
 <li>If the [=top-level browsing context=] does not equal |browsingContext|, abort these steps.
 <li>If |response|'s `Accept-CH` header is not present, abort these steps.
 <li>Let |hintSet| be an empty [=ordered set=].
 <li>For each |hint| in the result of parsing `Accept-CH` according to the header parsing rules, as a [=field-name=]:
 <ol>
  <li>If |hint| is a [=client hints token=] add it to |hintSet|.
 </ol>
 <li>Let |origin| be |response|'s [=url/origin=].
 <li>[=map/Set=] [=Accept-CH cache=][|origin|] to |hintSet|.
</ol>

`Critical-CH` {#critical-ch-algo}
--------

If an [=url/origin=] is loaded and the server sets an `Accept-CH` header that
lists hints not already in the current [=Accept-CH cache=] that means only
subsiquent loads of that [=url/origin=] will include the hints. If it's
critical that every load (including the first) has the requested Client Hints,
then the server can set a `Critical-CH` header to request a restart. The
`Critical-CH` header itself does not modify the [=Accept-CH cache=].

A restart will only occur when a hint in the `Accept-CH` header is both *not in*
the [=Accept-CH cache=] and *in* the `Critical-CH` header. If hints listed in
the `Critical-CH` header are already in the [=Accept-CH cache=] no restart is
needed as they were sent. If hints listed in the `Critical-CH` header are not
in the `Accept-CH` header a restart would not result in the hints being included
anyway.

The restart retries the entire navigation (including any prior redirects).

There MAY be multiple `Critical-CH` headers per-response and <a>sf-lists</a> can be split across lines as long as each line contains at least one token.

When asked if the user agent <dfn abstract-op>should restart loading the page for critical client hints</dfn> given a |settingsObject| and |response|:

<ol>
 <li>If |settingsObject| is a [=non-secure context=], abort these steps.
 <li>Let |browsingContext| be |settingsObject|'s [=environment settings object/global object=]'s [=Window/browsing context=].
 <li>If the [=top-level browsing context=] does not equal |browsingContext|, abort these steps.
 <li>If |response|'s `Accept-CH` header is not present, abort these steps.
 <li>If |response|'s `Critical-CH` header is not present, abort these steps.
 <li>Let |missingHintSet| be an empty [=ordered set=].
 <li>For each |hint| in the result of parsing `Accept-CH` according to the header parsing rules, as a [=field-name=]:
 <ol>
  <li>If |hint| is a [=client hints token=] add it to |missingHintSet|.
 </ol>
 <li>Let |origin| be |response|'s [=url/origin=].
 <li>For each |hint| in [=Accept-CH cache=][|origin|]:
 <ol>
  <li>Remove |hint| from |missingHintSet| if present.
 </ol>
 <li>For each |hint| in the result of parsing `Critical-CH` according to the header parsing rules, as a [=field-name=]:
 <ol>
  <li>If |hint| is in |missingHintSet| return `true`.
 </ol>
 <li>Return `false`.
</ol>

<dfn>`Delegate-CH`</dfn> {#delegate-ch-algo}
--------

There MAY be multiple `Delegate-CH` tags per-document and this algorithm is run once for each in the order of the appearance of the tags.

Note: This metadata *appends* [=client hints token=]s to the [=environment settings object=]'s [=environment settings object/client hints set=]. It *does not* add those hints to the [=Accept-CH cache=].

<ol>
 <li>Let |metaElement| be the <{meta}> element.
 <li>If any <{link}>, <{style}>, or <{script}> elements have begun to execute, then return.
 <li>If |metaElement| has no <{meta/http-equiv}> attribute, or if that attribute's value is not `delegate-ch`, then return.
 <li>If |metaElement| has no <{meta/content}> attribute, or if that attribute's value is the empty string, then return.
 <li>Let |settingsObject| be |metaElement|'s [=relevant settings object=].
 <li>If |settingsObject| is a [=non-secure context=], abort these steps.
 <li>Let |browsingContext| be |settingsObject|'s  [=environment settings object/global object=]'s [=Window/browsing context=].
 <li>If the [=top-level browsing context=] does not equal |browsingContext|, abort these steps.
 <li>Let |permissionsPolicy| be |metaElement|'s node document's [=Document/permissions policy=].
 <li>Let |delegateCHValue| be the value of |metaElement|'s <{meta/content}> attribute.
 <li>Let |policyDirective| be the result of running [[permissions-policy#algo-parse-policy-directive]] on |delegateCHValue| and the [=url/origin=] of the |metaElement|'s node document.
 <li>For each |feature|->|allowList| of |policyDirective|:
 <ol>
  <li>If |feature| is not a [=client hints token=], then continue.
  <li>If |permissionsPolicy|[|feature|]'s [[PERMISSIONS-POLICY|permissions policy]] is `*`, then continue.
  <li>Let |filteredAllowList| be an empty [=ordered set=].
  <li>For each |item| in |allowList|:
  <ol>
    <li>If |item| is [=url/origin=] then [=set/Append=] |item| to |filteredAllowList|.
  </ol>
  <li>[=set/Append=] |feature| to |settingsObject|'s [=environment settings object/client hints set=] and [=set/Append=] |filteredAllowList| to |permissionsPolicy|[|feature|]'s [[PERMISSIONS-POLICY|permissions policy]].
 </ol>
</ol>

Issue(110): Clarify detection of <{link}>, <{style}>, or <{script}> element execution.

Interaction with `ACCEPT_CH` frame {#interaction-with-accept-ch-frame}
--------

The `ACCEPT_CH` frame is a way for Client Hints to be requested by a server
during the TLS handshake of HTTP/2 and HTTP/3. The requested hints are *not*
persisted in the [=Accept-CH cache=], but will be retrieved and merged when
[=update the client hints set from cache=] is run. The full processing model
is defined in [[CLIENT-HINT-RELIABILITY|Client Hints Reliability]]</a>.

There MUST be only one `ACCEPT_CH` frames per-connection. Additional frames will be ignored.

Integration with HTML {#html}
===========

This specification integrates with the [[!HTML]] specification by patching the algorithms below:

Navigable {#navigable}
----------

Add a new field to [=navigable=]:
<ul>
 <li>A <dfn>`Critical-CH` restart time</dfn> {{DOMHighResTimeStamp}}, initially 0.
 This records the time the navigation was restarted to ensure required Client Hint
 headers will be sent.
</ul>

Navigation response {#navigation-response}
----------

At [=populating a session history entry=], in step 6 after substep 7 insert the following:
<ol>
 <li>Let |shouldRestartForCriticalClientHints| be `false`.
 <li>If <var>navigable</var>'s [=Critical-CH restart time=] is 0:
 <ol>
   <li>Let |shouldRestartForCriticalClientHints| be the result of running [$should restart page for critical client hints$] with the [=relevant settings object=] and |response|.
 </ol>
 <li>Run [$create or override the cached client hints set$] with the [=relevant settings object=] and |response| as inputs.
 <li>If |shouldRestartForCriticalClientHints| then:
 <ol>
   <li>Set <var>navigable</var>'s [=Critical-CH restart time=] to the [=current high resolution time=].
   <li>Restart the initial navigation (before any redirects).
 </ol>
 <li>If <var>navigable</var>'s [=Critical-CH restart time=] is not 0:
 <ol>
    <li>Set <var>navigationParams</var>'s [=Critical-CH restart time=] to be <var>navigable</var>'s [=Critical-CH restart time=].
 </ol>
</ol>

Issue(154): Clarify how "Restart the initial navigation (before any redirects)" integrates with the HTML spec.

At [=navigation params=], append the following:
<dl>
<dt>`Critical-CH` restart time</dt>
  <dd>a {{DOMHighResTimeStamp}} used for [=creating the navigation timing entry=] for the new <code>Document</code>.
  This records the time the navigation was restarted to ensure required Client Hint headers will be sent.</dd>
</dl>


Service Worker initialization {#service-worker-init}
-----------
At <a spec=HTML>set up a worker environment settings object</a>,
after step 6, add the following step:
<ol>
 <li>If <var ignore>worker global scope</var> implements {{ServiceWorkerGlobalScope}}, then set <var ignore="">settings object</var>'s [=environment settings object/client hints set=] to be a [=set/clone=] of <var ignore>outside settings</var>' [=environment settings object/client hints set=].
</ol>

Standard metadata names {#standard-metadata-names}
------------
For the section [=standard metadata names=],
add a subsection named `delegate-ch` with the [=Delegate-CH|outlined explanation=].

Extending environment settings object {#extending-environment-settings-object}
-------------

An [=environment settings object=] has a <dfn for="environment settings object">client hints set</dfn>: a [=/client hints set=], initially the empty set, used for [=fetches=] performed using the [=environment settings object=] as a [=request=] [=client=].


Request processing {#request-processing}
===========

When asked to <dfn export abstract-op>append client hints to request</dfn> with |settingsObject| and |request| as input, run the
following steps:

<ol>
 <li>If |request| is a [=non-subresource request=] for a "sharedworker" or "worker" [=request/destination=], exit without appending any hints to the [=request/header list=].
 <li>Let |hintSet| be an empty [=/client hints set=].
 <li>Run [=update the client hints set from cache=] with |settingsObject|.
 <li>For each [=client hints token=] |lowEntropyHint| in the registry's [=low entropy hint table=], [=set/append=] |lowEntropyHint| to |hintSet|.
 <li>If |request|'s [=request/client=] is not null, then for each [=client hints token=] |requestHint| in
|settingsObject|'s [=environment settings object/client hints set=], [=set/append=] |requestHint| to
|hintSet|.
 <li>For each |hintName| in |hintSet|:
 <ol>
   <li>If |request| is not a [=navigation request=] for a "document" [=request/destination=]:
   <ol>
     <li>Let |requestPermitsHint| be the result of running [[permissions-policy#algo-should-request-be-allowed-to-use-feature]] given |request| and |hintName|'s associated feature in [[#policy-controlled-features]].
     <li>If |requestPermitsHint| is `false`, then continue to next |hintName|.
   </ol>
   <li>If the user agent decides, in an [=implementation-defined=] way (see [[#privacy]]), to omit this hint then continue.
   <li>Let |value| be the result of running [=find client hint value=] with |hintName|.
   <li>If the user agent decides, in an [=implementation-defined=] way (see [[#privacy]]), to modify |value| then do so.
   <li>[=header list/append=] |hintName|/|value| to the [=request/header list=].
 </ol>
</ol>

When asked to <dfn abstract-op>remove client hints from redirect if needed</dfn> with |request| as input, run the following steps:

<ol>
 <li><p><a for=list>For each</a> <var>hintToken</var> in the list of [=client hints token=]s:
 <ol>
  <li><p>If <var>request</var>'s <a for=request>header list</a> <a for="header list">contains</a>
  <var>hintToken</var>, then remove <var>hintToken</var> from |request|'s [=request/header list=].
 </ol>
</ol>

Integration with Fetch {#fetch}
==============

This specification integrates with the [[!FETCH]] specification by patching the algorithms below:

In <a spec=FETCH>HTTP-network-or-cache fetch</a>, within step 8, after substep 23, run [$append client hints to request$] with the [=relevant settings object=] and |request| as input.

In [=HTTP-redirect fetch=], after step 11, run [$remove client hints from redirect if needed$] with |request| as input.

In [=forbidden request-header=], to the list of headers within step 1, add `Save-Data`, `DPR`, `Device-Memory`, `Width`, and `Viewport-Width`.

Feature Registry {#registry}
==========

Note: This section contains feature-specific definitions.
New features that rely on the Client Hints infrastructure need to add their respective definitions to this registry.
User Agents can implement some of those features without implementing others.

Client hints token {#client-hints-token-definition}
----------

A <dfn export>client hints token</dfn> is a [=byte-lowercase=] representation of one of
`Save-Data`,
`Sec-CH-DPR`,
`Sec-CH-Width`,
`Sec-CH-Viewport-Width`,
`Sec-CH-Viewport-Height`,
`Sec-CH-Device-Memory`,
`Sec-CH-RTT`,
`Sec-CH-Downlink`,
`Sec-CH-ECT`,
`Sec-CH-Prefers-Color-Scheme`,
`Sec-CH-Prefers-Reduced-Motion`,
`Sec-CH-UA`,
`Sec-CH-UA-Arch`,
`Sec-CH-UA-Bitness`,
`Sec-CH-UA-Full-Version`,
`Sec-CH-UA-Full-Version-List`,
`Sec-CH-UA-Mobile`,
`Sec-CH-UA-Model`,
`Sec-CH-UA-Platform`,
`Sec-CH-UA-Platform-Version`, or
`Sec-CH-UA-WoW64`.

Note: A client hints token will also match the request header sent by the user agent when
appropriate (as determined by the <a href="#request-processing">request processing algorithm</a>).

Policy-controlled features {#policy-controlled-features}
-------------

This document defines <dfn export>policy-controlled client hints features</dfn>,
the following [=policy-controlled features=]:

- <code><dfn export>ch-save-data</dfn></code> which has a [=default allowlist=] of `'*'`
- <code><dfn export>ch-dpr</dfn></code> which has a [=default allowlist=] of `'self'`
- <code><dfn export>ch-width</dfn></code> which has a [=default allowlist=] of `'self'`
- <code><dfn export>ch-viewport-width</dfn></code> which has a [=default allowlist=] of `'self'`
- <code><dfn export>ch-viewport-height</dfn></code> which has a [=default allowlist=] of `'self'`
- <code><dfn export>ch-device-memory</dfn></code> which has a [=default allowlist=] of `'self'`
- <code><dfn export>ch-rtt</dfn></code> which has a [=default allowlist=] of `'self'`
- <code><dfn export>ch-downlink</dfn></code> which has a [=default allowlist=] of `'self'`
- <code><dfn export>ch-ect</dfn></code> which has a [=default allowlist=] of `'self'`
- <code><dfn export>ch-prefers-color-scheme</dfn></code> which has a [=default allowlist=] of `'self'`
- <code><dfn export>ch-prefers-reduced-motion</dfn></code> which has a [=default allowlist=] of `'self'`
- <code><dfn export>ch-ua</dfn></code> which has a [=default allowlist=] of `'*'`
- <code><dfn export>ch-ua-arch</dfn></code> which has a [=default allowlist=] of `'self'`
- <code><dfn export>ch-ua-bitness</dfn></code> which has a [=default allowlist=] of `'self'`
- <code><dfn export>ch-ua-form-factors</dfn></code> which has a [=default allowlist=] of `'self'`
- <code><dfn export>ch-ua-full-version</dfn></code> which has a [=default allowlist=] of `'self'`
- <code><dfn export>ch-ua-full-version-list</dfn></code> which has a [=default allowlist=] of `'self'`
- <code><dfn export>ch-ua-mobile</dfn></code> which has a [=default allowlist=] of `'*'`
- <code><dfn export>ch-ua-model</dfn></code> which has a [=default allowlist=] of `'self'`
- <code><dfn export>ch-ua-platform</dfn></code> which has a [=default allowlist=] of `'*'`
- <code><dfn export>ch-ua-platform-version</dfn></code> which has a [=default allowlist=] of `'self'`
- <code><dfn export>ch-ua-wow64</dfn></code> which has a [=default allowlist=] of `'self'`

Issue: Should we tie low-entropy-ness to allowlists, generally?

Low-entropy hint table {#low-entropy-table}
-------
The <dfn export lt="low-entropy hint table|low entropy hint table">low-entropy hint table</dfn>
below defines hints that are safe to send by default due to their low amounts of entropy.

A <dfn export>high-entropy client hint</dfn> is a client hint that is not in the
<a>low-entropy hint table</a>.

<table>
 <thead>
 <tr>
  <th><a for=header>Name</a>
  <th><a for=header>Value</a>
 <tbody>
 <tr>
  <td>`Save-Data`
  <td>a suitable <a href="https://wicg.github.io/savedata/#save-data-request-header-field">Save-Data value</a>
 <tr>
  <td>`Sec-CH-UA`
  <td>a suitable <a href="https://wicg.github.io/ua-client-hints/#sec-ch-ua">UA value</a>
 <tr>
  <td>`Sec-CH-UA-Mobile`
  <td>a suitable <a href="https://wicg.github.io/ua-client-hints/#sec-ch-ua-mobile">Mobile value</a>
 <tr>
  <td>`Sec-CH-UA-Platform`
  <td>a suitable <a href="https://wicg.github.io/ua-client-hints/#sec-ch-ua-platform">Platform value</a>
</table>

Note: If the value transmitted by `Save-Data` is the empty string, the header will be omitted entirely.
This is done to reduce redundant header information sent by default.

Find client hint value {#find-client-hint-value-section}
------------

When asked to <dfn>find client hint value</dfn>, given |hint| as input, switch on |hint| and return the result:
 <dl class=switch>
  <dt>`Save-Data`
  <dd>a suitable <a href="https://wicg.github.io/savedata/#save-data-request-header-field">Save-Data value</a>
  <dt>`DPR`
  <dd>a suitable <a href>DPR value</a>
  <dt>`Viewport-Width`
  <dd>a suitable <a href>Viewport-Width value</a>
  <dt>`Viewport-Height`
  <dd>a suitable <a href>Viewport-Height value</a>
  <dt>`Width`
  <dd>a suitable <a href>Width value</a>
  <dt>`Device-Memory`
  <dd>a suitable <a href="https://w3c.github.io/device-memory/#sec-device-memory-client-hint-header">Device-Memory value</a>
  <dt>`RTT`
  <dd>a suitable <a href="https://wicg.github.io/netinfo/#rtt-request-header-field">RTT value</a>
  <dt>`Downlink`
  <dd>a suitable <a href="https://wicg.github.io/netinfo/#downlink-request-header-field">Downlink value</a>
  <dt>`ECT`
  <dd>a suitable <a href="https://wicg.github.io/netinfo/#ect-request-header-field">ECT value</a>
  <dt>`Prefers-Color-Scheme`
  <dd>a suitable <a href="https://wicg.github.io/user-preference-media-features-headers/#sec-ch-prefers-color-scheme">color theme value</a>
  <dt>`Prefers-Reduced-Motion`
  <dd>a suitable <a href="https://wicg.github.io/user-preference-media-features-headers/#sec-ch-prefers-reduced-motion">Reduced-Motion value</a>
  <dt>`UA`
  <dd>a suitable <a href="https://wicg.github.io/ua-client-hints/#sec-ch-ua">UA value</a>
  <dt>`UA-Arch`
  <dd>a suitable <a href="https://wicg.github.io/ua-client-hints/#sec-ch-ua-arch">Arch value</a>
  <dt>`UA-Bitness`
  <dd>a suitable <a href="https://wicg.github.io/ua-client-hints/#sec-ch-ua-bitness">Bitness value</a>
  <dt>`UA-Full-Version`
  <dd>a suitable <a href="https://wicg.github.io/ua-client-hints/#sec-ch-ua-full-version">Full-Version value</a>
  <dt>`UA-Full-Version-List`
  <dd>a suitable <a href="https://wicg.github.io/ua-client-hints/#sec-ch-ua-full-version-list">Full-Version-List value</a>
  <dt>`UA-Mobile`
  <dd>a suitable <a href="https://wicg.github.io/ua-client-hints/#sec-ch-ua-mobile">Mobile value</a>
  <dt>`UA-Model`
  <dd>a suitable <a href="https://wicg.github.io/ua-client-hints/#sec-ch-ua-model">Model value</a>
  <dt>`UA-Platform`
  <dd>a suitable <a href="https://wicg.github.io/ua-client-hints/#sec-ch-ua-platform">Platform value</a>
  <dt>`UA-Platform-Version`
  <dd>a suitable <a href="https://wicg.github.io/ua-client-hints/#sec-ch-ua-platform-version">Platform-Version value</a>
  <dt>`UA-WoW64`
  <dd>a suitable <a href="https://wicg.github.io/ua-client-hints/#sec-ch-ua-wow64">WoW64 value</a>
 </dl>

Issue: Links for image features are broken, need to actually define that and link to them.

Security and Privacy considerations {#privacy}
===========

This specification exposes information regarding the user's preferences and agent, which can be used as an active fingerprinting vector.
[=User agents=] implementing this specification need to be aware of that, and take that into consideration when deciding whether to implement specific hints,
modify their returned values for a given hint, or omit the hint entirely.

For example, the user might have a site specific setting to override or disable specific client hints to reduce the potential for fingerprinting.

Terms {#terms}
====

The following terms are defined in the HTTP specifications:
<dfn href="https://tools.ietf.org/html/rfc7230#section-3.2">field-name</dfn>