When websites want to know what browser you're using, they often examine the "user agent", or "UA" string. This is a string that provides information about what browser and operating system you're using. Beginning with Chrome 11, we're making some changes to our UA string, which can affect website compatibility.

For reference, here is what the current (Chrome 10) UA string looks like on a few different platforms:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16

Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16

And in comparison, here are the UA strings for Chrome 11 on the same platforms:

Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.16 Safari/534.24

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.16 Safari/534.24

Let's break down the differences in detail. We've made four changes, two of which are Windows-specific:
  1. On Windows, the initial "Windows;" platform identifier has been removed. This was redundant with the subsequent OS version identifier, and makes us more compatible with Internet Explorer, whose UA string doesn't have this initial token.
  2. The "U" SSL encryption strength token has been removed. This token dates from more than a decade ago, when U.S. export laws limited the encryption strength that could be built into software shipped to various other countries; the valid values are "U" (for "USA" 128-bit encryption support), "I" (for "International" 40-bit encryption support), and "N" (for "None", no encryption support). These days, every browser ships with 128-bit SSL support everywhere, so it's not necessary to advertise it.
  3. On 64-bit versions of Windows, tokens have been added after the OS version. For 32-bit Chrome builds running on 64-bit Windows, we've added "WOW64". (WOW64" stands for "Windows 32-bit On Windows 64-bit" and is the name Microsoft gives its 32-bit compatibility subsystem.) In our source code, we've also added identifiers for 64-bit native builds, specifically "Win64; x64" for x64-based processors and "Win64; IA64" for Itanium systems. (However, we don't currently ship such builds, or have any immediate plans to.) These tokens are useful for sites that need to provide download links for native executables, and match what Internet Explorer uses.
  4. The locale has been removed. Web authors who want to know what languages a browser supports should use the HTTP Accept-Language header instead, which can supply multiple locales. In fact, websites that relied on the UA string locale probably had some very unhappy visitors, because Chrome always had a bug where the UA string locale was reported as "en-US", regardless of the user's desired locale(s)!
One more question remains: why are we making these changes now? Because websites tend to use common pieces of code to check all browsers' UA strings, it's important for browsers to stay in sync with each other. Mozilla has made the above changes in Firefox 4 (and more; see http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/ for details), which was released recently, and we wanted to change Chrome to match as soon as possible, to minimize the disruption to web authors.

As the changes above have trickled into our Canary and Dev builds, we've already found and fixed some problems in Google's UA string parsing libraries that have caused compatibility issues with Google sites (though not all of the affected sites have updated yet). If you see problems on other sites you think might be caused by the new UA string, try running Chrome with an alternate UA string using the --user-agent="<Put older UA string here>" command line flag. (You can double-check the UA string Chrome sends to websites by typing about: in your address bar and hitting <enter>.) If that fixes the problem, please let us know by filing a bug in our bug tracker at http://crbug.com/.

Posted by Peter Kasting, Software Engineer