Chrome Performs Very Well at Hacking Competition

browsers At the CanSecWest conference each year they conduct a hacking competition (pwn2own).  Security professionals compete to get malware onto a machine faster than anyone else.  The contestant can pick the browser that they wish to attack.

At this year’s conference, every major browser including IE8, Firefox, and Safari were all hacked over a 3 day period.  The only browser which was not hacked was Chrome.  One of the winners of the contest had some interesting things to say about why Chrome was not hacked.

Chrome’s “sandbox” is not an accident; it was designed for this case.  Each web page runs in a renderer process, and that process has no privileges on the OS, so it cannot write to disk or talk to the network.  With all of the browsers being hacked, it’s fair to assume that hackers will find flaws in any browser.  Avoiding flaws is key, but the sandbox ensures that those flaws are contained to some degree.  It is much harder to do persist damage to the machine after the flaw has been exploited because the process can’t touch the network or disk.  While IE8 also uses multiple processes, it does not implement a sandbox, so it is vulnerable in similar ways to single process browsers.  Don’t get me wrong, the sandbox is not perfect, I’m sure someone will find an exploit.  But it does make Chrome harder to break into.  Plugins will be a vulnerability, as they cannot yet operate in a sandboxed environment (Flash, for instance, requires access to the OS in order to run).

More news:
IE8, Firefox, Safari Owned by 0-Day Vulnerabilities, Chrome Survives Intact
Chrome last browser standing after day one of Pwn2Own
Internet Explorer 8 Gets Hacked, Already

Javascript Faster and Slower

Several articles have been written about the latest in Javascript performance.  Here are some interesting points:

DownloadSquad:
“Chrome 2 beats Safari 4 like a rented mule”

CNet:
“The upshot: Chrome wins both tests handily, with Firefox in second place on Sunspider and Safari in second place on the V8 benchmark.”

Also interesting is that Firefox’s Tracemonkey Javascript engine may be falling behind.  Numerous articles have opined that Firefox 3’s ship date is in jeopardy due to Tracemonkey related bugs.  But new data also confirms that Javascript in Firefox 3.1 beta 3 is markedly slower than Firefox 3.1 beta 2.  The performance loss is palpable – Firefox lost 20% in performance from beta 2 to beta 3.  The problem may be that as the bugs have piled up in Tracemonkey, the fixes to ensure stability have eroded the performance gains initially boasted by the team.  It will be interesting to see Firefox’s final performance numbers when it ships out of beta.

JavaScript Private Member Variables

In JavaScript, nothing is private, right?  Sort of.  One mechanism for creating classes with hidden member variables is to leverage Javascript’s lexical scoping.  Lexical scoping means that a function’s scope is defined where it is declared, rather than where it is executed.

Here is a quick example which effectively creates a private member called “private_”:

function PrivateClass() {
  var private_ = 0;
  this.increment = function() { return ++private_; };
  this.decrement = function() { return –private_; };
}
var instance = new PrivateClass();

A question which comes to my mind is whether or not this is fast.  After all, if you’re going to have an object with methods, wouldn’t using prototypes be better?

Here is an alternate implementation:

function PrivateClass() {
  this.private_ = 0;
}

PrivateClass.prototype.increment = function() {
  return ++(this.private_);
}

PrivateClass.prototype.decrement = function() {
  return ++(this.private_);
}

In this implementation, private_ is no longer private and can be accessed externally.  However, the constructor for PrivateClass() is much simpler as the methods are assigned to the prototype once, and then reused.

So I wrote a quick benchmark to test creation of these objects and access time of these objects (these operations are fast, so I measured 20,000 iteration loops).  Using Chrome 2.0, here are the results:

creation time access time
via Lexical Scoping 122.2ms 0.18ms
via Prototype 11.3ms 0.18ms

So, if you are creating a few objects, and using them for a long time, either approach works well.  But, if you are churning through many objects over time, using lexical scoping to hide private members is substantially more expensive than using prototype methods on an object.

Chrome Multi-Process Performance

One of the features in Chrome is that it is a multi-process browser.  To most people, that doesn’t mean much.  I could tell you that using multiple processes improves security, performance, and memory management, but you’ll probably yawn.  Here is my attempt to look at one angle of multi-process performance with a demo.

 

Process Priorities

Operating Systems like Microsoft Windows generally support the notion of running different processes at different priorities.  Because Chrome isolates each “tab” into its own process, Chrome can tell the operating system which tabs are important and which are less important.  When you switch to a tab, Chrome automatically tells the operating system to lower the priority of the tab which moved to the background, and raise the priority of the one which moved to the foreground.  Other browsers can’t do this because those browsers run all tabs run in a single process.

Why does this matter?  There are two primary reasons. 

First, when you have many tabs open, the tab you are actively working with will get the most CPU resources.  A background tab can continue to run, but it will never slow down your foreground work – because the operating system ensures that the higher priority processes always run first, even if it means starving the background process.  This keeps your browser responsive and snappy no matter how many tabs you’ve opened.

Second, by lowering the priority of unused tabs, Chrome is being nicer to other applications.  Whether your other application is Outlook, Word, Firefox, or even a game, Chrome’s background tabs cannot slow down those other applications because Chrome has intentionally yielded its priority to other applications.  Chrome is the only browser which does this.  Ironically, by making Chrome’s background tabs run slower, it makes your system faster!

 

Quick Demo

Let’s run Chrome 1.0.  In one tab, I’m running the v8 benchmark.  In another tab, I’m running my CPU spinner page which eats up lots of CPU.  If these two pages run concurrently, the browser’s score on the benchmark will be lower because the browser is doing two things at once.  However, if Chrome properly lowers the priority of the background task, then the benchmark score should be unaffected.  I’m running these tests on my laptop- a single processor machine.

First, here is the V8 Benchmark for Chrome.  Chrome scored a 1333 in this quick run when nothing else was running.

chrome1

Next, we run the CPU spinner in a background tab, and run the benchmark in the foreground.  Chrome’s performance is unaffected by the background work, and in this run scores 1345.

chrome2

Let’s try the same thing with Firefox 3.

First, a dry run for the benchmark.  Firefox scores 165 on this test.

ff1

Now, with Chrome running the CPU spinner in the background, Firefox is not impacted.  Firefox still gets a score of 157, even though Chrome is using 100% of the CPU in a background process!  Priorities actually work.

ff5

Finally, lets see what happens if Chrome didn’t do this.  This time, we’ll let Firefox run the background tab and see if it effects Chrome’s benchmark score.  Sure enough, Chrome’s score drops to 762 (it was 1333).  Firefox degraded Chrome’s performance by nearly 50%.

ff4

 

Other Performance Benefits

Startup performance is also enhanced with this feature – especially when you startup with multiple tabs.  In this case, Chrome will lower the priority of the background tabs, and only the foreground tab will have high priority.  You get the foreground tab first (which is what you want), an the secondary tabs fill in as CPU becomes available.

 

Conclusion

When single process applications like Firefox, Internet Explorer or Safari run web pages in background tabs, they can reduce your foreground application performance by as much as 50%!  However, because Chrome uses background process priorities, it has almost zero impact on foreground applications.  This lets the user get his work done and not worry that idle applications are in the way.

All part of what you get with a multi-process browser.

Chrome Channel Changer

I get a lot of questions about the latest releases of Chrome which are available and how to get it.  Chrome releases a little differently from other software.

If you just download the default version of Chrome, you’ll get the “stable” version, and you’ll automatically be kept up to date with the latest “stable” releases.  New releases will come out only when the software is ready – it may be several months between versions.

If you want to see features more quickly, you can switch the to “beta” version.  Again, you’ll be automatically kept up to date with the latest beta versions.  These versions are generally stable (we constantly run a plethora of tests to keep code in reasonably good shape), but this is less tested than a stable release.  New releases may come out every month or so.

Finally, if you really want to see new features as they come in, you can subscribe to the “dev” channel.   Again, you’ll be automatically updated as new developer releases are available.   New releases may come out every few weeks.  These builds are tested well, but users should be aware that these releases will be the least stable.

To select which version of Chrome you want, you’ll need to run the Chrome “channel changer”.  You can get a copy of it here, or you can read more about it from here.  Once you’ve picked your channel, restart your browser, and soon you’ll have the version to which you’ve subscribed.

Here is a screenshot of the channel changer:

channels

XP Is Good Enough

ballmer Installing a new operating system is a pain in the neck. I hate doing it at home.  But how would you like to be the IT guy saddled with the task of updating 1,000 machines?

You basically have two choices:
  a) Let your customers use XP, take on no new workload for yourself so you can keep playing quake, get no new technical support questions and have no chance of getting fired, or

  b) Upgrade to Vista/Win7, creating tons of work for yourself in testing compatibility, be left with late-night work to answer stupid support questions, and if anything goes wrong, run the risk of getting fired.  Worse, you know that something *will* go wrong.  It’s just a matter of how bad the screw-up is.

Frankly – XP is good enough.  It works.  It’s compatible.  Hardware keeps getting faster to keep productivity up.  Applications move to the web, and the workload for supporting applications gets lighter.

Upgrading to Vista or Windows 7 means you have to make sure that every one of the 347 applications which worked yesterday still work today.  That’s simply an impossible task.  I wouldn’t want to do it.  Why would any IT manager want to?

Maybe Microsoft should just go into milk-the-cow mode.   No more operating systems.  Just do small patches to XP forever.

See also:
Recalling the Vista ‘Upgrade’
Vista Upgrade + Corporate Fleets = Costly Waste of Time
Microsoft Terrified Companies won’t Upgrade to Win7
Dell Warns of Vista Upgrade Challenges

New V8 Benchmark Posted

v8 A new version of the V8 Benchmark has been posted.  V8 is the Javascript engine used in Google Chrome.

Version 3 adds a new benchmark, RegExp. The RegExp benchmark is generated by loading 50 of the most popular pages on the web and logging all regexp operations performed. Each operation is given a weight that is calculated from an estimate of the popularity of the pages where it occurs and the number of times it is executed while loading each page. Finally the literal letters in the data are encoded using ROT13 in a way that does not affect how the regexps match their input.