W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2019

Re: Migrating some high-entropy HTTP headers to Client Hints.

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Tue, 15 Jan 2019 10:15:22 +0000
To: Mike West <mkwst@google.com>, Ilya Grigorik <igrigorik@google.com>, Yoav Weiss <yoavweiss@google.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <f6129f8d-b4b6-8f05-c18a-aae71e8d0908@it.aoyama.ac.jp>
Hello Mike,

Many thanks for your explanations.

On 2019/01/14 23:26, Mike West wrote:

> Hey Martin, good question!
> 
> In short, the client hints infrastructure places a number of limitations on
> the ways in which hints can be enabled for a given request. Some of those
> are documented in
> https://tools.ietf.org/html/draft-west-lang-client-hint-00#section-3. I'll
> hit the highlights below:
> 
> 1.  No plaintext delivery; hints can be delivered over encrypted channels,
> which means that we'll substantially reduce the scope of leakage to network
> attackers.
> 
> 2.  Client hints are moving to a delegation model whereby "first-party"
> responses (top-level navigations, etc) can opt-into receiving hints, but
> subresource requests cannot. That is, assuming the server you're talking
> about above lives at `https://fingerprinter.com/`, it can obtain access
> when the user directly navigates to `https://fingerprinter.com/`, but can
> only obtain access in third-party contexts (e.g. when embedded as a frame
> on `https://publisher.com/`) if the top-level domain explicitly delegates
> the privilege to it. Note that there's some ongoing work (described in
> https://tools.ietf.org/html/draft-west-lang-client-hint-00#section-3.2) to
> bring the various specifications up to date with this decision. +Ilya
> Grigorik <igrigorik@google.com>, +Yoav Weiss <yoavweiss@google.com>, and
> friends are working through those.
> 
> 3.  Because this data is no longer broadcast by default, but must be
> explicitly requested, the onus falls upon the requestor to justify the
> request. The explicitness makes it easier for researchers to dig into data
> usage, and, in the best case, brings abuses to light.
> 
> Does that answer your question?

Partially. But let me be more specific about the threat scenario I'm 
thinking about. Web sites use all kinds of third party services, some of 
the main ones being advertising and analytics. All these services come 
with installation instructions. My (easy, I'd say) guess is that these 
installation instructions will include instructions to activate the 
necessary third-party opt-ins for the server in question for those 
third-party services that are interested in fingerprinting.

Given that many third-party services are interested in fingerprinting, 
and that many Web administrators follow instructions carefully, I'd 
guess that most sites will end up with fingerprinting third-party 
services anyway. Those sites not interested in fingerprinting didn't 
analyse the Accept... headers to begin with.

Regards,   Martin.
Received on Tuesday, 15 January 2019 10:15:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 15 January 2019 10:15:51 UTC