Some Google Chrome FUD

Posted on December 18th, 2009 | No Comments »

I’m all for raising privacy concerns, as long as it is done well and responsibly.  However, this morning I stumbled upon a gem of an article that tries to make claims about Google Chrome’s policies that simply aren’t true.  The sad thing is, the only research needed to deny the claims made in the article involves launching the browser and going to a URL.

In Chrome is not an Internet Browser and not open, but closed to the Internet’s Domain Name System, Scott Cleland, a self-proclaimed “prescient analyst,” claims that Chrome is “a gateway to Google’s datacenter to browse Google’s mirror copy of the Internet and track the user’s every movement.”  However, the two most incredible claims in the article are as follows:

  • “Google’s Chrome browser effectively eliminates the Internet’s Domain Name System (DNS) address bar where a user can directly go to [a] URL.”
  • “When one puts a URL, www.brand.com, into Google’s OmniBox search bar they do not go where they asked to go but to Google’s results page where Google can advertise against that brand without sharing the ad revenues with that brand, and where Google can offer competitors an opportunity to divert the user from their requested destination and to a competitor’s destination.”

The claims about Google’s “mirror copy” and bypassing the Internet Domain Name System are discredited point blank in a post from The Chromium Blog titled DNS Prefetching (or Pre-Resolving), which states “Google Chrome resolves domain names…using your computer’s normal DNS resolution mechanism; no connection to Google is used.”

That second bullet point, though, is the most easily discredited.  If you launch Chrome and type “www.starbucks.com” into the OmniBox, you are taken to www.starbucks.com.  You aren’t taken to a search results page and certainly don’t see any competitors offering their services along the way.  If you type only “starbucks” into the OmniBox, that’s a somewhat different story, but the article is making its claim about URLs, which is just flat out wrong.

Perhaps the most concerning fact among all these non-facts is that Scott Cleland is a consultant to Fortune 500 companies and an advisor to Congress! His bio states, “eight different Congressional subcommittees have sought Cleland’s expert testimony.”

He might as well have titled his article “Chrome bypasses the series of tubes.”

Tags: , , , , , , , , ,

Multi-process Web Browser Architectures

Posted on February 10th, 2009 | 2 Comments »

All the nonsense aside, now that it seems like multi-process architectures are beginning to surface in the world of web browser development, I thought it would be a good idea to dig in to the feature a bit and, at the very least, provide links to some useful information for those who are interested in what multi-process architectures mean for web browsers.

One of the more notable features included in the unveiling of Google’s Chrome was what Google refers to as “Crash Control.”  This feature allows for a “Windows Task Manager” type of interface for managing web browser processes.  Aside from providing the interface for explicit management of the running (or dying) processes, it is also meant to shield tabs within the same running instance of the browser chrome (for lack of a better word) from any issues arising in other concurrently running tabs.  In essence, when you accidentally load a web page in one tab that was developed using Microsoft Word, you don’t have to worry about the severe code bloat of the page bringing your other tabs to a screeching halt.  Or if the JavaScript of one page goes off into la-la land, you won’t necessarily lose any of the other non-offending tabs.

Months after this feature was unveiled in Chrome, it was announced as a feature of Maxthon under the name “The Isolator:”

Maxthon 2.5.1…includes a feature called The Isolator that separates the functions of each Web tab from all other tabs and other parts of the browser. The Isolator protects other tabs from also becoming frozen because a single unresponsive tab is monopolizing a computer’s resources.

Though it certainly wasn’t the first implementation (despite what MaxthonGuy might want you to believe), The Isolator is one of the first official implementations of a multi-process architecture among the web browsers that actually show up on the Browsersphere radar.  Unlike Chrome’s “Crash Control,” though, The Isolator is still considered to be “in advanced beta.”

Other than the press release, I wasn’t able to find much on Maxthon’s actual implementation.  On the other hand, there has been plenty of coverage on Chrome’s implementation.  Marc Chung, for example, does an excellent job of explaining Chrome’s process model.  He even goes so far as to show you how you can control the type of process model used by Chrome at launch time.  He also points to another interesting article from Chromium Blog that explains why Chrome uses the multi-process architecture and why the architecture is more relevant today than it was when web browsers were first created, and refers to a publication from which Chrome’s process model was derived.

Though the multi-process architecture has been heralded by many web users, it isn’t without its downsides.  Google Chrome Memory Usage – Good and Bad explains the trade-offs of separating tabs into their own distinct processes, including the following:

While the multi-process model provides clear robustness and performance benefits, it can also be a setback in terms of using the absolute smallest amount of memory. Since each tab is its own “sandboxed” process, tabs cannot share information easily. Any data structures needed for general rendering of web pages must be replicated to each tab.

For more information on Chrome’s implementation of the multi-process architecture from both a developer’s and end user’s perspective, I recommend checking out the following links:

And finally, here are some other multi-process-related links related to web browsers other than Maxthon and Chrome:

Tags: , , , , , , , , , , , , ,