-
Notifications
You must be signed in to change notification settings - Fork 79
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
GREASE algorithm is underspecified #146
Comments
Good point, e.g., if Safari always uses 3 semicolons in its grease values, but Chrome always uses 2, at some point developers will figure that out and fork on behavior (if history teaches us anything).
I think the GREASE model will have failed if UAs have to emulate not only "real" branding and version inside the UA-CH list, but also the arbitrary values. But I also agree that coming up with these values could be more concrete to avoid this situation. |
I agree that GREASE would have failed in this circumstance; this proposal is intended to reduce the odds that it would fail in this way. |
This is handled in the "create an arbitrary brand" algorithm.
Issue #146 - Specify GREASE algorithms (aka arbitrary brand and version number)
Hey @othermaciej, I've rewritten the GREASE algorithms and would appreciate any feedback you have: See https://wicg.github.io/ua-client-hints/#create-ua-list-section and |
Hmm, no, I think those changes still leave the algorithm under specified in exactly the way stated in the original issue. I said:
https://wicg.github.io/ua-client-hints/#create-an-arbitrary-brand starts with this step:
All the steps after this seem to be deterministic, but there it’s unspecified how to generate this initial string other than it must meet some constraints. It’s also not stated whether the string should be different every single time, or should be fixed forever per UA, or should change less often than that. Given this, I still think it’s the case that:
If the step above was defined to use a more specific algorithm (such as even saying it should be use a PRNG, generate strings equally distributed from length M to N for some values M and N, and should choose any character from the set of ascii alpha and space with equal likelihood, that probably would be specific enough? If Chrome does something fancier than what I described, then it’s probably better to document that in the spec than to require others to reverse engineer it down the line. For example, are strings with leading or trailing spaces excluded? Is space more likely than other characters? Is there a cap on the number of spaces? These details seem potentially significant. |
I’m not sure how to reopen this issue or if I even have the power to do so. |
I'm happy to re-open (thanks for the additional feedback, will go through it in a couple of days). |
The create brands algorithm requires adding arbitrary values, but does not define what these should be, how they should be generated, or how often they should change. If UAs use very different arbitrary values, it's possible sites will intentionally or inadvertently start to depend on a particular value or set of value. Since UAs may need to emulate the values of other UAs for compatibility reasons, this may end up requiring reverse engineering of the arbitrary values.
The text was updated successfully, but these errors were encountered: