Chrome 110 applies User-Agent reduction to Navigator properties + User-Agent header

[chrisdavidmills]

Summary

Chromium browsers support User-Agent reduction, which means that features such as the User-Agent HTTP header provide less-specific information in an effort to reduce their effectiveness for fingerprinting/tracking.

This PR adds data points covering User-Agent reduction to relevant web platform features that I know to be affected by the change.

Compat data sources:

• From looking at https://blog.chromium.org/2021/09/user-agent-reduction-origin-trial-and-dates.html, it looks like rollout of UA reduction to 100% of Chromium desktop users occurred in version 110, while the version was 113 for Chromium Android users. I asked @miketaylr about this, and he confirmed it to be correct.
• From looking at https://www.chromium.org/updates/ua-reduction/#applicable-platforms, it looks like Android WebView should be false

Another question for Mike: For all of these data points, I used https://wicg.github.io/ua-client-hints/#user-agent as the spec_url. Are there better spec URLs we can point to for these individual features?

This PR is part of the final set of privacy sandbox information to be added to MDN. Much of it is being removed, but this feature is stable and will be kept, so it should be added.

Test results and supporting details

Related issues

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[miketaylr]

From looking at https://www.chromium.org/updates/ua-reduction/#applicable-platforms, it looks like Android WebView should be false

That's correct, but we're trying to ship it in the future.

Another question for Mike: For all of these data points, I used https://wicg.github.io/ua-client-hints/#user-agent as the spec_url. Are there better spec URLs we can point to for these individual features?

I'd use https://compat.spec.whatwg.org/#ua-string-section

[chrisdavidmills]

From looking at https://www.chromium.org/updates/ua-reduction/#applicable-platforms, it looks like Android WebView should be false

That's correct, but we're trying to ship it in the future.

This is fine. We can follow up with another PR when it ships.

Another question for Mike: For all of these data points, I used https://wicg.github.io/ua-client-hints/#user-agent as the spec_url. Are there better spec URLs we can point to for these individual features?

I'd use https://compat.spec.whatwg.org/#ua-string-section

Great, thanks. I've updated it in the latest commit.

[miketaylr]

non-owner LGTM

[caugner]

Here's my suggestion, but before applying, I'd like to get a second opinion by @ddbeck, who might have a better idea.

Suggested change

	"User-Agent_reduction": {
	"__compat": {
	"description": "Provides limited information due to [User-agent](https://developer.mozilla.org/docs/Web/HTTP/Guides/User-agent_reduction) reduction.",
	"applies_UA_reduction": {
	"__compat": {
	"description": "Applies [User-agent reduction](https://developer.mozilla.org/docs/Web/HTTP/Guides/User-agent_reduction)",

[chrisdavidmills]

FWIW, this sounds good to me.

[chrisdavidmills]

The corresponding docs have just been merged, so I'd like to expedite adding this data.

I like your suggestion, so for now I'm going to make this update in the places it appears. If we want to improve it further, I am happy to do so in a follow-up PR.

[ddbeck]

This text is fine, but see my other comment on the whole structure of this feature: #28275 (comment)

[caugner]

@Elchi3 What do you think about this behavioral subfeature?

[ddbeck]

You didn't ask me so FWIW, I'm -1 on this as a feature or at least one that is "standard_track": true. The linked "spec" says:

This section serves as a descriptive record of the User-Agent patterns found in the so-called major web browsers

If it's descriptive, then it's merely documentation that does not specify anything. The spec doesn't actually say what the vendors must or should do, just what they have done as convention. I think this is comparable to linking to an MDN page in a spec_url.

I think this would be better as a note that says exactly what's being reduced. Something along the lines of:

From version 110, the reported browser version number is always in the pattern of X.0.0.0 where X is the major version number.

[chrisdavidmills]

Your logic here sounds reasonable, but downgrading this to a note troubles me a bit. I am documenting user-agent reduction and what it means to the values reported by the User-Agent HTTP header (and associated API features). In a couple of places, like here in the user-agent reduction guide I link to the browser compat table to let people know which browsers support this.

I worry that if it is just a note, it'll be fairly easy to miss the note.

[ddbeck]

Yes, I acknowledge this concern and I agree that is a bit obscure in a note. That said, maybe a change to the docs might help? My suggestion for the docs would be to be somewhat more aggressive in saying that the content of a UA string is not actually standardized (even if the string's format is) and, theoretically, could change at any time. The browser tables might tell you how and when UA strings have changed, but I would hate to suggest to a developer that they could or should rely on that information.

[chrisdavidmills]

Fair point. Could we do both?

I'd still like UA reduction to be called out in the compat tables (and let's face it, we'll need to add another data point if a browser decides to do a U-turn, whether the info is contained in notes or separate data points).

But I also see the value in updating the doc that the data point links to, to make it clearer that the UA string content is still not standardized.

[ddbeck]

Yeah, both is OK. I would still like these subfeatures to be standard_track: false though (it would be nice for web-features, where I don't think this is a thing that should get a meaningful computed status—it's not really a "feature" that developers can use—if anything, it represents the opposite).

[miketaylr]

I can also just update the spec to be normative if that makes your lives easier.

[chrisdavidmills]

If that means we can put standard_track: true, then I think it is a good idea.

It would still be good to update the docs, as previously discussed.

[ddbeck]

I did not think editing the spec would be an option. That would be ideal!