Freezing User-Agent Strings

Chrome and other major browsers are about to freeze the User-Agent string, which has attracted widespread attention. This means that the User-Agent string still exists (appears in the request header and is accessible in JavaScript via navigator.userAgent ), but its functionality for detecting browsers/platforms/versions will decrease over time. Google officially explained that this move is to protect user privacy and prevent fingerprint recognition.

The front-end development field has always been recommended: Avoid User-Agent detection . Many websites use User-Agent detection incorrectly, resulting in more harm than good. The best way to avoid User-Agent detection is to test based on actual requirements .

Need to test whether the browser supports specific features? Test the feature directly, rather than relying on abstract concepts that assume that the browser should support the feature.

In JavaScript, testing many features is very simple, just check if their API exists:

 if (navigator.geolocation) {
  navigator.geolocation.getCurrentPosition(showPosition);
} else {
  console.warn("Geolocation not supported");
}

In CSS, you can use the @supports native mechanism:

 @supports (display: grid) {
  .main {
    display: grid;
  }
}

This can be detected by the JavaScript API that returns a Boolean value:

 CSS.supports("display: flex");

Not all web platform features are so easy to test, but usually do not require User-Agent probing. If you encounter difficulties, you can see if Modernizr provides the corresponding test, which is the gold standard for functional testing because it is well tested and handles edge cases that you may not foresee. Use the Modernizr library to get clear logical branches:

 if (Modernizr.requestanimationframe) {
  // Support } else {
  // Not supported}

If you really need to know the browser type, platform, and version, you can use User-Agent Client Hints (UA-CH).

For example, to obtain platform information, you can set the Sec-CH-Platform header in the request, which theoretically can be obtained in the response. This requires proactive requests for information, thereby avoiding problematic privacy fingerprint recognition problems. Similarly, there are Sec-CH-Mobile headers for detecting mobile devices, but this raises some questions: Who decides what a "mobile" device is? How should we make decisions based on this information?

It is usually desirable to understand browser, platform, and version information on the server side (sending different code in different situations), which is as important as the client side, but cannot be tested on the server side. The frozen User-Agent string should be able to last long enough for the server to be able to migrate to using UA-CH.

Jon Arne Sæterås expressed concerns:

I've been working in the mobile web field for over 15 years and I know that many websites, big and small, rely on device detection based on User-Agent headers. From a Google perspective, switching to UA-CH seems easy, but that's exactly where the teams driving this change don't understand its impact:

Device detection-based functions are crucial and widely used, not only in front-end code. Large software systems and their backend code rely on device detection, as does the entire infrastructure stack.

In my main code base, we do a small amount of server-side UA detection. We use a Rails gem called Browser, which exposes UA-derived information in a friendly API. I can write like this:

 if browser.safari?
  # Safari code end

We also expose the information in this gem on the client for use on the client. There are only a few use instances for the front-end and back-end, and these instances seem to be easily handled in other ways.

In the past, it was a bit tricky to pass front-end information back to the server in a way that was useful when the first page was loaded (because UA didn't know the viewport size and other information). I remember doing some very clever operations, loading a skeleton page, executing a small piece of JavaScript code to measure viewport width and screen size, then setting a cookie and forcibly refreshing the page. If a cookie exists, the server will have the required information and the skeleton page will not be loaded at all in these requests.

This is complicated, but the server can get the viewport width information on the server side, which is very useful for operations such as sending small screen resources (such as different HTML), which is otherwise impossible.

I mentioned this because UA-CH should not be confused with normal client prompts. We should be able to configure the server to send Accept-CH header and then let the client code whitelist the information to be sent back, for example:

<meta content="DPR, Viewport-Width" http-equiv="Accept-CH">

This means that the server can get this information from the client in subsequent page loading. This is a nice API, but Firefox and Safari don't support it. If both browsers are interested in UA-CH because of frozen UA strings, I wonder if it will be improved.

The above is the detailed content of Freezing User-Agent Strings. For more information, please follow other related articles on the PHP Chinese website!