Posted by: reformedmusings | September 3, 2008

Google Chrome revisited

I recorded my initial thoughts on Google Chrome last night. Today, I read through Google’s comic book explanation of the browser, its design and operation. In doing so, I learned some things that changed my opinion of Chrome a bit. In particular, the nature of tabs, their Java V8 engine, and the security sandbox provide power and protection not visible to the naked eye.

Opening a new tab in Chrome

Opening a new tab in Chrome

Before I get into all that, I mentioned last night that opening a new tab in Chrome presents a browsing and bookmark history. Google’s thought seems to be that most folks frequent particular locations. So, a new tab presents your 9 most frequently visited sites, your most recently saved bookmarks, recently closed tabs, and recent search locations. You can see this personalization approach illustrated above. Having built enough of a history with Chrome to see this work, I can see its benefits. Firefox does this both through its bookmark toolbar and the ability to put folders of frequently-used bookmarks on the bar. I have a number of sites that I visit every morning, so I put them in a Home Pages folder which can open all of them at once. While Chrome cannot do that, it can present these pages for quick access. Like I said last night, this is clever but Firefox’s method works better for me. I rarely create a new “blank” tab but navigate directly from the handy bookmarks on the toolbar. YMMV.

I also learned more about the combination address/search bar, which Google calls the Omnibar. You can search common sites like Amazon using the bar. For example, if I type “ama” and http://www.amazon.com appears in the offered list, I highlight Amazon and then hit tab. Another search sub-bar comes up for the user to type the desired search term. Hit Enter and the tab goes to Amazon with the search result. Pretty cool.

Now to the main topic.

Tabs in Chrome are different structures than tabs in Firefox or Internet Explorer 7 and 8. In FF and IE, tabs are parts of the single, overall browser process. They share the memory and some information from other tabs. This approach provides efficiencies in memory use and execution. However, because all tabs are part of a larger process, when something in one tab crashes (usually due to Flash in Firefox), the entire browser crashes. Been there, done that. Also, since Java is not multi-threaded, when a Java execution in one tab bogs down, the entire browser bogs down and must wait for that tab’s execution to pause or end.

In Chrome, each tab is its own process, almost like its own browser. They each have their own omnibar. Tabs do not share execution or data across each other. This provides three benefits: 1) even though Java isn’t multi-threaded, multiple process (e.g. Java in separate tabs) CAN execute in parallel, so one tab cannot bog down the entire browser; 2) if one tab crashes, the entire browser does not crash; and 3) since tabs do not communicate, data cannot be stolen across tabs. Chrome executes faster as a result of 1). It provides a more robust browsing experience due to 2). Although 3) isn’t normally a huge concern in Firefox, it enables a sandbox security approach which will be discussed below.

Google has gone a step further in that each plug-in also runs in a separate process, even separate from its host tab. This seems excessive on the surface, but it does have an advantage in Google’s security scheme which I’ll discuss below.

Chrome's task manager

Chrome's task manager

Since each tab and plug-in is its own process, each should theoretically be open to separate process monitoring. Google has included just such a tool in Chrome, and not surprisingly calls it a task manager and accessed through the Developer menu item. As you can see above, it lists all the tabs with their contents and all the active plug-ins, all with their CPU, memory, and network resources. Highlighting a process enables the End process button to kill that tab or plug-in. I find this very clever and potentially very helpful. If you need even more process information, just click on the “Stats for nerds” link on the bottom left:

Stats for nerds

Stats for nerds

I have to say that I like this approach to tabs. As I opined last night, it does use more memory because common elements are not shared within the browser. Google claims that this additional memory use is only true at first, but that the longer a browser runs and the more tabs are closed, the more small pieces of memory are wasted because they are too small to be reallocated or their pointers are lost. Of course, simply reloading the browser instantly cures this. Whether Chrome will routinely reap this long-term memory benefit or not, the additional memory overhead seems a worthwhile tradeoff for the stability and speed improvements.

Second, Google had their Denmark office write their Java V8 virtual machine completely from scratch. This enabled them to make some truly outstanding improvements to their Java engine. As Google points out, Java was never originally intended for the large-scale application use which it now sees. By starting with a clean sheet of paper, the Denmark group was able to design a Java VM around more challenging tasks. Instead of reinterpreting the same code over and over again like the old BASIC used to do, V8 actually compiles Java code to reuse (although Google doesn’t use the term “compiled”, V8 turns Java code into machine code specific to your processor). It also created “hidden classes” so that objects could be dynamically optimized. This is old hat to object oriented programmers, but Java was not originally designed with object classes.

Additionally, V8 handles memory differently. Older Java implementations don’t track memory pointers. This makes it difficult to precisely return unused memory back to the system heap. Plus, periodically looking for these unused blocks is time consuming. V8 keeps track of its memory pointers so it always knows which memory blocks should be returned to the system. This cuts the “housekeeping” overhead time down by several orders of magnitude.

The net result is a very, very fast and efficient Java implementation. Plus, they made V8 open source so others could benefit. I’d personally like to see this Java VM become the standard in both desktop application support and web browsers. Hopefully Mozilla picks it up for Firefox 4, or maybe even 3.2.

Lastly, I opined last night that Chrome apparently didn’t have a robust security apparatus. I was right that it wasn’t apparent, but Chrome does in fact have an interesting security approach. Google leveraged each tab’s process isolation to create a security sandbox for each. It limited rendering activity inside each tab to that tab’s process memory alone. Rendered code cannot read or write files on your system or make changes to your system. Each tab is limited to its own space. Except…

Plug-ins are not currently written with this concept in mind. So, they cannot be contained within a tab’s process space. That’s why Google broke out plug-ins to separate processes. This separation keeps the tab securely limited to its sandbox with only the plug-in outside of it. This isn’t a perfect solution, but it is a good compromise given that Google doesn’t write the plug-ins.

As Google points out, the tabs’ sandbox renders keyboard and mouse logging impossible, as well as data theft from your hard drive or changing the system settings to run malware on startup. Communication in or out of the sandbox must be approved by the user. If you wind up on a site with malware, simply close that tab and the problem is resolved. The malware was limited to that tab’s memory space, so when the tab is closed, the malware is gone. The sandbox boundaries are controlled by user preferences. Users will have to ensure that their settings provide sufficient security for their purposes.

However, one of the most prolific sources of Flash and hidden code executing in your browser is web advertising. Bots and other malware can be distributed through flash and its supporting Java code. As I opined last night, I believe that Google will be reluctant to provide or support a capability to limit or eliminate ads from the browsing experience since ads provide its life blood. Perhaps the security implications will override this, or maybe someone outside Google will write an extension to eliminate the ads while browsing. The ad loophole will prevent many from seriously considering Chrome for their full-time browser.

I like this sandbox approach, but the plug-ins leave a gaping security hole. Firefox extensions that control flash and script execution, etc., provide the next best alternative to a sandbox. Whether plug-in makers will bother conforming to Google’s wishes in regards to the sandbox remains to be seen. I’d like to see add-ons or built-in capability for the user to control add-on and even browsing security behavior, preferably with one or two clicks for each element.

Overall, I am impressed by Google’s efforts with Chrome. Reading through their explanation of its design made a big difference in how I view Chrome. It seems to be the most innovative browser approach extant. Java V8, in particular, should be a boon to the community. I applaud Google for making Chrome and V8 open source in the best tradition of the Internet.

Now what we need is a Linux version…

Advertisements

Responses

  1. […] – bookmarked by 4 members originally found by shehopeso on 2008-10-04 Google Chrome revisited https://reformedmusings.wordpress.com/2008/09/03/google-chrome-revisited/ – bookmarked by 3 members […]


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: