Scope of "user agent" in proposal

[ronancremin]

This is more of a question than an issue.

As it currently stands, the UA-CH proposal is written using the accepted term "user agent" for the client, as might be expected. But much of the proposal feels a little narrower than this and mostly seems to describe the issues (and the proposal) in the narrower case where the user agent is specifically a web browser.

A lot of web traffic these days actually originates from native apps that aren't browsers as such, even though they have the ability to display web pages via OS-supplied web views or their own built-in renderers. Many such native apps chose to add tokens to a device's UA string in order to identify themselves e.g.

• Twitter: Mozilla/5.0 (Linux; Android 9; Redmi Note 7 Build/PKQ1.180904.001; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/76.0.3809.132 Mobile Safari/537.36 TwitterAndroid
• Pinterest: Mozilla/5.0 (Linux; Android 8.0.0; SM-G930F Build/R16NW; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/76.0.3809.132 Mobile Safari/537.36 [Pinterest/Android]

In some cases apps may wish to identify the device and renderer (as is routine) but also the name of the app in question. As it is written currently I don't believe that the UA-CH proposal provides a way to do this.

So the question is: is the scope of this proposal "web browsers" or should it be more general to reflect current web traffic patterns? If it is to be more general then there are use cases around non-browser apps that should perhaps be considered.

[miketaylr]

If it is to be more general then there are use cases around non-browser apps that should perhaps be considered.

You raise a good point. I think it's worth considering how UA-CH might make sense—or not—for apps with embedded browsers/webviews. It could make sense for these additional tokens to be added in the "brandlist", but maybe something entirely different is appropriate.

[jwrosewell]

It seems we have three components. The vendor, name and version of the;

1. engine used to interpret instructions and interface with the user;
2. module that invokes the engine; and
3. application that invokes the module OR uses the engine directly.

A "user agent" is a type of application, but not the only application.

I'm not sure if engine, module and application are the right names, but it does seem like this reflects the software layer above the operation system in practice today.

[ronancremin]

To attempt to answer my own question, mentions of the JavaScript API in the proposal, and the fact that the underlying Client Hints proposal appears to be browser-specific suggest that the User Agent Client Hints proposal is scoped to browsers/webviews in particular rather than "user agents" in general. Is that a fair comment?

[miketaylr]

Circling back to this, as the draft spec is written today, it's pretty "web browser" specific. But we are starting to explore what Client Hints might look like in a WebView context (which would also cover UAs/apps that allow for web browsing like Instagram or TikTok, etc). Understanding how sites or servers might want to use "app name" info (or similar?) would be useful.

[jross1012]

@miketaylr For the purpose of traffic analysis and usage analytics, a client hint connecting a WebView session with a source app would be extremely useful. This would provide us with much needed visibility in the source of traffic and allow us to better maintain ecosystem health.

In particular we would like to see User-Agent Client Hints to indicate:

• If the traffic is coming from a WebView
• The source application that the browser session is coming from

[miketaylr]

Thanks, this seems related to #280

[jross1012]

Yup, definitely related to the topic of WebViews in the other issue, but as you mentioned you are exploring Client Hints for WebView here, I wanted to add some further support. Let me know if you prefer the conversation continue here or on 280

[miketaylr]

Thanks for adding support here. Let's continue over in 280. :)