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/2016
>>> OctDec/0060.html
>>> [2] https://github.com/httpwg/http-extensions/issues/284
>>> [3] Unsanctioned Web Tracking
>>> https://www.w3.org/2001/tag/doc/unsanctioned-tracking/
>>>
>>>
>>
>