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

From: Ronan Cremin <[email-masked]>
Date: Thu, 11 Apr 2019 12:58:10 +0100

Hi,

My name is Ronan Cremin, I help to build a device recognition product 
widely-used in the web analytics, publishing and advertising industries. 
Full disclosure: my employer profits from analysis of UA strings, though 
moving the same information to client hints is not expected to impact 
this materially.

One concern over moving UA string information to Client Hints is that 
the information required to publish device-specific responses arrives 
only in the second request from the client. This imposes a performance 
penalty on publishers that serve a device-tailored HTML document. As 
Mike mentioned, RWD notwithstanding, many publishers employ 
device-specific responses as envisaged in RFC1945, usually to tailor the 
experience to a class of device e.g. smartphone, tablet, desktop and so 
on. Publishers endeavour to fit everything required for the first screen 
of content into this first response, so a delay to this impacts 
performance. The last time I checked more than 80% of the top 100 
websites used this technique.

Web analytics might also be impacted. Most web analytics solutions 
support a JavaScript-free integration approach based on linking a single 
pixel image hosted by the analytics platform. The ability to do this is 
impacted for the same reason—the information required for analytics 
becomes available only on the second request from the client.

Has thought been given to the performance impact of the proposal? Yoav 
mentions this issue in his Client Hints infrastructure document 
(https://github.com/yoavweiss/client-hints-infrastructure) but I haven't 
seen any attempt to quantify the impact.

Regards,
Ronan

On 29/11/2018 12:08, Thomas Peterson wrote:
> I would propose that all Accept* headers are included in Client Hints 
> as all can be used for some level of fingerprinting, e.g. Accept can 
> used to distinguish between desktop browsers (which typically have 
> html/xml MIME types) and cURL/wget which by default have '*/*'. Many 
> user agents also do their own guess work on response bodies anyway 
> (such as looking at the magic number) to determine content type or 
> encoding, so the impact of a "failed negotiation" of content can be 
> limited.
>
> Also, Is there a particular reason why Sec-CH-Lang omits Quality Values?
>
>
> Regards
>
>
> On 29/11/2018 10:22, Mike West wrote:
>> Hey folks,
>>
>> Section 9.7 of RFC7231 
>> <https://tools.ietf.org/html/rfc7231#section-9.7> rightly notes that 
>> some of the content negotiation headers user agents deliver in HTTP 
>> requests create substantial fingerprinting surface. I think it would 
>> be beneficial if we took steps to reduce their prevalence on the 
>> wire, and Client Hints looks like a reasonable infrastructure on top 
>> of which to build.
>>
>> `User-Agent` and `Accept-Language` seem like particularly tasty and 
>> low-hanging fruit, and I've sketched out two proposals as proofs of 
>> concept:
>>
>> *   `User-Agent` could be represented as ~four distinct hints: `UA`, 
>> `Model`, `Platform`, and `Arch`: 
>> https://github.com/mikewest/ua-client-hints is a high-level 
>> explainer, and https://tools.ietf.org/html/draft-west-ua-client-hints 
>> a sketchy ID for the new headers.
>>
>> *   `Accept-Language` could be represented as a `Lang` hint: 
>> https://github.com/mikewest/lang-client-hint is a high-level 
>> explainer, https://tools.ietf.org/html/draft-west-lang-client-hint an 
>> equally sketchy ID for the new header.
>>
>> I'd appreciate y'all's feedback. Thanks!
>>
>> -mike
>

---

From: Yoav Weiss <[email-masked]>
Date: Thu, 11 Apr 2019 17:47:33 -0400

Hey Ronan,

On Thu, Apr 11, 2019 at 8:11 AM Ronan Cremin <[email-masked]> wrote:

> on.

The viewport Client Hint can provide such distinction, but it exposes more
bits that are actually needed, so not a great option to expose by default,
without an opt-in.
>From your description, maybe exposing another tri-state hint by default
will be enough to cover the use-case and maybe it not expose too much bits
about the user in the process.
Can you open an issue on https://github.com/WICG/ua-client-hints describing
your use-case?

If we were to conclude that something like that is privacy-safe, I guess
the main problem would be to define where is the line drawn between a phone
and a tablet, and between a tablet and a laptop.
I suspect a standard definition of those borders is likely to become stale
fairly quickly...

Publishers endeavour to fit everything required for the first screen
> websites used this technique.

When was that? Do you have data you can point us to?

> becomes available only on the second request from the client.

I'm not sure that's a winning argument, as it sounds like those analytics
vendors exploit the current UA string to extract bits of information from
passive requests.
The current proposal will enable them to do the same (with the same number
of RTTs), but only after an explicit opt-in to receive that data from the
browser. An opt-in that can be monitored by the browser, extensions and
privacy researchers.

> Has thought been given to the performance impact of the proposal?

Yes.

> Yoav

As indicated in the document you linked to, we currently don't have a great
way to make fingerprinting-bits-exposing Client Hints an opt-in while
keeping sending those on the very first request.
That's unfortunate and we hope to improve on that in the future.
At the same time, the User-Agent string is exposing many bits of entropy,
so it is a privacy hole we're interested in blocking.

---

From: Ronan Cremin <[email-masked]>
Date: Wed, 17 Apr 2019 17:42:24 +0100

Yoav,

Thanks for the reply, comments below.

Regards,
Ronan

On 11/04/2019 22:47, Yoav Weiss wrote:
> Hey Ronan,
>
>
> On Thu, Apr 11, 2019 at 8:11 AM Ronan Cremin <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
> The viewport Client Hint can provide such distinction, but it exposes 
> more bits that are actually needed, so not a great option to expose by 
> default, without an opt-in.
> From your description, maybe exposing another tri-state hint by 
> default will be enough to cover the use-case and maybe it not expose 
> too much bits about the user in the process.
> Can you open an issue on 
> https://github.com/WICG/ua-client-hints describing your use-case?
Sure, I'll create an issue.

For the record, I'm not sure if a tri-state will do it. In my statement 
above I perhaps over-simplified the description. Many publishers use 
content adaptation to a device-specific level, not just the broader 
device class.
>
> If we were to conclude that something like that is privacy-safe, I 
> guess the main problem would be to define where is the line drawn 
> between a phone and a tablet, and between a tablet and a laptop.
> I suspect a standard definition of those borders is likely to become 
> stale fairly quickly...
True, any boundary definition along these lines would not last long 
enough to be useful—it's already a continuum; the ‘phablet’ term 
represents the problem here and folding screens will further blur the lines.
> When was that? Do you have data you can point us to?
It was a several years ago so I ran another quick analysis. My test does 
a GET on the main site entry point with a few different user-agent 
strings. I'm not fetching any additional linked resources, nor storing 
cookies or any other state. Public data for Alexa rankings is now 
limited to the top 50 sites, so that's what I used.

In summary, greater than 80% of the top 50 Alexa sites are using device 
adaptation at some level, with the majority offering more than two 
adaptations.

I'm using the byte size of the first HTML response as an indicator of 
device adaptation. I believe that this is crude, but workable. Some 
sites were blocked by my corporate firewall but in checking them 
afterwards via a VPN the percentage using UA adaptation only increases.

https://docs.google.com/spreadsheets/d/1ZPmpwsowowgLugVCEZuKaIeJUKw17jTjLN3iDzfK1AA/
> I'm not sure that's a winning argument, as it sounds like those 
> analytics vendors exploit the current UA string to extract bits of 
> information from passive requests.
> The current proposal will enable them to do the same (with the same 
> number of RTTs), but only after an explicit opt-in to receive that 
> data from the browser. An opt-in that can be monitored by the browser, 
> extensions and privacy researchers.
Exploit is possibly a loaded word here. Sending a UA string is a SHOULD 
requirement in the HTTP RFCs, not a MUST. User agents /voluntarily/ send 
a UA string, they are not obliged to, just like they wouldn't be obliged 
to send Hints per the proposal. Further, the contents of the UA string 
are entirely up to the browser and thus they are already empowered to 
decide how many bits of information to include in them. The Safari team 
have already elected to reduce the meaningful bits.
> As indicated in the document you linked to, we currently don't have a 
> great way to make fingerprinting-bits-exposing Client Hints an opt-in 
> while keeping sending those on the very first request.
> At the same time, the User-Agent string is exposing many bits of 
> entropy, so it is a privacy hole we're interested in blocking.
Improving privacy is a laudable goal, I can't imagine that anyone would 
take issue with this.

But it's worth asking the question if the cost of attaining the goal is 
worthwhile. For the particular case of moving the user-agent string to 
Hints (rather than Hints in general), there are 20+ years of 
infrastructure based around RFC1945 and its successors. There are known 
performance penalties in moving the UA string to Hints. Add to this the 
fact that there isn't yet a consensus whether this move would improve or 
disimprove privacy and I think it's fair to say that there is a debate 
to be had around the overall merits of the proposal.
>     >> explainer, and
>     https://tools.ietf.org/html/draft-west-ua-client-hints
>     >> explainer,
>     https://tools.ietf.org/html/draft-west-lang-client-hint an