Infrequently Noted

ZDNet has an article out discussing a study that shows that that Chrome's (Open Source) auto-update system makes the browser more secure than the alternatives. Disclosure: Google co-authored the study. I work for Google, on Chrome. Caveat emptor.

Back when I did security for a living, I quickly noted a distinction between those who saw things as white vs. black and those who viewed things in risks. White vs. black is the mentality of the attacker (you only need to pwn one system, not every system) and of green defenders who can't yet distinguish severity or haven't been thought to think about defense in depth. A risk-based view of security pays a lot more attention to questions of who you're securing a system against and for how long. In this world view, threats are risks to be evaluated and mitigated, not a constant stream of sky-is-falling crises. A risk based view says "yes, the sky might be falling somewhere, but what are the odds it's falling on me? And even if it is, what's the worst that can happen?" If the likelihood is high and the severity is high, spend a lot of time on it. When you view security in terms of risks to be mitigated, you make very different tradeoffs. If you think you need to (or even can) control and eliminate every risk, than you might be tempted to build brittle systems. If, on the other hand, you acknowledge that humans are invoked (and are fallible) and that sometimes things break, you might give up a little control to get to a better place on average and be willing to suffer some minor setbacks on the way there.

The difference between Chrome's update system and that of other browsers is that the Chrome updater turns the dial all the way in the direction of mitigation, treating the window of vulnerability as the most important factor in the risk of an attack. It's more important in this world to mitigate an attack than to have asked the user if they want their system to be updated. Is there any other right answer to that question for most users than "yes"?

Here's where the knives come out: rational people with very different perspectives often want totally different things. System administrators for large organizations – tallented people whose job it is to personally assess and deal with risks – may disagree with this policy since it introduces new risks which they can't effectively mitigate. The Chrome answer to these concerns has been to treat them as the special case they are. You can easily get the standalone installer that doesn't include auto-update, but it's not something that's advertised on the main download page. Why? Because it's not what will keep most users secure.

The default Chrome update model is designed around the perspective of the average Chrome user. Not the vocal minority of those who know enough to build Chrome from source or even for corporate IT administrators. Their needs are real, and their perspective is valid, but it is not common and should not dominate the discussion about what is best for the majority. If we've learned anything through most GUI Open Source projects, it's that developers have a hard time empathizing with the needs and skills of most users. This shows up in many places, but perhaps the most curious place of all is the extra confirmation box that asks you if you'd like to have a secure browser or an insecure browser. To anyone but an IT administrator or a developer, it's not a legitimate choice, it's an opportunity for failure with the deck stacked against you.

I'm glad the Chrome team has prioritized security through convenience at the expense of the illusion of control. It's one of those things that's obvious once you change your perspective. Too bad it's not nearly as easy as it sounds. Everyone's selling their point of view, but there are predictably few buyers amongst the already enfranchised.

Hat tip: Glen's excellent ChatGraph.

The Uxebu guys show how to use Google Spreadsheets as a cross-domain data source. Clever.

The Google O3D team just launched and the news stories are already starting to trickle out.

Ok, so it's shiny...but so what?

First, O3D embeds V8. This means that while you might be running your O3D code in a browser with a terrible JavaScript engine, or worse, an engine with terrible GC pauses, your O3D content isn't subject to those problems. This is a Big Win (TM). Most of the web can limp by with bad GC behavior, but interactive 3D just can't. You might have seen the difference this makes by running Dean's Monster demo in Chrome and then trying it in other browsers.

Next, O3D presents a scene graph. Direct-mode proposals to the 3D-on-the-web discussion are based on the idea that JavaScript programmers will ship enormous toolsets down the wire in order to re-create the scene graph and/or to parse shape descriptions. Having direct access to the OpenGL surface description is incredibly powerful, but I suspect not sufficient in the long term to really bootstrap a world where 3D is a first-class citizen. Also, using the web as a way to break-open some of the closed interchange challenges of today's 3D world isn't going to happen when everyone's description of things is entirely programmatic, so I'm excited by the direction of O3D as a force for good.

Congrats to the O3D team. It's a big day for them and the deserve huge props for shipping concurrently on Windows and Mac.

Google Analytics is ubiquitous, not least of all because it's better at what it does than most of the alternatives. Also, it doesn't require any install or maintenance. And it's free. What's not to like?

Frankly, not much, but if I had to nit pick, I'd note that the worst part of Google Analytics is the ga.js script that does the actual tracking of content. It's not bad, in and of itself, but it tends to load slowly. There are several reasons for this:

• Another DNS lookup to resolve http://www.google-analytics.com/. This DNS entry is likely to be "warm" given how frequently ga.js is used on the web, but as Jim Roskind explained on the Chromium blog, it's the outliers that kill you.
• It's kinda big. At 9K on the wire (22K unzipped), ga.js is kinda chunky for what it does most of the time, namely tracking a single page load.
• The default instructions are bone-headed. They direct you to do a document.write() which is a blocking, synchronous operation WRT page loading. This is tres dumb. Reasonable people should just include ga.js with a <script> tag, but nearly nobody does. Turns out that sane defaults still matter.
• Load times seem totally random. As with DNS lookup, ga.js's latency varies wildly. This isn't backed up by anything empirical, but many pages feel blocked by ga.js for a near eternity.

So how to fix this? Dojo 1.3's dojox.analytics.Urchin to the rescue! Given that I was going to be including Dojo on the page to do other things anyway, I can use 1.3's new Urchin system to help amortize the cost of using Google Analytics. The code running on this blog now includes the following code (more or less):

<script type="text/javascript"
  src="https://ajax.googleapis.com/ajax/libs/dojo/1.3/dojo/dojo.xd.js">
</script>
<script type="text/javascript">
  dojo.addOnLoad(function(){
    setTimeout(function(){
      dojo.require("dojox.analytics.Urchin");
      dojo.addOnLoad(function(){
        var tracker = new dojox.analytics.Urchin({
          acct: "UA-XXXXXX-X" // your tracking # here
        });
      });
    }, 100);
  });
</script>

You can see the real thing by looking at the bottom of this page which pulls in custom.js which includes this logic. Pete Higgins blogged about how the module works when he first wrote it, and the strategy is to load Dojo from a CDN (since the page wanted it for other things) and wait until after the page has loaded to include ga.js. This delayed loading ensures that the page is responsive before we start doing anything related to tracking. The nested calls to dojo.addOnLoad show how we can wait for one set of modules to finish before kicking off another group, and in this case we also wait until after the page is responsive to load dojox.analytics.Urchin. This module further delays loading of ga.js, meaning that it doesn't matter how long it takes for things like DNS to resolve and for Google to serve ga.ja since it's not ever blocking the user.

Looking at the "before" and "after" shots in firebug gives you some idea of how this technique can really make a difference:

[caption id="attachment_940" align="aligncenter" width="300" caption="onload waits for ga.js"][/caption]

[caption id="attachment_941" align="aligncenter" width="300" caption="using dojox.analytics.Urchin, we can get a responsive page and then track usage"][/caption]

We get page tracking and the user gets an interactive page faster. Rad.

Google Updater, aka "Omaha", has gone Open Source!

This is the auto-update system that's key to keeping Chrome secure by always ensuring that the version you're running is the freshest it can be. It's huge for the Omaha team to be out in the open, particularly given how many inaccurate articles have been penned about the update system. Now you, dear user and/or journalist, can know exactly what the update system is doing all the time. It's all right there in the code.