RE: `Accept-CH` header is weird

I agree with Nick and Eric. Fingerprinting will become more popular as a tracking technique as browsers implement more privacy features such as third-party cookie partitioning. The web, and people’s trust in it, will be damaged if the only recourse is to remove functionality by content blocking or wholesale feature removal.

 

There has to be a simple standardised way for a user to find out if a site, or embedded third-party, is fingerprinting. The procedure might have to err on the side of caution, but the challenge of minimising false positives would be a competitive differentiator between UAs. Anything that the UAr finds will tend to have to be clearly explained in sites’ privacy declaration. An automatic link to such explanations would be even better!

 

Mike

 

From: Eric Rescorla <ekr@rtfm.com> 
Sent: 13 April 2018 17:24
To: Alex Russell <slightlyoff@google.com>
Cc: Nick Doty <npdoty@ischool.berkeley.edu>; TAG List <www-tag@w3.org>; public-privacy (W3C mailing list) <public-privacy@w3.org>
Subject: Re: `Accept-CH` header is weird

 

 

On Fri, Apr 13, 2018 at 9:07 AM, Alex Russell <slightlyoff@google.com <mailto:slightlyoff@google.com> > wrote:

Hi Nick, Eric:

 

Thanks for the thoughtful comments.

 

The analysis about opt-in free CH comes from turning the question around slightly: if any origin can opt-in for subsequent top-level navigations, and browsers wish not to provide that information to those origins (selectively, or as a policy), isn't the recourse identical to the recourse in the non-opt-in scenario?

 

I.e., browsers will need to filter the list (perhaps to zero) to maintain whatever privacy invariants they wish to maintain. To be effective, this would also need to be paired with removing/modifying the runtime behavior of web content (turning off media query support, blocking various DOM APIs, disabling scripting, etc.).

 

Similarly, if browsers want to know what's being exfiltrated, they can simply not support CH (always send a null list).  If visibility of script/active measures is the goal, this seems like the only way to achieve it.

 

The opt-in-CH-is-good position seems untenable as a result.

 

What am I missing? 

 

I'm not sure if you're missing anything, but I have a slightly different analysis. If the site has to take active measures to record a piece of client information then the clients are able to determine when the site is asking for it and if that request is reasonable. However, if the posture is that the browser always sends it, then the user has no way of knowing.

 

Take as an example, the (not in the current spec, but suggested) Geolocation hint. Currently, the browser knows when that happens and can show the user if it's in use, as in, for instance, "I'm actually using a map on this site". However, if there is a Geolocation client hint, then that doesn't work, because the site is always getting the data whether or not they are using it. The same is true, though to a lesser extent, with other hints.

 

Yes, of course, the browser has the recourse to not support CH, but the question at hand is whether it's good for the Web to standardize this kind of functionality at all.

 

-Ekr

 

 

 

Regards

 

 

 

On Fri, Apr 13, 2018 at 6:51 AM, Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com> > wrote:

 

 

On Thu, Apr 12, 2018 at 7:41 PM, Nick Doty <npdoty@ischool.berkeley.edu <mailto:npdoty@ischool.berkeley.edu> > wrote:

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].

 

I have to agree with Nick here. There are a number of widespread fingerprinting techniques that we know about largely because they are active. See, for instance, http://randomwalker.info/publications/OpenWPM_1_million_site_tracking_measurement.pdf

 

-Ekr

 

 

 

 

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

[1] https://lists.w3.org/Archives/Public/public-privacy/2016OctDec/0060.html 

[2] https://github.com/httpwg/http-extensions/issues/284

[3] Unsanctioned Web Tracking 

https://www.w3.org/2001/tag/doc/unsanctioned-tracking/