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

Michael Catanzaro mcatanzaro at gnome.org
Thu May 7 16:22:10 PDT 2020


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!) [1]. 
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/




More information about the webkit-dev mailing list