Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider collaborating with UACH on standardized "enum" values #174

Open
domenic opened this issue Feb 1, 2022 · 1 comment
Open

Consider collaborating with UACH on standardized "enum" values #174

domenic opened this issue Feb 1, 2022 · 1 comment

Comments

@domenic
Copy link
Member

domenic commented Feb 1, 2022

https://wicg.github.io/ua-client-hints/ has gone further than https://compat.spec.whatwg.org/#ua-string-section by trying to lock down some "enum" values. Namely:

It might be worth having a common foundation, probably living in the Compat Standard, which these two share. I'm envisioning something like:

Recommended platforms

Platform name UA String <platform> UA string <oscpu>
Windows Windows NT 10.0 Win64; x64
...

and then the UACH spec says to use the platform name, and the UA string part of the Compat spec says to pick a platform row and use the corresponding <platform> and <oscpu> columns.

The main thing here is not to waste work on stuff that we think will not exist in the UA string in the future. But I think platform is likely to stay, as is the mobileness bit.

domenic pushed a commit to whatwg/html that referenced this issue Mar 30, 2022
navigator.platform was permitted to return the empty string due to a privacy-motivated spec change in ecefa6e.

Since 2008, the understanding of changing things like this for privacy has evolved from returning special privacy values to returning a value that is already commonly returned for non-privacy reasons. Therefore, change the spec not to say "the empty string" but to permit returning a string commonly returned on another platform.

Additionally, change the examples to be from the set of values given at https://www.chromium.org/updates/ua-reduction/ to avoid suggesting more-identifying and potentially-less-compatible values. But, for now, avoid actually constraining the permitted values to a reduced set.

Further work on constraining these values is tracked mostly in https://github.com/whatwg/compat; see especially whatwg/compat#174.
@miketaylr
Copy link
Member

Thanks for the suggestion, I think it's a good idea. I'll try to find the time to tackle this in Q2 (not putting a year, just in case™).

miketaylr added a commit that referenced this issue Apr 29, 2022
Similar to Safari, this differentiates between mobile and
desktop. In #174, we can further improve this by defining
the allowed values for <platform> and <oscpu>, etc.

Closes #171
miketaylr added a commit that referenced this issue May 2, 2022
* Fix Firefox UA pattern

Similar to Safari, this differentiates between mobile and
desktop. In #174, we can further improve this by defining
the allowed values for <platform> and <oscpu>, etc.

Closes #171

* Properly scope both <deviceCompat>s
mfreed7 pushed a commit to mfreed7/html that referenced this issue Jun 3, 2022
navigator.platform was permitted to return the empty string due to a privacy-motivated spec change in ecefa6e.

Since 2008, the understanding of changing things like this for privacy has evolved from returning special privacy values to returning a value that is already commonly returned for non-privacy reasons. Therefore, change the spec not to say "the empty string" but to permit returning a string commonly returned on another platform.

Additionally, change the examples to be from the set of values given at https://www.chromium.org/updates/ua-reduction/ to avoid suggesting more-identifying and potentially-less-compatible values. But, for now, avoid actually constraining the permitted values to a reduced set.

Further work on constraining these values is tracked mostly in https://github.com/whatwg/compat; see especially whatwg/compat#174.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants