Sticky opt-in mechanism can be misused as super cookie

[johnwilander]

From the explainer:

A user agent's initial request to https://example.com will include the following request headers:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/71.0.0.0 Safari/537.36
Sec-CH-UA: "Chrome"; v="74", ";Not)Your=Browser"; v="13"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: “Windows”

If a server delivers the following response header:

Accept-CH: Sec-CH-UA-Full-Version, Sec-CH-UA-Arch

Then subsequent requests to https://example.com will include the following request headers:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/71.0.0.0 Safari/537.36
Sec-CH-UA: "Chrome"; v="74", ";Not)Your=Browser"; v="13"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"
Sec-CH-UA-Full-Version: "74.0.3424.124"
Sec-CH-UA-Arch: "arm"

The proposal lists three response headers as the default and seven response headers in total. That looks like four-bit persistent storage. For how long will "subsequent requests" adhere to the opt-in headers the server has sent? Is it per-page, per tab, ephemeral per browsing session, or persistent?

Is the opt-in state partitioned per top site? If not, eight auxiliary domains can form a 4*8=32-bit identifier.

I searched the explainer for some keywords like "sticky," "persistent," "scope," "partition," and "session," but couldn't find this issue addressed. I also did some casual searches for existing issues but didn't find any.

[ronancremin]

Note that there was an Accept-CH-Lifetime header at one point in the CH spec that let origins to specify the persistence of hints but this was dropped in mid 2019.

[amtunlimited]

This is an issue with the HTTP Client Hints more than this definition of particular hints; this is defined in RFC 8942.

For how long will "subsequent requests" adhere to the opt-in headers the server has sent? Is it per-page, per tab, ephemeral per browsing session, or persistent?

The relevant section of the spec:

[the opt in] SHOULD be persisted and bound to the origin to enable delivery of Client Hints on subsequent requests to the server's origin, for the duration of the user's session (as defined by the user agent).

Emphasis my own. The current implementation in chrome clears the preferences on browser restart and if origin-specific information is cleared (e.g. cookies, storage, cache).

[miketaylr]

https://wicg.github.io/client-hints-infrastructure/#accept-ch-cache-definition also states:

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.

@johnwilander wrote:

I searched the explainer for some keywords like "sticky," "persistent," "scope," "partition," and "session," but couldn't find this issue addressed. I also did some casual searches for existing issues but didn't find any.

Thanks for the feedback - we could do a better job of connecting the dots between RFC8942 and Client Hints Infra in the UA-CH spec (and linking to those from the explainer).

[johnwilander]

This is an issue with the HTTP Client Hints more than this definition of particular hints; this is defined in RFC 8942.

For how long will "subsequent requests" adhere to the opt-in headers the server has sent? Is it per-page, per tab, ephemeral per browsing session, or persistent?

The relevant section of the spec:

[the opt in] SHOULD be persisted and bound to the origin to enable delivery of Client Hints on subsequent requests to the server's origin, for the duration of the user's session (as defined by the user agent).

Emphasis my own. The current implementation in chrome clears the preferences on browser restart and if origin-specific information is cleared (e.g. cookies, storage, cache).

That sounds to me like a per-session super cookie since there is no partitioning. Would you agree? If so, any site the user has a logged in first-party relationship with can set the same super cookie for every browsing session and persistently track the user across websites.

[miketaylr]

The Accept-CH cache only applies to top-level navigations, so it's effectively partitioned by top-level origin anyway. But we could require partitioning to be consistent with the rest of the platform that's moving in that direction. I'll file a bug on the right repo.

[miketaylr]

Let's close here and continue the conversation in WICG/client-hints-infrastructure#75