Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

paulirish
Copy link
Member

@paulirish paulirish commented Sep 9, 2025

This means we don't need to update the UA every few months. It'll always reflect the milestone of the host browser you're using.

If you supply a custom UA via configuration, we'll still use it BUT tweaked to use the matching milestone. After landing this PR, there's no way to force a specific chrome version in the emulated UA.

ref #14917. This has been an idea for a long while now.

@paulirish paulirish requested a review from a team as a code owner September 9, 2025 19:37
@paulirish paulirish requested review from connorjclark and removed request for a team September 9, 2025 19:37
*/
async function matchHostUAVersion(session, userAgent) {
const {milestone} = await getBrowserVersion(session);
const tweakedUA = userAgent.replace(/(Chrome\/)[\d.]+/, `$1${milestone}.0.0.0`);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason to not include the full version number?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

chromium version number is MILESTONE.MINOR.BRANCH.PATCH.

  • minor is always 0, afaik
  • BUILD must get updated whenever a release candidate is built from the current trunk. The BUILD number is an ever-increasing number representing a point in time of the Chromium trunk.
  • PATCH must get updated whenever a release candidate is built from the BUILD branch.

then there's UA reduction
https://www.chromium.org/updates/ua-reduction/
https://privacysandbox.google.com/blog/user-agent-reduction-android-model-and-version

so now the useragent (in navigator and request headers) gets milestone.0.0.0 now.

however if you request UA client hints you can get the non-reduced minor.branch.patch. (apparently)


It's actually correct for us to ensure the UA we emulate (which ends up in navigator and requestheaders) has .0.0.0 because regular chrome does. so any more data would be a LH fingerprint.

i'm indirectly pitching here that we give reduced version numbers to clienthints. if we didn't, we'd either 1) be creating "invalid" version numbers or 2) we'd have to make them legit which requires a bunch of chromium version number data.. seems like a pain.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

t's actually correct for us to ensure the UA we emulate (which ends up in navigator and requestheaders) has .0.0.0 because regular chrome does. so any more data would be a LH fingerprint.

sg

i'm indirectly pitching here that we give reduced version numbers to clienthints

I don't think we need to do anything. Chrome will decide what level of detail to give when users request client hints (see https://developer.mozilla.org/en-US/docs/Web/API/NavigatorUAData/getHighEntropyValues).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants