[Webkit-unassigned] [Bug 278284] WKWebView version not available in API and not included in user agent for macOS

Wed Aug 21 13:29:51 PDT 2024

https://bugs.webkit.org/show_bug.cgi?id=278284

--- Comment #5 from Steve Repsher <steverep+webkit at gmail.com> ---
Karl & Michael,

Thanks for the detailed replies.  First let me address specific things for this report:

> So if I understand you would rather have ?

Correct, except also add the "Safari/<webkitVersion>".  All regexps I've seen look for both "Version/" followed by "Safari/" to accurately identify Safari.  So the string would look like:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/<safariVersion> Safari/<wkVersion> <applicationNameForUserAgent>

> But what you are asking seems to be an API on the side of Safari code, not WebKit.

Okay.  I just assumed WK controlled the UA for WKWebView.  Also, per the OP, it seems reasonable to add the version to the API (e.g. via WKWebView.safariVersion).

> What I'd prefer is to just change the Version to something static, say Version/42.0, and leave it frozen forever. Then we won't have to play version number games with websites like in https://github.com/nextcloud/server/issues/40793

FWIW, NextCloud's browserslist query is not great and is probably the main source of their issue.  Their inclusion is purely based on usage stats, which browserslist specifically documents as a bad idea as it will often exclude recent releases (along with betas).  Home Assistant uses it too, so here's an example of better queries:
https://github.com/home-assistant/frontend/blob/a235f7698546f7a2f46111cac061176d1533d411/.browserslistrc

Freezing the version defeats the purpose of providing it in the first place, and kills many legitimate use cases (including my example).  Plus it is out of scope for this report.  And I suppose that's a good segue for my attempt at a humble response to other points...

I'll preface by saying I hate the user agent string as much as the next developer.  It's an absolute mess both for privacy and for legitimate use.  I would love to see it deprecated and replaced with some version of the client hints interface.  But the practice of freezing without implementing such an alternative is a bad approach IMHO.  All it does is exchange one problem for others.

The message from browsers is clearly that feature detection is the answer to all UA uses.  And while that's probably true in the majority of cases, it's not always the best solution.  If I want to decide to use a web API or load a polyfill, sure use of the UA is dumb.  But take the modern/legacy approach for Home Assistant as an example, and consider what that looks like with feature detection.

Right now, with tools like babel, browserslist, core-js, etc., we can simply say the modern build will support all major browsers released in the last year, and legacy will be served to everything else.  That's fully automated over time using the UA string.  If I wanted to only use feature detection, the process would be a roughly yearly cycle or so of:

1. Pick 1 or 2 features that were implemented about a year ago in ALL browsers.  That's actually a PITA project given that you vendors aren't exactly in sync with what gets implemented when.  So in the end we will end of with a split that confuses our users every year, and inevitably pisses some off.
2.  Rewrite the feature detection (often only easy for easy new features) and rewrite the browserslist queries (which now have to be hard coded, defeating the tool's purpose for the most part).
3. Fix bugs and repeat.

Now also consider that those tools work with compatibility data from CanIUse and/or MDN.  In other words, compatibility can only be guaranteed for the browsers they have data on.  Pure feature detection could then end up serving the modern build to some client that passes the initial split detectors, only to fail somewhere else in the app when it encounters another feature or syntax it doesn't support.

Finally, also consider that privacy and fingerprints can sometimes be non-issues.  In Home Assistant for example, the user controls their own server.  So high entropy can actually be a good thing as it allows us to identify to them which client did what in their homes.

Anyway, that's my 2 cents.  Perhaps my problem is I have precisely zero sympathy for sites that stop working because of bad or old UA usage ;-).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240821/ab99586c/attachment.htm>