Independent study on OpenID awareness using Mechanical Turk

Even though I wasn’t able to attend the eighth Internet Identity Workshop this week in Mountain View (check out the latest episode of TheSocialWeb.tv for a glimpse), I wanted to do my part to contribute so I’m sharing the results of a study that Brynn Evans and I performed on Mechanical Turk a short while ago.

I’ll cut to the chase and then go into some background detail.

Heard of OpenID?Of the 302 responses we received, we only rejected one, leaving us with 301 valid data points to work with. Of those 301:

  • 19.3% had heard of OpenID (58 people)
  • 9.0% knew what OpenID was used for (27) and 8.0% were unsure (24)
  • 1.3% used OpenID (4) and 18.3% were unsure if they used it (55).
  • 5.3% recognized the OpenID icon (16) and 7.0% were unsure (21).

Combining some of the results, we found that:

  • of those who know what OpenID is, 14.81% use it.
  • of those who have merely heard of it, 6.9% use it.

That’s what the data show.

Background

Several weeks ago, Yahoo released usability research and best practices for OpenID (PDF). This research was performed by Beverly Freeman in the Yahoo! Customer Insights division in July of this year and involved 9 female Yahoo! users age 32-39 with self-declared medium-to-high level of Internet savvy.

This research, along with Eric Sachs’ later contributions (Google), have taken us from virtually zero research on the usability of OpenID to having a much more robust pool of information to pull from. And though I’m sure many would agree that this research only points to opportunities for improvement, many people interpreted the results as an indication that “OpenID is too confusing” or that it “befuddles users“.

A lot of people also took cheap shots, using the Yahoo! results to bolster their long-held arguments against the protocol and its unfamiliar interaction flow. The problem with such criticism, as far as I’m concerned, is that generalizing from the experiences of nine female Yahoo! users in their thirties is not necessarily representative of the web at large, nor are the conditions favorable to such research. Y’know, Ford got a lot of flack too when he introduced the Model T because everyone loved their horse and carriages. Good thing Ford was right.

Now, some of the criticism of OpenID is valid, especially if it can be turned into productive outcomes, like making OpenID easier to use, or less awkward.

And it serves no one’s interests to make grandiose claims on the basis of minimal data, so given Brynn’s work using Mechanical Turk (with Ed Chi from PARC), I thought I’d ask her to help me set up a study to discover just what awareness of OpenID might be among a wider segment of the population, especially with Japanese awareness of OpenID topping out around 28% (with usage of OpenID at 15%, more than ten times what we saw with Turkers).

Mechanical Turk Demographics

First, it’s important to point out something about Turker demographics. Because Turkers must have either a US bank account or be willing to be paid in Amazon gift certificates, the quality of participants you get (especially if you design your HIT well) will actually be pretty good (compared with, say, a blog-based survey). Now, Mechanical Turk actually has rules against asking for demographic or personally identifying information, but some information has been gathered by Panos Ipeirotis to shed some light on who the Turkers are and why they participate. I’ll leave the bulk of the analysis up to him, but it’s worth noting that a survey put out on Mechanical Turk about OpenID will likely hit a fairly average segment of the internet-using population (or at least one that doesn’t differ greatly from college undergraduates).

Method

Over the course of a week (October 19 – 26), we fielded 302 responses to our survey, paying $0.02 for each valid reply (yes, we were essentially asking people for their “two cents”). We only rejected one response out of the batch, leaving us with 301 valid data points at a whooping cost of $6.02.

Findings

As I reported above, contrary to the 0% awareness demonstrated in the Yahoo! study of nine participants, we found that nearly 20% of respondents had at least heard of OpenID, though a much smaller percentage (1.3%) actually used it (or at least were consciously aware of using it — nearly everyone (18%) who’d heard of OpenID didn’t know if they used it or not).

There was also at least some familiarity with the OpenID logo/icon (5.3%).

What’s also interesting is that many respondents, upon hearing about “OpenID”, expressed an interest in finding out more: “What is it? LOL.”; “I’ve gotta look it up!”; “This survey has sparked my interest”; “Heading to Google to find out”. I can’t say that this shows clear interest in the concept, but at least some folks showed a curious disposition, as such:

How can I tell for sure whether I’ve used OpenID or not when I don’t know what it is? I’ve surely heard of it. That confuses me mainly in Magnolia {bookmarking service} where I want to sign up, but I can’t as it asks for OpenID. And until you mentioned above, it simply didn’t occur to me to just search it up. Hell, after submitting this hit, I’m going to do that first and foremost. Anyways, thanks a lot for indirectly suggesting a move!!!

Now, I won’t repeat the other findings, as they’ve already been reported above.

Thoughts and next steps

The results of this survey are interesting to me, but not unexpected. They’re not reassuring either, and they tell me that we’re doing well considering that we’ve only just begun.

Consider that 20% of a random sampling of 300 people on the internet had at least heard of OpenID, before Google, MySpace or Microsoft turned on their support for the protocol (MySpace announced their intention to support OpenID in July).

Consider that nearly a year ago Marshall Kirkpatrick sounded the deathknell of what seemed like the forgone conclusion about OpenID:

Big Players are Dragging Their Feet … Sharing User Info is a Whole Other Matter … Public Facing Profiles are Anemic … Ease of Use and Marketing Clarity Remain Low Priorities

Consider that no concerted effort has been made to date to inform or educate the general web population about OpenID, or about the problems with sharing your user credentials all over the web, and that many of the large providers have yet to turn on their OpenID support (despite all coming to the table and agreeing that it’s the way forward for identity on the web (save, as usual, Facebook, looking more Microsoftian by the day).

Consider also that momentum to rev the protocol to accommodate email addresses in OpenID is just now gaining traction.

In other words, with areas of user education becoming obvious, with provider adoption starting to happen (vis-a-via MySpace demonstrating the value and prevalence of URL-based identifiers) and necessary usability improvements starting to take shape (both in terms of the OpenID and OAuth flows being combined, and in terms of email addresses becoming valid in OpenID flows), we’re truly just getting started with making OpenID ready for mainstream audiences. It’s been a hard slog so far, and it’s bound to continue to be challenging, but the shared vision for where we’re going gets clearer every time there’s an Internet Identity Workshop.

I plan to re-run this study every 3-6 months from this point forward to keep track of our progress. I hope that these numbers will shed some much-needed balanced light on the subject of OpenID awareness and adoption — both to demonstrate how far we have to go, and how far we’ve come.

Lightweight access PINs: a modest proposal for enabling OpenID in desktop and mobile apps

While the news that Google is now an OpenID Provider was generally welcomed, a common chorus decrying their support (along with others large OPs like Yahoo, Microsoft and others) at best as half-hearted, at worst as ruining OpenID has revealed a significant barrier to such large providers becoming relying parties (even beyond usability).

Eric Sachs (Google Security Team) writes:

One other question that a lot of people asked yesterday is when a large provider like Google will become a relying party. There is one big problem that stands in the way of doing that, but fortunately it is more of a technology problem than a usability issue. That problem is that rich-client apps (desktop apps and mobile apps) are hard-coded to ask a user for their username and password. As an example, all Google rich-client apps would break if we supported federated login for our consumer users, and in fact they do break for the large number of our enterprise E-mail outsourcing customers who run their own identity provider, and for which Google is a relying party today. This problem with rich-client apps also affects other sites like Plaxo who are already relying parties.

Fortunately there is a solution, and it was developed specifically because Ma.gnolia ran into this problem when it became an OpenID relying party. The result, nine months in the making, was OAuth. Eric even recognizes this:

We need standard open-source components on as many platforms as possible to enable those rich-client apps to support OAuth. That includes a lot more platforms then just Windows and Mac. The harder part is mobile devices (Blackberry, Symbian, Windows Mobile, iPhone, and yes even Android), and other Internet connected devices like Tivos, Apple TVs, Playstations, etc. that have rich-client apps that ask users for their passwords to access services like Youtube, Google photos, etc. If we build these components, they will be useful not only to Google, but also to any other relying parties which have rich-client apps or exposes APIs, and it will also help enterprise SaaS vendors like Salesforce.

iPhone Sync CodeAs I’ve been thinking about this problem, I’ve come to see as an intermediate approach to full-on delegated authorization a simpler, perhaps more familiar approach that would be relatively easy to implement given common interface patterns today. For comparison, Pownce’s iPhone app originally used out-of-band browser-based authentication, leading to a swarm of user criticism resulting in a compromised solution that required embedding a web browser in the app. Less than ideal.

In my proposal, rather than ask for a user’s password, an easier-to-remember OP-issued numerical PIN would be used to authenticate requests. Better is that this approach is already supported in OAuth, it’s just not widely used yet (though is similar to how Flickr authorizes mobile clients).

The basic concept is that you’d have one password (or other strong authentication method) for your primary OpenID account and you’d have one (or more) PINs that you would use to access your account remotely — perhaps in limited risk scenarios or where (again) the full browser-based OAuth flow is not possible or warranted.

Although I initially opposed FriendFeed’s use of Remote Keys, I now think that there’s some merit to this approach, as long as the underlying mechanism uses standard OAuth calls.

There are plenty of holes in this approach, but insomuch as it enables an existing pattern to be phased out gently, I think it offers at least the foundation of an idea that could be useful. It also could be used as a counter-balance to some of the current thinking on federated login flows with OAuth.

Consider these three sign in boxes for comparison:

  1. Traditional Password
    traditional password
  2. Lightweight PIN access
    pin-access
  3. Full OAuth
    Full OAuth

Thoughts welcome.

OpenID usability is not an oxymoron

Julie Zhou of Facebook discusses usability findings from Facebook Connect.
Julie Zhou of Facebook discusses usability findings from Facebook Connect. Photo © John McCrea. All rights reserved.

See? We're working on this! Monday last week marked the first ever OpenID UX Summit at Yahoo! in Sunnyvale with over 40 in attendance. Representatives came from MySpace, Facebook, Google, Yahoo!, Vidoop, Janrain, Six Apart, AOL, Chimp, Magnolia, Microsoft, Plaxo, Netmesh, Internet 2 and Liberty Alliance to debate and discuss how best to make implementations of the protocol easier to use and more familiar.

John McCrea covered the significance of the summit on TechCrunchIT (and recognized Facebook’s welcomed participation) and has a good overall summary on his blog.

While the summit was a long-overdue step towards addressing the clear usability issues directly inhibiting the spread of OpenID, there are four additional areas that I think need more attention. I’ll address each separately. Continue reading “OpenID usability is not an oxymoron”

Obama Phone!

Obama PhoneIf you haven’t heard about this yet, the Obama campaign today released an iPhone app that, among other features, enables you to call your friends prioritized by their location in battleground states.

This is critical.

There’s nothing more important, or more influential, than friends encouraging friends to vote, and when it comes to getting informed on the issues and what’s at stake, nothing is more effective than getting an impassioned plea from a personal contact or relative.

Providing a tool that allows people to get in touch with people who they personally know is so much better than cold-calling phone banking (the importance of that tactic notwithstanding given the need to reach out beyond the friends of iPhone owners).

You can get the app in the iTunes App Store.

Obama Phone CreditsThe Obama ’08 app development was spearheaded by personal friends of mine — co-organizers of the popular iPhoneDevCamps that we held the past two years at Adobe’s offices in San Francisco (which are now spreading, like all good *camp events should!). Specifically, props go to Dom Sagolla and Raven Zachary, without whom this application might never have happened. But credit is also due to the entire top-tier team that spent countless hours over the past month putting this app together (*iPhoneDevCamp alumni):

What’s significant is not only the application, but what this move represents for those of us who live and breathe the web and open source: this app is born of both, reusing a number of open source components and, from the outset, leverages the web with presence on social networks like Facebook. This is the Obama campaign reaching out to the open source and iPhone development communities and working with us to do what we know how to do best, and giving us a space in which we can make a difference for the campaign.

We’re nearly a month a way from the election, and that means that if you want to participate, you’re going to need be registered to vote beforehand. It also means that if you’ve been waiting, or holding out, and looking for an opening to get involved, now’s your chance. As Raven says, making a few simple calls with this app enables even ‘The Two Minute Volunteer’ to make a substantial difference by personally involving friends and family in the election.

Seeing this work inspires and gives me hope; if we can keep up this kind of innovative thinking for the next 30 days, I think it’s clear that the best candidate is going to come out on top and get the country back on its proper footing.

After 1984

iTunes Genius

iTunes 8 has added a new feature called “Genius” that harnesses the collective behavior of iTunes Music Store shoppers to generate “perfect” playlists.

Had an interesting email exchange with my mom earlier today about Monica Hesse’s story Bytes of Life. The crux of the story is that more and more people are self-monitoring and collecting data about themselves, in many cases, because, well, it’s gotten so much easier, so, why not?

Well, yes, it is easier, but just because it is easier, doesn’t automatically mean that one should do it, so let’s look at this a little more deeply.

First, my mom asked about the amount of effort involved in tracking all this data:

I still have a hard time even considering all that time and effort spent in detailing every moment of one’s life, and then the other side of it which is that it all has to be read and processed in order to “know oneself”. I think I like the Jon Cabot Zinn philosophy better — just BE in the moment, being mindful of each second doesn’t require one to log or blog it, I don’t think. Just BE in it.

Monica didn’t really touch on too many tools that we use to self-monitor. It’s true that, depending on the kind of data we’re collecting, the effort will vary. But so will the benefits.

MyMileMarkerIf you take a look at MyMileMarker’s iPhone interface, you’ll see how quick and painless it is to record this information. Why bother? Well, for one thing, over time you get to see not only how much fuel you’re consuming, but how much it’s going to cost you to keep running your car in the future:

View my Honda Civic - My Mile Marker

Without collecting this data, you might guess at your MPG, or take the manufacturer’s rating as given, but when you record what actually is happening, you can prove to yourself whether filling up your tires really does save you money (or the planet).

On the topic of the environment, recording my trips on Dopplr gives me an actual view of my carbon footprint (pretty damning, indeed):

DOPPLR Carbon

As my mom pointed out, perhaps having access to this data will encourage me to cut back excess travel — or to consolidate my trips. Ross Mayfield suggests that he could potentially quit smoking if his habit were made more plainly visible to him.

What’s also interesting is how passive monitors, or semi-passive monitoring tools, can also inform, educate or predict — and on this point I’m thinking of Last.fm where of course my music taste is aggregated, or location-based sites like Brightkite, where my locative behavior is tracked (albeit, manually — though Fire Eagle + Spot changes that).

My mom’s other point about the ability to just BE in the moment is also important — because self-tracking should ideally be non-invasive. In other words, it shouldn’t be the tracking that changes your behavior, but your analysis and reflection after the fact.

One of the stronger points I might make about this is that data, especially when collected regularly and when the right indicators are recorded, you can reduce a great amount of distortion from your self-serving biases. Monica writes:

“We all have the tendency to see our behaviors in a little bit of a halo,” says Jayne Gackenbach, who researches the psychology of the Internet at Grant MacEwan College in Alberta, Canada. It’s why dieters underestimate their food intake, why smokers say they go through fewer cigarettes than they do. “If people can get at some objective criteria, it would be wonderfully informative.” That’s the brilliance, she says, of new technology.

big-brotherSo that’s great and all, but all of this, at least for my mom, raises the spectre of George Orwell’s ubiquitous and all-knowing “Big Brother” from Nineteen Eighty-Four and neo-Taylorism:

I do agree that people lie, or misperceive, and that data is a truer bearer of actualities. I guess I don’t care. Story telling is an art form, too. There’s something sort of 1984ish about all this data collection – – as if the accumulated data could eventually turn us all into robotic creatures too self-programmed to suck the real juice out of life.

I certainly am sympathetic to that view, especially because the characterization of life in 1984 was so compelling and visceral. The problem is that this analogy invariably falls short, especially in other conversations when you’re talking about the likes of Google and other web-based companies.

In 1984, Big Brother symbolized the encroachment of the government on the life of the private citizen. Since the government had the ability to lock you up or take you away based on your behavior, you can imagine that this kind of dystopic vision would resonate in a time when increasingly fewer people probably understand the guts of technology and yet increasingly rely on it, shoveling more and more of their data into online repositories, or having it collected about them as they visit various websites. Never before has the human race had so much data about itself, and yet (likely) so little understanding.

The difference, as I explained to my mom, comes down to access to — and leverage over — the data:

I want to write more about this, but I don’t think 1984 is an apt analogy here. In the book, the government knows everything about the citizenry, and makes decisions using that data, towards maximizing efficiency for some unknown — or spiritually void — end. In this case, we’re flipping 1984 on its head! In this case we’re collecting the data on OURSELVES — empowering ourselves to know more than the credit card companies and banks! It’s certainly a daunting and scary thought to realize how much data OTHER people have about us — but what better way to get a leg up then to start looking at ourselves, and collecting that information for our own benefit?

I used to be pretty skeptical of all this too… but since I’ve seen the tools, and I’ve seen the value of data — I just don’t want other people to profit off of my behaviors… I want to be able to benefit from it as well — in ways that I dictate — on my terms!

In any case, Tim O’Reilly is right: data is the new Intel inside. But shouldn’t we be getting a piece of the action if we’re talking about data about us? Shouldn’t we write the book on what 2014 is going to look like so we can put the tired 1984 analogies to rest for awhile and take advantage of what is unfolding today? I’m certainly weary of large corporate behemoths usurping the role the government played in 1984, but frankly, I think we’ve gone beyond that point.

Musings on Chrome, the rebirth of the location bar and privacy in the cloud

Imagine a browser of the web, by the web, and for the web. Not simply a thick client application that simply opens documents with the http:// protocol instead of file://, but one that runs web applications (efficiently!), that plays the web, that connects people across the boundaries of the silos and gives them local-like access to remote data.

It might not be Chrome, but it’s a damn near approximation, given what people today.

Take a step back. You can see the relics of desktop computing in our applications’ file menus… and we can intuit the assumptions that the original designer must have made about the user, her context and the interaction expectations she brought with her:

Firefox Menubar

This is not a start menu or a Dock. This is a document-driven menubar that’s barely changed since Netscape Communicator.

Indeed, the browser is a funny thing, because it’s really just a wrapper for someone else’s content or someone’s else’s application. That’s why it’s not about “features“. It’s all about which features, especially for developers.

It’s a hugely powerful place to insert oneself: between a person and the vast expanse that is the Open Web. Better yet: to be the conduit through which anyone projects herself on to the web, or reaches into the digital void to do something.

So if you were going to design a new browser, how would you handle the enormity of that responsibility? How would you seize the monument of that opportunity and create something great?

Well, for starters, you’d probably want to think about that first run experience — what it’s like to get behind the wheel for the very time with a newly minted driver’s permit — with the daunting realization that you can now go anywhere you please…! Which is of course awesome, until you realize that you have no idea where to go first!

Historically, the solution has been to flip-flop between portals and search boxes, and if we’ve learned anything from Google’s shockingly austere homepage, it comes down to recognizing that the first step of getting somewhere is expressing some notion of where you want to go:

Camino. Start

InquisitorThe problem is that the location field has, up until recently, been fairly inert and useless. With Spotlight-influenced interfaces creeping into the browser (like David Watanabe’s recently acquired Inquisitor Safari plugin — now powered by Yahoo! Search BOSS — or the flyout in Flock that was inspired by it) it’s clear that browsers can and should provide more direction and assistance to get people going. Not everyone’s got a penchant for remembering URLs (or RFCs) like Tantek’s.

This kind of predictive interface, however, has only slowly made its way into the location bar, like fish being washed ashore and gradually sprouting legs. Eventually they’ll learn to walk and breath normally, but until then, things might look a little awkward. But yes, dear reader, things do change.

So you can imagine, having recognized this trend, Google went ahead and combined the search box and the location field in Chrome and is now pushing the location bar as the starting place, as well as where to do your searching:

Chrome Start

This change to such a fundamental piece of real estate in the browser has profound consequences on both the typical use of the browser as well as security models that treat the visibility of the URL bar as sacrosanct (read: phishing):

Omnibox

The URL bar is dead! Long live the URL bar!

While cats like us know intuitively how to use the location bar in combination with URLs to gets us to where to we want to go, that practice is now outmoded. Instead we type anything into the “box” and have some likely chance that we’re going to end up close to something interesting. Feeling lucky?

But there’s something else behind all this that I think is super important to realize… and that’s that our fundamental notions and expectations of privacy on the web have to change or will be changed for us. Either we do without tools that augment our cognitive faculties or we embrace them, and in so doing, shim open a window on our behaviors and our habits so that computers, computing environments and web service agents can become more predictive and responsive to them, and in so doing, serve us better. So it goes.

Underlying these changes are new legal concepts and challenges, spelled out in Google’s updated EULA and Privacy Policy… heretofore places where few feared to go, least of all browser manufacturers:

5. Use of the Services by you

5.1 In order to access certain Services, you may be required to provide information about yourself (such as identification or contact details) as part of the registration process for the Service, or as part of your continued use of the Services. You agree that any registration information you give to Google will always be accurate, correct and up to date.

. . .

12. Software updates

12.1 The Software which you use may automatically download and install updates from time to time from Google. These updates are designed to improve, enhance and further develop the Services and may take the form of bug fixes, enhanced functions, new software modules and completely new versions. You agree to receive such updates (and permit Google to deliver these to you) as part of your use of the Services.

It’s not that any of this is unexpected or Draconian: it is what it is, if it weren’t like this already.

Each of us will eventually need to choose a data brokers or two in the future and agree to similar terms and conditions, just like we’ve done with banks and credit card providers; and if we haven’t already, just as we have as we’ve done in embracing webmail.

Hopefully visibility into Chrome’s source code will help keep things honest, and also provide the means to excise those features, or to redirect them to brokers or service providers of our choosing, but it’s inevitable that effective cloud computing will increasingly require more data from and about us than we’ve previously felt comfortable giving. And the crazy thing is that a great number of us (yes, including me!) will give it. Willingly. And eagerly.

But think one more second about the ramifications (see Matt Cutts) of Section 12 up there about Software Updates: by using Chrome, you agree to allow Google to update the browser. That’s it: end of story. You want to turn it off? Disconnect from the web… in the process, rendering Chrome nothing more than, well, chrome (pun intended).

Welcome to cloud computing. The future has arrived and is arriving.

Google Chrome and the future of browsers

Chrome LogoNews came today confirming Google’s plans for Chrome, its own open source browser based on Webkit.

This is big news. As far as I’m concerned, it doesn’t get much bigger than this, at least in my little shed on the internet.

I’ve been struggling to come to grips with my thoughts on this since I first heard about this this morning over Twitter (thanks @rww @Carnage4Life and @furrier). Once I found out that it was based on Webkit, the pieces all fell into place (or perhaps the puzzle that’s been under construction for the past year or so became clearer).

Chrome is powered by Webkit

Last May I ranted for a good 45 minutes or so about the state of Mozilla and Firefox and my concerns for its future. It’s curious to look back and consider my fears about Adobe Air and Silverlight; it’s more curious to think about what Google Chrome might mean now that it’s been confirmed and that those frameworks have little to offer in the way of standards for the open web.

I read announcement as the kid gloves coming off. I just can’t read this any other way than to think that Google’s finally fed up waiting around for Firefox to get their act together, fix their performance issues in serious ways, provide tangible and near-term vision and make good on their ultimate promise and value-proposition.

Sure, Google re-upped their deal with Firefox, but why wouldn’t they? If this really is a battle against Microsoft, Google can continue to use Firefox as its proxy against the entrenched behemoth. Why not? Mozilla’s lack of concern worries me greatly; if they knew about it, what did they do about it? Although Weave has potential, Google has had Google Browser Sync for ages (announced, to wit, by Chrome’s product manager Brian Rakowski). Aza Raskin might be doing very curious and esoteric experiments on Labs, but how does this demonstrate a wider, clearer, focused vision? Or is that the point?

Therein lies the tragedy: Google is a well-oiled, well-heeled machine. Mozilla, in contrast, is not (and probably never will be). The Webkit team, as a rhizomatic offshoot from Apple, has a similar development pedigree and has consistently produced a high quality — now cross-platform — open source project, nary engaging in polemics or politics. They let the results speak for themselves. They keep their eyes on the ball.

Ultimately this has everything to do with people; with leadership, execution and vision.

When Mozilla lost Ben Goodger I think the damage went deeper than was known or understood. Then Blake Ross and Joe Hewitt went over to Facebook, where they’re probably in the bowels of the organization, doing stuff with FBML and the like, bringing Parakeet into existence (they’ve recently been joined by Mike Schroepfer, previously VP of Engineering at Mozilla). Brad Neuberg joined Google to take Dojo Offline forward in the Gears project (along with efforts from Dylan Schiemann and Alex Russell). And the list goes on.

Start poking around the names in the Google Chrome comic book and the names are there. Scott McCloud’s drawings aren’t just a useful pictorial explanation of what to expect in Chrome; it’s practically a declaration of independence from the yesteryear traditions of browser design of the past 10 years, going all the way back to Netscape’s heyday when the notion of the web was a vast collection of interlinked documents. With Chrome, the web starts to look more like a nodal grid of documents, with cloud applications running on momentary instances, being run directly and indirectly by people and their agents. This is the browser caught up.

We get Gears baked in (note the lack of “Google” prefix — it’s now simply “of the web”) and if you’ve read the fine-print closely, you already know that this means that Chrome will be a self-updating, self-healing browser. This means that the web will rev at the speed of the frameworks and the specifications, and will no longer be tied to the monopoly player’s broken rendering engine.

And on top of Gears, we’re starting to see the light of the site-specific browser revolution and the maturing of the web as an application platform, something Todd Ditchendorf, with his Fluid project, knows something about (also based on Webkit — all your base, etc):

Google Chrome + Gears

In spite of its lofty rhetoric in support of a free Internet, Chrome isn’t Mozilla’s pièce de résistance. Turns out that it’s going to be Apple and Google who will usher in the future of browsers, and who will get to determine just what that future of browsers are going to look like:

Google Chrome, starting from scratch

To put it mildly, things just got a whole lot more exciting.