Re: `Accept-CH` header is weird

On Thu, Apr 12, 2018 at 7:41 PM, Nick Doty <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/
>
>