Bug 278284 – WKWebView version not available in API and not included in user agent for macOS

• Status: NEW
• Component: WebKit API

[Steve Repsher]

Currently there is no way for app authors to determine the Safari version being used by a WKWebView.  It is also not included in the default user agent string for macOS (i.e. the string set by the contentMode before before appending the applicationNameForUserAgent).  On iPhone or iPad, this is not an issue since the Safari version matches the OS version, which is included in the string.

The current user agent string looks like:

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

The WebKit version there is old and frozen.  There is no useful information for clients to use in that string, and there is no way for applications to add the useful Safari version for clients.  I understand that user agent strings are a contentious topic, but it seems like a correction is warranted here until some version of the client hints API is widely supported.

My proposed solution would be:
1. Make the version available to app authors, perhaps as a static string on the WKWebView class (preferably as a user-friendly Safari version).
2. When the contentMode is desktop (either on macOS or pretending to be from an iPad), add the appropriate tokens to the default string to identify the Safari version as would be done by the browser (e.g. "Version/17.5 Safari/<webkit-version>").

[Karl Dubost]

Steve,

What are the scenarios you are trying to solve with the user agent string, which are not possible with features detection?

Understanding the use cases for the version number will help.

[Steve Repsher]

(In reply to Karl Dubost from comment #1)
> What are the scenarios you are trying to solve with the user agent string,
> which are not possible with features detection?

TBH, I'm not sure what that question has to do with the merit of the report?  But to divulge for a moment, my primary use case is for an open source app called Home Assistant.  We have a build for modern browsers, and a heavily transpiled and polyfilled build for legacy browsers.  While we use feature detection as backup, splitting based on known browser version is far more convenient and virtually free of maintenance over time.

> Understanding the use cases for the version number will help.

Safari browser on every platform currently sends the correct version in the user agent header.  A WKWebView on iPhone and iPad does the same.  So, I don't understand the need for justification of its use here when WebKit is already doing it.  This report is simply pointing out the discrepancy with WKWebView on macOS, and the inability of app authors to manually retrieve it with the current API.  That seems like an oversight rather than a conscious choice by Apple, no?

Similarly, modifying this bug to depend on the implementation of client hints also makes zero sense to me.  Unless I'm really missing something, in no way do either of the solutions requested depend on that.

[Karl Dubost]

Thanks for the more detailed answer. I had missed some of the point you were making. 
 

This is the current UA string of Safari on macOS
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Safari/605.1.15


Just to explain a bit 

/start of context

The UA string has been frozen for a while, except for the "Version/" part.

The two main reasons to try to avoid too much entropy in the UA string
1. Fingerprinting for privacy
2. Bad features detection for websites

the 2. is a constant pain point while some websites stay on top of their games (minority), a lot of JS libraries and websites are not maintained and break one way or another when the detection is done through UA version, which then forces the browsers to hack around later on through Quirks in WebKit, Site Interventions in Firefox, etc. Specifically when time is lingering, it breaks at a point.

Chrome, Firefox are also pushing forward with an effort to reduce the entropy of the UA string
https://compat.spec.whatwg.org/#ua-string-section


/end of context. 

Back to your actual bug. 

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

So if I understand you would rather have ?

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


User Agent string on WebKit
on iOS 
https://searchfox.org/wubkat/source/Source/WebCore/platform/ios/UserAgentIOS.mm
on macOS
https://searchfox.org/wubkat/source/Source/WebCore/platform/mac/UserAgentMac.mm


But what you are asking seems to be an API on the side of Safari code, not WebKit.
Let me try to find more information about the history of this.

[Michael Catanzaro]

(In reply to Steve Repsher from comment #2) 
> TBH, I'm not sure what that question has to do with the merit of the report?
> But to divulge for a moment, my primary use case is for an open source app
> called Home Assistant.  We have a build for modern browsers, and a heavily
> transpiled and polyfilled build for legacy browsers.  While we use feature
> detection as backup, splitting based on known browser version is far more
> convenient and virtually free of maintenance over time.

You're assuming the Safari version indicates Safari, but it could be any WebKit-based browser. You have to assume the Safari version is a lie. Notably, if you see Version/18.0 and assume the browser exposes the same features as Safari 18.0, or has the same bugs as Safari 18.0, or is more than vaguely similar to Safari 18.0, then you've messed up.

(In reply to Steve Repsher from comment #2)
> Safari browser on every platform currently sends the correct version in the
> user agent header.  A WKWebView on iPhone and iPad does the same.  So, I
> don't understand the need for justification of its use here when WebKit is
> already doing it.  This report is simply pointing out the discrepancy with
> WKWebView on macOS, and the inability of app authors to manually retrieve it
> with the current API.  That seems like an oversight rather than a conscious
> choice by Apple, no?

Fair point. I agree. It doesn't make sense for WKWebView to provide a Safari version on iOS but not on macOS.

> So if I understand you would rather have ?
>
> Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 <applicationNameForUserAgent>

The Version/18.0 is mandatory for web compatibility. Might as well be nice to WKWebView applications and add it.

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

[Steve Repsher]

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 ;-).

[Radar WebKit Bug Importer]

<rdar://problem/134631568>