Re: [w3ctag/design-reviews] User-Agent Client Hints & UA Reduction (#640)

> One question that came up : currently browsers lie in the UA string because web sites make assumptions. What tells you that the CH approach will compel UAs to tell the truth more often or will somehow disincentivize them from lying?

Hi, I maintain WebKit's UA string quirks list (currently used only by WebKitGTK). I can pretty much promise that if WebKit were ever to implement CH -- which currently seems unlikely, I believe our position on CH is neutral? -- then we would definitely lie, likely beginning from day one, and likely in the same ways and for the same reasons that we lie in the UA header. How exactly depends on which hints are mandatory to implement in the final spec. We would probably hardcode Safari for the browser name, for example, and *maybe* let UAs override that at their peril (not recommended). We might choose to lie about CPU architecture or operating system, etc. Unfortunately, we can be certain that telling the truth will cause websites to break in the same ways they do currently with the UA string, so we have extremely low incentive to be truthful.

I'm not sure this is necessarily a bad thing, though. I don't see CH as a way to avoid lying. CH would be a more structured alternative to the UA string, to encourage web developers to avoid *accidentally* breaking things by misparsing the UA string. Reducing accidental breakage seems good for me. But there will always be websites that decide they do not want to allow access to FreeBSD users or s390x users (yes, these run web browsers!) or whatever, and that means we'll always need to lie.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/640#issuecomment-895549581