[prev in list] [next in list] [prev in thread] [next in thread] 

List:       webkit-dev
Subject:    Re: [webkit-dev] Position on User-Agent Client Hints
From:       Maciej Stachowiak <mjs () apple ! com>
Date:       2020-05-08 7:04:22
Message-ID: 8430DBAD-C593-4A43-8E05-000A00E5A7F7 () apple ! com
[Download RAW message or body]


I would consider myself mildly positive as to the direction, but that's my personal \
view for the moment, absent consultation with my colleagues. I will solicit more \
viewpoints.

I particularly appreciate the responsiveness to feedback and that Yoav in particular \
has been willing to iterate.

I think there's a number of things in the spec that should be cleaned up before an \
implementation ships enabled by default, specifically around interop, privacy, and \
protection against UA lockouts. I know there are PRs in flight for some of these \
issues. I think it would be good to get more of the open issues to resolution before \
actually shipping this.

Regards,
Maciej

> On May 7, 2020, at 4:22 PM, Michael Catanzaro <mcatanzaro@gnome.org> wrote:
> 
> 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/
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[prev in list] [next in list] [prev in thread] [next in thread]