There are some obvious advantages to SPDY; header compression means that things like cookies get gzipped, not just content, and mutliplexing over a single connection with priority information will allow clients and servers to cooperate to accelerate page layout based on what’s important, not only what got requested first.

But the the really interesting stuff from my perspective is the way SPDY enables server push both for anticipated content and for handling Comet-style workloads. The first bit is likely to have the largest impact for the largest set of apps. Instead of trying to do things like embed images in data: URLs — which punishes content by making it uncacheable — SPDY allows the server to anticipate that the client will need some resource and preemptively begin sending it without changing the HTTP-level semantics of the request/response. The result is that even for non-cached requests, many fewer full round trips are required when servers are savvy about what the client will be asking for. Another way to think about it is that it allows the server to help pre-fill an empty cache. Application servers like RoR and Django can know enough about what resources a page is likely to require to begin sending them preemptively in a SPDY-enabled environment. The results in terms of how we optimize apps are nothing short of stunning. Today we work hard to tell browsers as early as possible that they’ll need some chunk of CSS (per Steve’s findings) and try to structure our JavaScript so that it starts up late in the game because the penalty for waiting on JS is so severe (blocked rendering, etc.). At the very edge of the envelope, this often means inlining CSS and accepting the penalty of not being able to cache for things that should likely be reusable across pages. On most sites, the next page looks a lot like the previous one, after all. When implemented well, SPDY will buy us a way out of this conundrum.

And then there are the implications for Comet workloads. First, SPDY multiplexes. One socket, many requests. Statefully. By default. Awwwww yeah. That means that a client that wants to hang on to an HTTP connection (long polling, “hanging GET”, <term of the week here>) isn’t penalized at the server since SPDY servers are expected to be handling stateful, long-lived connections. At an architectural level, SPDY forces the issue. No one will be fielding a SPDY server that doesn’t handle Comet workloads out of the box because it’ll often be harder to do so than not. SPDY finally brings servers into architectural alignment with how many clients want to use them.

Beyond that, SPDY allows clients to set priority information, meaning that real-time information that’s likely to be small in size can take precedence on the wire over a large image request. Similarly, because it multiplexes, SPDY could be used as an encapsulation format for WebSockets, allowing one TCP socket to service multiple WebSockets. The efficiency gains here are pretty obvious: less TCP overhead and lowered potential for unintentional DoS (think portals with tons of widgets all making socket requests). There’s going to need to be some further discussion about how to make new ideas like WebSockets work over SPDY, but the direction is both clear and promising. SPDY should enable a faster web both now and in the future.

Some googling revealed that Apple shipped two 10.5.8′s!. A regular software-update won’t trigger the required update, either. Luckily, re-applying the stand-alone updater got me up to 9l31a, and I can once again abuse my co-worker’s CPUs instead of my own. Phew!

A very short open letter:

Today’s example of failure made manifest comes via Reddit’s programming section (easy target, I know), but deserves some special attention thanks to such witty repartee as:

Using slow-motion video? What a great idea. Maybe we can benchmark operating systems like that.

Maybe we can….and maybe we should. It might yield improvements in areas of OS performance that impact user experience. With a methodology that represents end-user perception, you should be able to calculate the impact of different scheduling algorithms on UI responsiveness, something that desktop Linux has struggled with.

The test under mockery may have problems, but they’re not the ones the author assumes. It turns out that watching for visual indications of “doneness” is a better-than-average way to judge overall browser performance (assuming fixed hardware, testing from multiple network topologies, etc.). After all, perceived performance in browsing is all that matters. No one discounts a website’s performance because when you visit they happen to let browsers cache resources that get used across pages or because they use a CDN to improve resource loading parallelism. In the real world, anything you can do to improve the perceived latency of a web site or application is a win.

MSFT’s test methodology (pdf) does a good job in balancing several factors that affect latency for end-users, including resources that are loaded after onload or in sub-documents, potential DNS lookup timing issues, and the effects of network-level parallelism on page loading. Or at least it would in theory. The IE team’s published methodology is silent on points such as how and where DNS caches may be in play and what was done to mitigate them, but the level of overall rigor is quite good.

So what’s wrong with the MSFT test? Not much, except that they didn’t publish their code or make the test rig available for new releases of browsers to be run against. As a result, the data is more likely to be incorrect because it’s stale than to be incorrect due to methodology problems. New browser versions are being released all the time, rendering the conclusions from the Microsoft study already obsolete. Making the tests repeatable by opening up the test rig or filling in the gaps in the methodology would fix that issue while lending the tests the kind of credibility that the Sun Spider and V8 benchmarks now enjoy.

This stands in stark opposition to this latest “benchmark”. Indeed, while the source code was posted, it only deepens my despair. By loading the “real world sites” from a local copy, much of the excellent work being done to improve browser performance at the network level is totally eliminated. Given the complexity of real-world sites and the number of resources loaded by say, Facebook.com, changes that eliminate the effects of the network make the tests highly suspect. While excoriating JavaScript benchmarks as not representing the real world accurately, the test author eliminated perhaps the largest contributor to page loading latency and perceived performance. Ugg.

Instead of testing real-world websites (where network topology and browser networking makes a difference), the author tested local, “dehydrated” versions of websites. The result is that “loading times” weren’t tested, but rather a test of “local resource serving times and site-specific optimizations around the onload event” was run . Testing load times would have accounted for resources loaded after the onload event fired, too. There’s reason to think that neither time to load from local disk nor time for a page to fire the onload handler dominate (or even indicate) real world performance.

I’m grateful that this test showed that Chrome loads and renders things quickly from local disk. I also have no doubt that Chrome loads real websites very quickly, but this test doesn’t speak to that.

It’s frustrating that the Reddits and Slashdots of the world have such poor collective memory and such faulty filtering that they can’t seem to keep themselves from promoting these types of bias re-enforcing stories on a regular basis. Why, oh why, can’t we have better tech journalism?

I’m sure all the blags will be a-twitter with this shortly, but Chrome 2.0 is now out to everyone, and it’s even faster. Yes, V8 got even more polish (new compiler infrastructure FTW!), but the big speed news from my perspective comes from other parts of the browser. Chrome 2.0 moves fully away from the Windows networking stack to Chrome’s faster networking infrastructure and includes changes to memory allocation that make the DOM go like hell. There’s lots of great feature work in 2.0, of course, but now’s not the time for us to bury the real story: Chrome, fast as it was, just got even faster. Thanks to silent auto-update, it’ll even make the web faster faster.

Bam!

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.

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.

Trying out the experiments on the Chrome 2.0 beta or Safari 4′s beta feels like the early days of the web all over again, in a good way. New things seem possible…like there’s stuff we can do now that was off limits before. Beautiful stuff, particularly Dean McNamee’s Monster and Colorscube, Ryan Alexander’s Canopy, and the awesome Browsermation.

Awww yeah.

Thanks, as always, go to Chrome’s good friends over at Apple and WebKit who are doing amazing work to help deliver a more beautiful web.

Take, for example, ZDNet’s gutter-to-gutter coverage which, I’m afraid, simply ends in the intellectual gutter. Larry Dignan’s piece does the profession no favors by simply recycling the tried-and-true blogger formula for traffic generation:

I know about X, Google did Y, which is clearly *all about* X

The best of this flavor of “story” approaches the quality level of a plausible but objectively outlandish conspiracy theory, often pulling together bits of fact with a healthy dose of wild speculation (journalistically couched as the unfounded and unquestioned opinion of some supposedly credible third party).

ZDNet piles all aboard the loony-bin express with Paula Rooney’s “analysis” piece, helpfully asking the non-question “is this a prelude to Google acquiring Mozilla?”. In what twisted alternate universe would this wild, hair-brained straw-man garner a full ‘graf in a legit online publication, let alone a respected print daily? A small, tiny dig into the strategy of Google’s Mozilla search placement deal and the infrastructure of the Chrome browser would lead anyone (and everyone) to conclude that Google’s interest here is in keeping the browser a viable platform by any means necessary, not that they would ever gain anything by “acquiring” MoCo or MoFo (an even more nutty idea, since it would be difficult for a 501(c)3 organization to transfer resources and assets to a for-profit entity anyway).

The strategic and tactical incoherence continues with the daringly dumb quote:

Larry Dignan of ZDnet suggests that perhaps Google and Mozilla are working together as a tag team to defeat Microsoft’s Internet Explorer, and that Google may perhaps purchase the Mozilla Firefox crew and integrate the two code bases to deliver a kock out punch to Microsoft’s IE. Will Mozilla become Google browser labs? Given the close cooperation of the two projects, it’s more than possible.

Ignoring the incestuous and dubious use of a fellow reporter’s speculation as a source for an article, the idea that the Google would want much (if any) of the Firefox team (or vice versa) beyond those which they already pulled away. It does Google no good to reduce competition in the browser space, and one can imagine that there’s no love lost at Mozilla over Chrome, particularly after Google shunned the Firefox rendering engine, replaced the JavaScript engine, and re-built the entire visual and end-user experience from-scratch with completely different technology (i.e., not XUL). Good sourcing might have fleshed out the idea and perhaps even made a case for the theory, but alas, that seems far too much for ZDNet to produce on deadline. I mean, it’s not like they cover technology for a living…gosh, that’d be embarrassing. Quick tip for the next time they want to write this story: Google just became “Google’s browser labs” after giving Mozilla a good long run at it. They’re still strategically aligned, but Google seems impatient and is likely most interested in having direct leverage in the browser space (first via Gears and now Chrome) instead of the indirect influence they exerted over Firefox when it was still “Plan A”.

The coupe-de-disgrace belongs to PC World, though. After laying out 7 sensible, but “we’re just cribbing this from the press release, really” reasons to like Chrome they proceed to indulge in 7 forehead-slappingly idiotic reasons why you might consider something announced as a Beta to be…well…a beta. It feels kinda dirty just linking to it. Luckily, the PC World crew was able to get it together enough to publish a scoop-free “I played with it for 5 minutes” piece that WaPo wasn’t embarrassed to run, although the “like being there!” aspect really looses it’s punch when anyone can download the beta and, well, be there.

At least with Wired you know you’ll be getting fawning access journalism without the pretense of objectivity, but damnit, it’ll be well written and vaguely cogent.

I won’t even start on the blags. It’s to depressing. I’ll except Ajaxian and Philipp Lenssen here as they added some useful background from the inside perspective and scooped the story (respectively). “Citizen journalism” has a loooong way to go before it earns a place in the 4th estate, though.

Why, oh why, can’t we have better tech journalists?

So what does Chrome mean for those of us who aren’t breaking out the champagne? Well, first, it’s the second sign (after Gears and YBP (har!)) that the content authors are taking back the web from the “browser guys”. I’ve been fascinated for the last 6 months or so by the strategic mis-alignment which results when both the browsing and authoring experience in the hands of organizations only care about one but not the other. Mozilla gets paid by search-box revenue and users download it because it’s better for browsing, therefore Mozilla is incented to build new ways to browse, but their investments in content are somewhat mis-aligned (and, frankly, it shows). Google and Yahoo, on the other hand, are critically dependent on the content getting better, so they produce plugins to augment HTML in un-intrusive ways. Chrome crosses over into the browser business from the perspective of content, and it also shows, albeit in a good-ish way. I guess we’ll need to wait and see how browsing-oriented Chrome gets (e.g., will it sprout an extensions platform – ala Firefox – or will the propsect of an ad-blocking plugin for the Google browser make that proposal D.O.A.?).

Regardless of how Chrome evolves as a product, the important question now is: how will it be distributed? The obviously non-evil thing to do is to say “look, it’s great, it’s free” and hope that the world discovers it on its own thanks to word-of-mouth and/or leverage of the Google brand. Given that Chrome delivers new awesome things which are end-user-visible (some “end-user-awesome”, if you will), there’s some real chance that Chrome can get to roughly Firefox level market-share without breaking too much of a sweat. Not that Firefox’s market share is anything to really covet, given that MoFo/MoCo have been toiling at it for a decade now. To get real, honest-to-god leverage out of this process, Chrome is going to need something like 60+% market share, and that means changing ingrained user habits. I put the probability of that happening without distribution channel love at roughly bupkis.

Microsoft killed Netscape by bundling the browser with the OS. Apple is making inroads by bundling. Firefox is even getting aggressive. So where does this leave “don’t be evil”? Given the toolbar promotional deals which Google has cut in the past, I think there’s some organizational capacity inside the Goog to use the distribution channels they’ve already created as a way of getting to critical mass. What I don’t see, though, is a view of how to bring the mission of Gears into alignment with Chrome (or vice versa). They’re both important, but Chrome is a long-term bet while Gears is the near-future solution. They are not in opposition, but their strategies for gaining leverage over the problems facing content authors are very different.

We need what Gears can offer to every browser right now while Chrome dukes it out for market share on the browsing experience merits. Hopefully, if nothing else, the Chrome installer will add Gears to other browsers on the system that users install Chrome to. Even if they don’t pick the googly experience for browsing day-to-day, perhaps Chrome can still serve to give new tools to the content-author side of the house. Other browser vendors won’t do such a thing since they win or loose on an exclusive “I must replace the other guy” basis. Here, Google (and by “Google”, I mean “the open web”) wins either way. Hopefully Google’s interest in making the content experience better trumps the “we’re all browser guys now” instinct in this case.

We’ll find out tomorrow, I guess. Here’s to hoping.