Re: `Accept-CH` header is weird

Hi TAG folks,

I'm concerned to read the TAG's feedback on the Client-Hints draft [0] as suggesting that the feature should only go forward if it's done in a way that adds undetectable passive browser fingerprinting surface, after previous discussions had come up with a design that explicitly created a visible server opt-in for this setting. Apologies if I'm just misunderstanding the TAG issue comments, but this seemed like a significant change away from previous discussion on the public-privacy list [1], in the httpwg [2] and at the recent IETF meeting.

> We remain unconvinced by privacy arguments regarding opt-in-free Client-Hints. Perhaps for environments that aren't the web, this would be a meaningful distinction, but for HTML, the reality of CSS media queries, DOM APIs, and other side-channels for determining this information at runtime ensure that there's no net privacy benefit (aside from requiring that fingerprinting parties do so actively and thus visibly, a situation the can be re-created by removing support for Client-Hints).

You mention that with a visible opt-in fingerprinting parties would do so "actively and thus visibly" as an aside, and I'm not sure why. Making fingerprinting detectable or observable is a key mitigation, not a parenthetical one. Detectability is a mitigation that is often feasible in the design of the Web platform, as it is in this case. Following the TAG's guidance that technical prevention mechanisms are unlikely to be entirely effective, detectability of fingerprinting is essential for using other means, including policy means, to discourage widespread browser fingerprinting, an example of tracking outside of user awareness and control [3].

In addition, encouraging data to be sent by default on every request does not following the principle of data minimization, and makes it more likely that such fingerprinting would become "normal", an outcome that the TAG indicated should be the focus of prevention [3]. Here that data minimization design it seems to align well with the position of implementers not interested in sending data on every request.

> A unique case is reflection of data that's not trivially available otherwise (e.g. Save-Data), but given that this information is available via origin opt-in under Accept-CH.

I might not understand this sentence. Was something left out? Maybe the suggestion is that a privacy benefit would only exist for previously private data that is newly disclosed in these headers, but that the privacy benefit doesn't exist if an origin can opt-in to receiving it? In addition to fingerprinting surface, it is also useful to require sites to ask for the user data they need, in order to improve detection and to allow sites that don't need additional info not to receive it.

I'm reminded that while much fingerprinting surface is currently accessible to parties using HTML, CSS and JavaScript, this additional fingerprinting surface / information about the user's device/window would also be provided in the loading of images (1x1 gifs, for example), a particular intentional use case. So I would say that there certainly is disclosure of data not trivially available otherwise and that the analogy you draw to, for example, CSS media queries may not capture all usage.

> We therefore recommend that UAs revisit the decision to require the  opt-in at their earliest convenience (again, acknowledging that non-web environments or restricted contexts like a "private browsing" mode may choose to set defaults very differently, up to and including disabling Client-Hints entirely).

It's good to recognize that some UAs and some modes of browsing will continue to restrict information even if a spec requires it to be sent with no opt-in. But I don't think we should cabin off all privacy considerations just for private browsing modes or privacy-specific browsers. Concepts like data minimization are meaningfully applied throughout the Web platform, so that there doesn't need to be a large gulf in functionality-privacy trade-offs between default modes and private browsing modes.

I've CCed the Privacy Interest Group list and hope that public-privacy@ would be a group of people to consult when the TAG finds privacy arguments unconvincing or otherwise has questions about privacy implications of particular designs.

Cheers,
Nick

[0] https://github.com/w3ctag/design-reviews/issues/206#issuecomment-379422513 <https://github.com/w3ctag/design-reviews/issues/206#issuecomment-379422513>
[1] https://lists.w3.org/Archives/Public/public-privacy/2016OctDec/0060.html <https://lists.w3.org/Archives/Public/public-privacy/2016OctDec/0060.html>
[2] https://github.com/httpwg/http-extensions/issues/284 <https://github.com/httpwg/http-extensions/issues/284>
[3] Unsanctioned Web Tracking
https://www.w3.org/2001/tag/doc/unsanctioned-tracking/ <https://www.w3.org/2001/tag/doc/unsanctioned-tracking/>