What’s In Google Chrome’s User-Agent String

Friday, 12th September 2008 in Development, Technology by Simon | 1 comment

With the advent Google Chrome there has been a lot of media coverage regarding the browser’s uptake and how it will compete with Internet Explorer, Firefox and Safari. This is where the User Agent becomes most valuable. It can be used in analytics software to determine the browser share and consequently aid the development of the website.

But what is a User Agent? A User Agent is the client application used with a particular network protocol; the phrase is most commonly used in reference to those which access the Web. Web user agents range from web browsers and e-mail clients to search engine crawlers (spiders), as well as mobile phones, screen readers and braille browsers used by people with disabilities. When Internet users visit a web site, a text string is generally sent to identify the user agent to the server. This forms part of the HTTP request, prefixed with user-agent: and typically includes information such as the application name, version, host operating system, and language. Bots, such as web crawlers, often also include a URL and/or e-mail address so that the webmaster can contact the operator of the bot.

By simply typing about:version into Chrome’s address bar you will be presented with the following information:

Google Chrome
0.2.149.29 (1798)
Official Build
Google Inc.
Copyright © 2006-2008 Google Inc. All Rights Reserved.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.29 Safari/525.13

As you can see Chrome’s version information provides limited detail about the browser. The last line is the important one. It is the HTTP User-Agent header:

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

If you know the RFC 2616 specification on the HyperText Transfer Protocol — which incidentally, I gladly don’t — you would know that the User Agent, or more formally, product token, should be short and to the point:

Product tokens SHOULD be short and to the point. They MUST NOT be used for advertising or other non-essential information. Although any token character MAY appear in a product-version, this token SHOULD only be used for a version identifier (i.e., successive versions of the same product SHOULD only differ in the product-version portion of the product value).

Clearly this isn’t the case! One of Google’s reason’s behind creating the Chrome browser was to start afresh. It would have therefore been truely amazing if they had made the string simply Chrome/0.2.149.27.

Unfortunately, browser sniffing makes an ever-growing UA string the path of least resistance for browser vendors.

So, what does Chrome’s User Agent string actually mean:

  • Mozilla/ – This means that browser has the kind of capabilities that Netscape 1.1 had compared to Mosaic and Lynx.
  • 5.0 – This means that the browser engine is from the post-Browser War Web Standards era as opposed to being from the Browser War era.
  • (Windows; – This means that general windowing system flavor the browser runs on is Windows (as opposed to, for example, Apple and X11).
  • U; – This means that the browser has at least the level of cryptographic capability / encryption strength that U.S. versions of browsers had in the late 1990s.
  • Windows NT 6.0; – This indicates the operating system the browser is running on. In this instance, the browser is running on Vista.
  • en-US) – This indicates the user interface language of the browser (U.S. English in this case). This may be used to choose between different content languages even though HTTP has a different header for that purpose.
  • AppleWebKit/ – This indicates that the engine of the browser is WebKit as opposed to being Gecko. Developers should not do user agent sniffing as a rule, but if they still do, this is what they should be sniffing.
  • 525.13 – This is the WebKit version from which Chrome branched its copy. Site admins could use this to detect old versions with known bugs.
  • (KHTML, like Gecko) – This introduces the substring Gecko into the UA string while pointing out to human readers that Webkit was forked from KHTML. Without this substring, Chrome might be put in the same category as IE and Netscape 4.
  • Chrome/ – This string identifies the browser as actually Google Chrome.
  • 0.2.149.27 – This is the Chrome version. This could be used to detect old versions with known bugs.
  • Safari/ – This means that the browser is like Safari as opposed to being like Firefox.
  • 525.13 – This just repeats the WebKit version in order to have some version but not the irrelevant Safari.app version.

More Than Just Hot AIR – Single Site Browsers

Wednesday, 9th April 2008 in Development, Technology by Simon | No comments

Adobe AIR LogoAdobe Integrated Runtime is more than just hot air, it traverses the previously unexplored space that exists between the Web and desktop applications.

Up until very recently, the void between the Web and the desktop seemed like a schism that could not be crossed. But since AIR’s 1.0 release in February this year, a whole host of other applications are emerging to compete with AIR in the single site browser space.

Although AIR is very new, the product is remarkably mature with the integration of the excellent opensource WebKit browser engine for rendering HTML and JavaScript, the SQLite database engine for embedded database functionality and of course, Adobe’s Flash player for development of Flash-based Rich Internet Applications. Because of this flexibility, the learning curve faced by developers is almost non-existent, they simply have to get to grips with the AIR API.

What is all the fuss about?

Delving into the AIR API, your application will have the ability to detect whether it is currently the active window or connected to the network. You can access the file system, allowing you to read and write files, access other datasources, tap into the native menu options or interact with almost any aspect of the operating system in a way familiar to common desktop applications. This functionality is available regardless of the architecture on which it is installed. Therefore AIR applications will work similarly when installed on a Windows PC or Mac, and soon on Linux machines as well.

AIR is much, much more than a single-site browser — it’s a cross-platform runtime environment and the distinction is significant.

The ability to run applications built on AIR on almost any machine, on- and offline, sets it apart from any other offering currently out there or in development. For example, Google Gears is restricted to AJAX applications, whilst Mozilla Prism isn’t much more advanced than a cut-down version of Firefox, with no offline capabilities yet.

Who else has entered the race?

As mentioned, a significant entry is Mozilla’s Prism, however, Pyro for Linux and Bubbles and Fluid for Mac are clever little tools for packaging up an existing website and presenting it as a standalone desktop application.

Mozilla Prism

Mozilla Prism LogoPrism, previously known as WebRunner is a product in development which integrates web applications with the desktop, allowing web applications to be launched from the desktop and configured independently of the default web browser. It is commonly used with Google AJAX Applications, such as Gmail and Google Docs.

Prism is part of an experiment by Mozilla designed to “bridge the divide in the user experience between web applications and desktop applications”. Essentially, Prism will allow you to create a desktop-like application out of individual websites. These site-specific applications are a growing trend and a trend heavily marketed by, not only Adobe, but now Mozilla, as ‘the future’.

While traditionally users have interacted mostly with desktop applications, more and more of them are using Web applications. But the latter often fit awkwardly into the document-centric interface of Web browsers.

In its current form, Prism doesn’t have the ability to function as a desktop application without access to the Internet, but Mozilla says it is “working to increase the capabilities of those apps by adding functionality to the Web itself, such as providing support for offline data storage and access to 3D graphics hardware.”

More details can be found on the Mozilla Prism website.

Pyro Desktop

Pyro LogoPyro Desktop is a new type of desktop environment for Linux built on Mozilla Firefox. Its goal is to enable true integration between the Web and modern desktop computing. Pyro was announced during GUADEC 2007 and is developed by Alex Graveley and Chris Toshok.

More details can be found on the Pyro Desktop website.

3D3R Bubbles

Bubbles LogoBubbles is a desktop application that allows you to work with your web resources in the way you want to work with them.

The Bubbles application window, known simply as a Bubble carries the web resource almost like a web browser does. Since the Bubble has advanced browser capabilities there’s an advanced control device for it — the Bubble seed — an XML file called Smart Bubble. It defines the properties — the whats & the hows — of its Bubble window. The Smart Bubble contains the information about what Bubble will load, how it will look on the desktop and what capabilities it will have, etc. So it goes from the Smart Bubble into a grown Bubble that lives on your desktop, accessible from the system tray.

More details can be found on the 3D3R Bubbles website.

Fluid App

Fluid LogoFluid is a way to create Site-Specific Browsers SSBs to run each of your favorite WebApps as a separate desktop application. Fluid gives any WebApp a home on your Mac OS X desktop complete with Dock icon, standard menu bar, logical separation from your other web browsing activity, and many other goodies.

Fluid includes optional Tabbed Browsing, built-in Userscripting (aka Greasemonkey/GreaseKit), RSS/Atom Feed detection, a JavaScript API for setting dock badges, showing Growl notifications and adding Dock Menu Items, optional bookmarks, optional browsing to urls outside the SSB “home” domain, Dock badges and Dock menus for Gmail, Google Reader, Facebook, Flickr, and Yahoo! Mail, auto-software updates via the Sparkle Update framework, and custom SSB icons.

More details can be found on the Fluid App website.

Web Standards Project Expands Collaboration with Adobe

Saturday, 15th March 2008 in Development, Technology by Simon | No comments

The Web Standards Project (WaSP) is to expand its scope of collaboration with Adobe to advance web standards. Having successfully completed its initial goals for assisting Adobe’s Dreamweaver team in supporting Web standards, the Web Standards Project’s Dreamweaver Task Force will be renamed the Adobe Task Force to reflect its widened scope. The Adobe Task Force will collaborate with Adobe on all of the company’s products that output code or content to the Web, and will continue to advocate compliance with Web Standards and accessibility guidelines by those who use Adobe’s products to design and build Web sites and applications.

You can read the full press release on the Web Standards Project website.

Widening the collaboration between standards experts, who are also product experts, and Adobe is an exciting step forward in the maturation of the Web. This will hopefully lead to full standards support in not only Adobe-based products such as Dreamweaver and AIR, but leading browser and web editor suppliers such as Mozilla, Microsoft and Apple.