Accidentally removed Yoav from Cc and I’m not sure if he is on this list.

> On May 8, 2020, at 12:04 AM, Maciej Stachowiak <m...@apple.com> wrote:
> 
> 
> 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 <mcatanz...@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

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

Reply via email to