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

Re: `Accept-CH` header is weird

From: Nick Doty <npdoty@ischool.berkeley.edu>
Date: Fri, 13 Apr 2018 13:02:09 -0700
Message-Id: <F483C1E6-6EDF-4D50-A984-69EEE262871E@ischool.berkeley.edu>
Cc: Eric Rescorla <ekr@rtfm.com>, TAG List <www-tag@w3.org>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>
To: Alex Russell <slightlyoff@google.com>
On 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.).

As a reminder, this doesn't apply just to top-level navigations, but also to embedded content, which might be loading of an image that doesn't have access to DOM APIs, JavaScript, or CSS.

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

I think this is the distinction between limiting fingerprinting surface and making fingerprinting detectable.

I agree that browsers that wish not to expose this fingerprinting surface or to limit disclosure of this information to sites will not send the client hint in any case, whether there's an opt-in request from the server or not. But we're also especially interested in the ability for a client, a researcher or some other observer to detect when a site might be gathering information for the purpose of fingerprinting. If sites need to indicate that they want this data, that provides a way for others to measure the potential use of this data for fingerprinting users.

In some cases, as ekr is suggesting with the elsewhere-proposed geolocation hint, that might be done by a single client who evaluates whether it makes sense to share that data in that case. But even outside the capabilities of a single client, the data on larger-scale use is only available if servers have to provide some visible indication that they want that data. Researchers can analyze after-the-fact whether those requests are reasonable for content-negotiation or not; policymakers and enforcement agencies can use that data to support cases, etc.

Hope this helps,
Nick

Received on Friday, 13 April 2018 20:02:44 UTC

This archive was generated by hypermail 2.3.1 : Friday, 13 April 2018 20:02:45 UTC