Re: [w3ctag/design-reviews] Partial freezing of the User-Agent string (#467)

> One specific concern have about this proposal has to do with how "minority browsers" are impacted.

I have [some experience](https://trac.webkit.org/log/webkit/trunk/Source/WebCore/platform/UserAgentQuirks.cpp) with constructing user agent strings for a minority browser (Epiphany, using WebKitGTK). I see a lot of concern in this thread as to how the proposal could impact minor browsers, but not much explanation of why that impact might be negative.

> it's unclear what the effects on minority browsers will be (although I think it could be either positive or negative)

I have no doubt: the impact will be positive. Very positive. In particular, Yoav's proposed change will make it harder for Google to screw over small browsers, something it has previously done to us many times in the past. (And continues to do to this day. I have a pending TODO to try to figure out a new user agent quirk for Google Docs. It's not easy.) There are some details of the UA-CH proposal that seem problematic to me (details below), but overall it seems like a big step in the right direction. This change will help small browsers deal with the compatibility issues caused by websites' abuse of the user agent string. As the maintainer of the Epiphany web browser, I'm confident Yoav's proposal will help us far more than it helps Chrome.

> And yes, from the PoV of non-dominant browsers, who often need to maintain support for their development by citing usage numbers, I don't think it would be a good thing to suppress the the browser name.

For a non-dominant browser, it is absolutely essential to send a user agent that matches a dominant browser as closely as possible. A small browser cannot be web compatible otherwise. Even appending the browser's name to the end of the user agent -- which is *relatively* safe -- creates risks; I have pending to investigate whether we should stop doing that. Constructing a viable user agent string for a small browser is *hard.* The user agent header is *extremely* fragile and difficult for a non-dominant browser to get right. I have spent far too long experimenting with fairly small changes to the user agent, and also experimenting with WebKit's user agent quirks list (which is absolutely required, because it is impossible for a non-dominant browser to select a user agent that will work for all major websites).

Yoav's proposal is designed to give small browsers a better chance, not to favor Chrome. The status quo of the user agent string favors Chrome, and is in fact [absolutely brutal for small browsers](https://lists.webkit.org/pipermail/webkit-dev/2017-May/028991.html). Please read that linked thread in full if you have any doubt that the status quo is awful for small browsers. Years ago, I wrote:

> User agent is an extremely demotivating, never-ending game, and it's by 
> far our biggest web compatibility problem. It almost feels as if Google 
> is deliberately trying to break WebKit, which I know is not true as 
> they don't care either way about us... but they do know full well that 
> basing logic off of user agent checks serves to harm less-popular 
> browsers, so it's hardly unintentional. I cannot think of any aspect of 
> WebKit development less gratifying than maintaining our user agent 
> quirk list, nor any bigger user agent offender than Google.

The situation has not improved since then.
Now, we can debate the details of how exactly `Sec-CH-UA` would work. The [current spec](https://wicg.github.io/ua-client-hints/) actually exposes far too much IMO; eventually, it could become just as problematic as user agent strings currently are. (I've had to hardcode fake user agents for websites that blacklist FreeBSD users, or websites that treat ARM devices as mobile devices. Creating a standardized mechanism for websites to do this is a mistake.) But that's orthogonal to this issue.

In addition to what Yoav has already proposed, I would also very much like to see the string "Chrome" completely removed from Chrome's user agent, despite the short-term web compat issues that would cause. If that's out of the question, I'd love to see the version number frozen at least. Playing catch-up with Chrome user agents is very frustrating.

> TL;DR: We need the full os and browser version to survive as a small ad network. And more importantly, we need this data as part of every first http request, without being discriminated against for being a less frequently visited / smaller website.

The user agent is very difficult due to such competing interests. Small browsers need servers to either not have access to this information, or to have access only to fake frozen versions of this information, and we need collaboration from large browsers to make this possible. As far as we're concerned, any web server that so much as looks at the user agent string is evil. Revealing OS, browser, or architecture information allows websites to block us and makes it very hard to compete with Chrome.

-- 
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/467#issuecomment-583104002