Re: `Accept-CH` header is weird

Again, the question here isn't "*do you view sending this data as a good or
bad thing?*", it's "*how will browsers who want to not send it react?*". If
the answer is "*they won't send it under any `Accept-CH` value*" (the
logical outcome), then implementing Client HInts *at all* looks suspect,
and the question regarding opt-in vs. automatic CH value transmission is
moot.

Regards

On Fri, Apr 13, 2018 at 10:27 AM, Mike O'Neill <michael.oneill@baycloud.com>
wrote:

> 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>
> 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> wrote:
>
>
>
>
>
> 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/publi
> cations/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#issu
> ecomment-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/
>
>
>
>
>
>
>
>
>