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

In the discussion surrounding Mozilla's position change, @hsivonen [stated](https://github.com/mozilla/standards-positions/issues/552#issue-942122883), regarding the [browser bugs use case](https://github.com/WICG/ua-client-hints#browser-bug-workaround):

> This one indeed is something that browsers can’t offer designed detection surface. Still, this generally needs the major version of the engine. Not “brand”, minor OS version, or such.

I wanted to offer a few counter-examples. My employer, [Cloudinary](https://cloudinary.com), serves a lot of media to Safari on behalf of our customers. Media decoding in Safari is largely handled by the underlying OS libraries, and we have struggled to work around a [series](https://bugs.webkit.org/show_bug.cgi?id=219977) of [unfortunate](https://bugs.webkit.org/show_bug.cgi?id=222150) [bugs](https://bugs.webkit.org/show_bug.cgi?id=227920) introduced and fixed in minor macOS versions since Apple froze macOS Safari’s `User-Agent` header on `Macintosh; Intel Mac OS X 10_15_7`).

<details>
<summary><em>That's the gist of it; unfold for gory details</em></summary>

@hsivonen:

> An interesting question is how relevant this actually is with current version uptakes for browsers and sites having resources to pay attention to users who for whatever reason aren’t updating according to the rapid release schedule. At the time sites deploy a workaround, they can’t necessarily know what future browser version won’t have the need for the workaround. Can we guarantee only retrospective use? Do Web developers care enough about retrospective workarounds for evergreen browsers?

We never want to ship someone a broken image/video. Part of our core value proposition to customers is handling the complexity of UA-adaptive media encoding/optimization, for them. When we encountered [an earlier Safari media bug](https://bugs.webkit.org/show_bug.cgi?id=205568) introduced and fixed before the UA freezing, our flow was to:

- Identify which types of media were affected, in starting with which OS version
- Deploy new resource generation and delivery logic, keyed on facts about the content and the requests' `User-Agent`s, to avoid sending would-be-affected media to would-be-affected end users. Also bust a bunch of caches, so that the resources behind existing URLs get regenerated using the new logic. Affected UAs ended up getting lower-common-denominator, significantly-less-optimized resources (for instance, when JP2s with alpha started acting up: PNGs instead of JP2s)
- Find or file browser/OS issues
- Monitor those issues, and when a version that fixes the bug is released, update our logic again, accordingly. The workaround logic that looks for a range of affected versions then lives on ~forever in our codebase, even though affected requests dwindle over time.

When confronting the more recent macOS media-handling bugs, we can't identify the request's OS, so we create a loose, no-guarantees mapping between browser version (which Safari still reports) and OS version. Because broken media is a much worse experience than unoptimized media, we end up being rather conservative, sending fallback formats to (sometimes many) more people than we need to during the workaround period, and nervously guessing which browser version will almost guarantee a certain OS version, before flipping the fallback switch back off.

Because there are no guarantees, we are almost certainly sending broken media to a non-zero number of end users. Also, the extra cache busting and delivery of unoptimized media doesn't come without costs for us, our customers, and end users. We are very much looking forward to a future in which customers who are particularly impacted by these costs could choose to delegate OS version information to us, via the UA client hints, allowing us to send fallbacks to precisely the end users who need them.

</details>

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