- From: Mike West <mkwst@google.com>
- Date: Mon, 14 Jan 2019 06:26:46 -0800
- To: Martin J. Dürst <duerst@it.aoyama.ac.jp>, Ilya Grigorik <igrigorik@google.com>, Yoav Weiss <yoavweiss@google.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAKXHy=dUy1n5dNkxj_L3Ov=auaZr-L-+ZaneqLq4FCrRQQ72Gw@mail.gmail.com>
On Sun, Jan 13, 2019 at 3:56 AM Martin J. Dürst <duerst@it.aoyama.ac.jp> 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 <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? -mike
Received on Monday, 14 January 2019 14:27:21 UTC