Based on https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/QHI3sio6--Q/v_zWX1O6AAAJ I have a couple of questions about the impact of Accept-CH-Lifetime as currently defined in https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-04#section-2.2.2

The main risk, touched upon in the Security Considerations section, is the fact that providers of cross-origin subresources (e.g. images) loaded from pages with Accept-CH headers will start receiving fingerprinting-prone information about the configuration of a connecting client. Note that it will expose more information than what was available to these parties in the past because subresources such as images cannot use client-side logic to access information sent in Client Hints. A related issue is that based on the sets of headers sent in such subresource requests, the subresource owner might be able to identify the referring site even if it sets a Referrer Policy to prevent disclosing its URL or origin. For example, requests from a large site which sets Referrer-Policy: no-referrer; Accept-CH: DPR will be distinguishable from requests from sites with Accept-CH: DPR, Viewport-Width and from those without client hints. Depending on the chosen set of hints this can in practice uniquely identify the origin visited by the user.

The introduction of Accept-CH-Lifetime will extend this problem to all resources on a given origin -- if one page sets the header, then subresource requests from all pages in that origin will start carrying hint information. This can be undesirable for the user because it can disclose information about the visited origin and broadcasts fingerprintable information to all parties from which the given origin loads subresources.

It seems like this should be mitigated, possibly by one of the following:

• (Preferably) Not broadcasting client hints on cross-origin subresource loads.
• Obeying Referrer Policy and omitting hints if the referring page attempts to restrict data which is sent in the Referer header. Similarly, hints should probably also be stripped on HTTPS -> HTTP transitions.