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

@yoavweiss 

> GREASEing by adding non-existent browser names would avoid blocking of unknown browsers (which as @mcatanzaro indicated, _is_ a major problem today).

It's true this would avoid blocking unknown browsers. What browsers are unknown, though, depends on the tools you use. As @ocram rightly noticed, there are incentives to detect even minor browsers (e.g. for analytics purposes) which means tools are created that make such detection possible and these same tools are then used to apply some fixes, enable some features, etc. only to some browsers.

When you use a browser-detecting library that knows about minor browsers, this library will ignore tokens like "NotBrowser" but it will take tokens like "Vivaldi" into account.

Vivaldi has recently stopped using its own token in the user agent string for this very reason. They wrote [a blog post](https://vivaldi.com/blog/user-agent-changes/) showing a few examples of how Google sites were serving a degraded experience to Vivaldi when the `Vivaldi` token was present in the UA. One example is [google.com](https://google.com) where input text appears outside of the input frame. I repeated the test locally and the site was broken with the `Vivaldi/2.10.1745.27` token but it worked correctly when I changed it to `Vivald/2.10.1745.27` (i.e. I just removed `i`) it worked again. It's clear, then that it's not just that any extra UA suffix would break the site; it was specifically singling out Vivaldi.

These issues wouldn't exist if sites were targeting engines by default instead of browser names when applying changes related to engines' APIs. Since even Google often does it by browser, it's hard to expect companies with less cash to spend time on making sure they're not singling out minority browsers.

> One can also imagine sending invalid headers that would also be correctly parsed by valid Structured Headers parsers, to avoid error-prone regex based "parsing". (e.g. `"Chrome"; v="73", "GibberishFirefox 66 dfgdfg"`)

This won't solve the case I described above.

> One could imagine a distant future where browsers would keep a similar list on which they perform targeted GREASEing (somewhat similar to what @mcatanzaro [suggested](https://github.com/w3ctag/design-reviews/issues/467#issuecomment-583110469)) in order to dissuade known compatibility offenders from their practices. Enabling GREASEing in the first place seems like a good first step in that direction.

If such a strategy was applied against known offenders it'd have to be done carefully as I can't imaging browser makers willingfully breaking existing sites of these offenders. Also, note that these offenders list would have to include Google today so Chromium would have to fight against the company that governs the project. It's hard to imaging it happening.

-- 
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-583781356