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
