search

WICG / ua-client-hints

Wouldn't it be nice if `User-Agent` was a (set of) client hints?
https://wicg.github.io/ua-client-hints/
Other
590 stars 77 forks source link

Scope of "user agent" in proposal #219

Open ronancremin opened 3 years ago

ronancremin commented 3 years ago

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.

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

@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:

miketaylr commented 1 year ago

Thanks, this seems related to https://github.com/WICG/ua-client-hints/issues/280

jross1012 commented 1 year ago

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 commented 1 year ago

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