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

[Mike West <[e-mail]>]

On Sun, Jan 13, 2019 at 3:56 AM Martin J. Dürst <[e-mail]>
wrote:

> Sorry to be very late, and with a rather basic question:
>
> The point about substantial fingerprinting is definitely important. But
> what's the difference, in terms of fingerprinting, between the following
> two alternatives?
>
> a) The browser sending out Accept-Language,... to a server interested in
> fingerprinting.
>
> b) A server interested in fingerprinting sending out an Accept-CH header
> with the equivalent information, even if the server doesn't need e.g.
> language information for serving the request.
>

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 <[e-mail]>, +Yoav Weiss <[e-mail]>, 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?

-mike