W3C home > Mailing lists > Public > www-tag@w3.org > April 2018

Re: `Accept-CH` header is weird

From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 13 Apr 2018 09:51:05 -0700
Message-ID: <CABcZeBNmU=-DAbMp2KtE1WD30ULgMemrr9Fzqe_3urEd=Cx6Kw@mail.gmail.com>
To: David Singer <singer@apple.com>
Cc: Alex Russell <slightlyoff@google.com>, Nick Doty <npdoty@ischool.berkeley.edu>, TAG List <www-tag@w3.org>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>
On Fri, Apr 13, 2018 at 9:47 AM, David Singer <singer@apple.com> wrote:

> Maybe I don’t fully understand the proposal, but if
> a) the header from the server was called request-CH (request client hints)
> and
> b) the clients only send information IF requested and
> c) they send the intersection of what’s requested and what they are
> willing/able to send
>
> then the UAs would know and be able to choose what’s being sent, and could
> take active steps when wanted to minimize fingerprinting (e.g. during
> private browsing)? if the list of client hints gets longer, they’d also be
> in a position to be suspicious of sites that ask for everything.
>

I don't think that that helps that much.

The issue is that the server's request is sticky and so the client sends
the data with every request, whether the server is consuming the data or not

-Ekr


>
> > On Apr 13, 2018, at 18:23 , Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >
> > 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/
> 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/
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
>
Received on Friday, 13 April 2018 16:52:13 UTC

This archive was generated by hypermail 2.3.1 : Friday, 13 April 2018 16:52:13 UTC