You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although it is unclear why this would be a good idea (#21), if we assume it's desirable, I worry that the current design does not do enough to encourage web developers to treat the UA list as a set. Unless early browser implementations follow this optional part of the spec, I imagine we'll see a lot of parsing code for Sec-CH-UA which assumes there's only a single value. (See also #7 (comment).) This will effectively prevent any later browser from ever implementing the optional steps in the spec, because doing so would break server assumptions.
Additionally, the JS API always returns a single string, not a set.
If the intention is to encourage treating the UA as a set of possible UAs, then I think you need to make changes such as:
Changing Sec-CH-UA to a structured header list of strings, instead of a structured header string.
Potentially mandating, or at least strongly suggesting, that browsers always include >= 2 items in the list. (Especially early implementations.)
Change the JS API so that getUserAgent() returns a promise for an array of NavigatorUADatas, or possibly change NavigatorUAData's platform and version members to be arrays instead.
The text was updated successfully, but these errors were encountered:
yoavweiss
changed the title
Stronger encouragement on set of UA strings
UAs SHOULD have more than a single brand value (Was: Stronger encouragement on set of UA strings)
Jan 27, 2020
https://github.com/WICG/ua-client-hints#should-the-ua-string-be-a-set indicates an idea of there being a set of user agents.
Although it is unclear why this would be a good idea (#21), if we assume it's desirable, I worry that the current design does not do enough to encourage web developers to treat the UA list as a set. Unless early browser implementations follow this optional part of the spec, I imagine we'll see a lot of parsing code for Sec-CH-UA which assumes there's only a single value. (See also #7 (comment).) This will effectively prevent any later browser from ever implementing the optional steps in the spec, because doing so would break server assumptions.
Additionally, the JS API always returns a single string, not a set.
If the intention is to encourage treating the UA as a set of possible UAs, then I think you need to make changes such as:
getUserAgent()
returns a promise for an array ofNavigatorUAData
s, or possibly changeNavigatorUAData
'splatform
andversion
members to be arrays instead.The text was updated successfully, but these errors were encountered: