[webkit-dev] Position on User-Agent Client Hints

[Haelwenn (lanodan) Monnier]

[2020-05-07 18:22:10-0500] Michael Catanzaro:
> My personal $0.02: I'm mildly supportive of this spec. It's certainly 
> an improvement on existing HTTP user agent headers. I appreciate that 
> you worked to incorporate feedback into the spec and considered the 
> concerns of small browsers.
> 
> Is it going to solve all the problems caused by user agent headers? No. 
> If WebKit implements the spec, we're surely going to eventually need a 
> quirks list for user agent client hints to decide which websites to lie 
> to, just like we already have quirks for the user agent header. And as 
> long as Chrome sends a user agent header that includes the string 
> "Chrome", it's unlikely we'll be able to get rid of the existing quirks 
> list. But I think client hints will probably reduce the amount of 
> websites that *accidentally* break WebKit, by replacing wild west UA 
> header parsing with well-defined APIs, and adding some GREASE for good 
> measure. The promise of freezing Chrome's UA header sounds nice, as it 
> makes quirks easier to maintain. And being able to ration entropy by 
> revealing details about the platform on an active rather than passive 
> basis is quite appealing.
> 
> The spec attracted some misplaced concern about negative impact to 
> small browsers, which I've rebutted in [1]. I'm not quite so 
> enthusiastic about this spec as I was initially, especially after I was 
> convinced that the GREASE is never going to be enough to remove our 
> quirks list, but it's certainly not going to *hurt* small browsers.
> 
> This spec has received some pretty harsh criticism from the user 
> tracking industry (some call it the "ad industry"). Not historically a 
> friend of WebKit, so sounds good to me. ;)
> 
> One concern I haven't mentioned elsewhere is that frozen UA header 
> might encourage deeper levels of fingerprinting than are currently 
> used, e.g. for ad fraud prevention. caddy has started blocking 
> WebKitGTK users based on TLS handshake fingerprint (yes, really!) [2]. 
> If techniques like that take off as a result of this, that could 
> potentially backfire on us quite badly. But websites could choose to do 
> such things today anyway, client hints or no, and if so, the solution 
> will be for us to just try even harder to look more like Chrome.
> 
> Seems like a net positive overall. I don't work for Apple and can't say 
> whether it might be implemented by WebKit.
> 
> Michael
> 
> [1] 
> https://github.com/w3ctag/design-reviews/issues/467#issuecomment-583104002
> [2] https://mitm.watch/

This particular thing is bullshit, it's not even using the TLS handshake.
Copying the curl options is enough and what made me notice it that 
glib-networking with OpenSSL (non-default) has the message.

Screenshot showing a simple curl vs. a curl with webkit-gtk's options:
https://queer.hacktivis.me/media/5d9122fd-64c4-43de-ba02-776b162c106e/screen.png

Most aggressive fingerprinting done currently is done with JavaScript 
or CSS, having yet another few lines to get the Client Hints isn't 
going to change much things for them.
Sure, it makes it a bit harder for some small advertisers that wouldn't 
do much fingerprinting but do not forget that Google is probably the 
biggest one and with a very large toolset.