Brian Rakowski walks to the whiteboard in a small conference room in Building 41 on Google's Mountain View campus. A lanky, gregarious man in his twenties, Rakowski is the product manager of a top-secret project that's been under way for more than two years. The weekly Monday meeting of managers — or "leads," as Google puts it in its nonhierarchical way — will be one of the last before the upcoming launch. Rakowski writes 12 items on the board with a black dry-erase marker. The first is "State of the Release." It's late August, and the release in question is called Chrome, Google's first Web browser. Since a browser is the linchpin of Web activity — the framework for our searching, reading, buying, banking, Facebooking, chatting, video watching, music appreciation, and porn consumption — this is huge for Google, a step that needed to wait until the company had, essentially, come of age. It is an explicit attempt to accelerate the movement of computing off the desktop and into the cloud — where Google holds advantage. And it's an aggressive move destined to put the company even more squarely in the crosshairs of its rival Microsoft, which long ago crushed the most fabled browser of all, Netscape Navigator.
A Google browser has been rumored for so long that most people have stopped talking about it. But the folks in this room know that the talking will soon begin again. Chrome is due to rock the Web just 16 days from this meeting.
It turns out the state of the release is ... not so bad. At Release Build Minus One — ideally, the last version before the public beta hits the streets — there are only five "blocking" bugs, all of which Rakowski and team deem fixable. "Things are looking good," says Mark Larson, one of the tech leads.
"What are we missing?" asks Sundar Pichai, Google's vice president of product management. "What's keeping you up at night?"
"It's not Chrome," says Darin Fisher, an engineer who coauthored the first prototype. That gets a laugh because everyone knows he's got a 10-week-old at home. Rakowski takes a red marker and puts an X next to the State of the Release item. The Google browser is one step closer to reality.
Why is Google building a browser? A better question is, why did it take so long for Google to build a browser? After all, as Pichai says, "our entire business is people using a browser to access us and the Web."
"The browser matters," CEO Eric Schmidt says. He should know, because he was CTO of Sun Microsystems during the great browser wars of the 1990s. Google cofounders Larry Page and Sergey Brin know it, too. "When I joined Google in 2001, Larry and Sergey immediately said, 'We should build our own browser,'" Schmidt says. "And I said no."
It wasn't the right time, Schmidt told them. "I did not believe that the company was strong enough to withstand a browser war," he says. "It was important that our strategic aspirations be relatively under the radar." Nonetheless, the idea persisted — and rumors percolated. After a 2004 New York Times article quoted "a person who has detailed knowledge of the company's business" saying a browser was in the works, Schmidt had to publicly deny it.
But behind the scenes, the subject remained a running argument between Schmidt and the founders. As a kind of compromise, Google assembled a team to work on improvements for the open source browser Firefox, spearheaded by browser wizards Ben Goodger and Fisher. (Both had worked with Mozilla, the nonprofit organization behind Firefox.) Another hiring coup came when Linus Upson, a 37-year-old engineer whose pedigree includes a stint at NeXT, signed up as a director of engineering. "This was very clever on Larry and Sergey's part," Schmidt says, "because, of course, these people doing Firefox extensions are perfectly capable of doing a great browser."
Sure enough, in the spring of 2006, the Firefox group began talking among themselves about designing a new app. They loved Firefox — but they recognized a flaw in all current browsers.
When Microsoft's Internet Explorer and the codebase at the heart of Firefox were originally conceived, browsing was less complex. Now, however, functions that previously could be performed only on the desktop — email, spreadsheets, database management — are increasingly handled online. In the coming era of cloud computing, the Web will be much more than just a means of delivering content — it will be a platform in its own right. The problem with revamping existing browsers to accommodate this concept is that they have developed an ecology of add-on extensions (toolbars, RSS readers, etc.) that would be hopelessly disrupted by a radical upgrade. "As a Firefox developer, you love to innovate, but you're always worried that it means in the next version all the extensions will be broken," Fisher says. "And indeed, that's what happens." The conclusion was obvious: Only by building its own software could Google bring the browser into the cloud age and potentially trigger a spiral of innovation not seen since Microsoft and Netscape one-upped each other almost monthly.
CHROME: HERE'S WHAT SHINES
Google wanted a browser optimized for cloud computing, with a design emphasis on simplicity and speed. Key features:
- Speed
Blazing fast JavaScript engine opens the door to more advanced Web applications. - Navigation
The "omnibox" combines the search and address boxes, and pop-up thumbnails show your most-visited destinations. - Availability
The open source software was launched in over 40 languages, but Windows only; Mac and Linux versions are in the works. - Reliability
Tabs run in isolation, so if one crashes, no others are affected. Also, you can drag tabs to create new windows. - Privacy
Browsing history is now searchable and editable; incognito mode offers private surfing.
One key change they had in mind was something called a multiprocess architecture, the system that helps the computer keep going when an application crashes or freezes. Why not extend that idea to browsers, so if something crashes in a tab, the other tabs are unperturbed? Also, for that matter, why not set things up so that you can drag an existing tab to create a new window? Starting from scratch had other advantages. You could design it to look cleaner and run faster, the twin dogmas of the Google corporate religion.
Around June 2006, Goodger, Fisher, and another former Mozillan named Brian Ryner cooked up a small prototype. Their first big decision involved the choice of a rendering engine, the software that processes the HTML code of a Web page into the stuff that appears on your screen. The two major open source options were Gecko, used by Firefox, and WebKit, which powers Apple's Safari browser. The word was that WebKit (which had already been adopted by the group developing Google's Android mobile operating system) could be nasty fast — three times as fast as Gecko, in one example.
In a few weeks, they had a simple application running WebKit on Windows that kept going even when a Web page crashed a tab. Early on, Goodger recalls, "our prototypes had a picture of a little tab that was unhappy, and if a tab died you'd see that. It was the first piece of personality in the product."
Not long after that, Brin and Page came by to check in on the furtive beginnings of their browser. "I remember sitting at my desk, which at the time had a stuffed snake running along the back of it," says Pam Greene, an engineer on the team. "Sergey was bouncing on one of those exercise balls, watching Darin give a demo, and petting the snake."
No one will say exactly when the browser project got the official green light. Pichai recalls an executive meeting when Schmidt no longer seemed as opposed as he had been. If Google did go for it, the CEO said, the team had to produce something very different from Explorer and Firefox. In addition, a Google browser would have to be fast, and it would have to be open source. Which, of course, was exactly what the team already had in mind.
In any case, by the autumn of 2006 the line between unofficial concept and formal project had been crossed. "One Friday, there was a meeting called with like an hour's notice," engineer Brett Wilson says. "We were told, 'The management is thinking about doing our own browser — what do you think about that?' Everybody was a combination of excited and freaked out." Part of the freak-out was they knew full well that building a competitive browser was a massive undertaking. There were also mixed feelings because of the group's attachment to Firefox, an icon of open source development and a hedge against Microsoft's dominance. "The fear was that people were going to read this as sabotaging Firefox," says Erik Kay, an engineer who joined the team in October 2006. The Googlers were mollified by the fact that their browser would be 100 percent open source: Google's innovations could potentially find their way into the Mozilla codebase. "We really want to make Firefox successful, as well as other open source browsers," Upson says.
As part of Google's Firefox effort, Pichai had been meeting with Mozilla head Mitchell Baker, and at some point he told her about Google's project. Baker now says a Google browser is a mixed bag for Mozilla and Firefox. She sees the effort as a vindication of Mozilla's belief that browser choice is essential. "If Google comes up with some good new ideas, that's really great for users," she says. "Competition spurs the best in us." But she also understands that many of her users will download Google's app. "We expect people will try it and come back," she says. "Mozilla exists because independence is important."
The Illustrated History: To introduce Chrome and its development team, Google asked noted artist Scott McCloud to create a 32-page comic (available online) that depicts the browser's two-year gestation and special features.
A less weighty issue was what to dub the product. After considering some ridiculous codenames (Upson says they were so awful that he took the un-Googly step of a top-down veto), the project borrowed its moniker from the term used to describe the frame, toolbars, and menus bordering a browser window: chrome.
One more hire was key. Because Chrome was supposed to be optimized to run Web applications, a crucial element would be the JavaScript engine, a "virtual machine" that runs Web application code. The ideal person to construct this was a Danish computer scientist named Lars Bak. In September 2006, after more than 20 years of nonstop labor designing virtual machines, Bak had been planning to take some time off to work on his farm outside Århus. Then Google called.
Bak set up a small team that originally worked from the farm, then moved to some offices at the local university. He understood that his mission was to provide a faster engine than in any previous browser. He called his team's part of the project "V8." "We decided we wanted to speed up JavaScript by a factor of 10, and we gave ourselves four months to do it," he says. A typical day for the Denmark team began between 7 and 8 am; they programmed constantly until 6 or 7 at night. The only break was for lunch, when they would wolf down food in five minutes and spend 20 minutes at the game console. "We are pretty damn good at Wii Tennis," Bak says.
They were also pretty good at writing a JavaScript engine. "We just did some benchmark runs today," Bak says a couple of weeks before the launch. Indeed, V8 processes JavaScript 10 times faster than Firefox or Safari. And how does it compare in those same benchmarks to the market-share leader, Microsoft's IE 7? Fifty-six times faster. "We sort of underestimated what we could do," Bak says.
Speed may be Chrome's most significant advance. When you improve things by an order of magnitude, you haven't made something better — you've made something new. "As soon as developers get the taste for this kind of speed, they'll start doing more amazing new Web applications and be more creative in doing them," Bak says. Google hopes to kick-start a new generation of Web-based applications that will truly make Microsoft's worst nightmare a reality: The browser will become the equivalent of an operating system.
Google also brought in reinforcements to implement the multiprocess architecture that allowed each open tab to run like a separate, self-contained program. In May 2007, it acquired GreenBorder Technologies, a software security firm whose technology was designed to isolate IE and Firefox activities into virtual sessions, or "sandboxes," where malware intrusions couldn't mess with other activities or data on your computer. When the deal was announced publicly, tech pundits wondered whether it meant that Google was going into the antivirus business. Only after the acquisition did GreenBorder's engineers learn that their job was to construct sandboxes for the tabs of a new browser. "It was confusing," says Carlos Pizano, one of the GreenBorder hires. "They would not say what they wanted to sandbox."
The team was growing, but the process never got bogged down in bureaucracy. In the project's early stages, Chromers would all have lunch together at a table in one of the Google cafés. Soon even the largest table couldn't accommodate them all. Working in an open source spirit, every engineer was free to check out any piece of code and tweak or improve it. Rakowski always tried to keep things light, one day awarding tins of chrome polish to the best bug catchers.
As the plumbing aspects of the product fell into place, activity focused on user interface. From the beginning, the Chrome team hoped that its visual presentation would be so understated that people wouldn't even think they were using a browser. The mantra became "Content, not chrome," which is sort of weird given the name of the browser. ("We've learned to live with the irony," Mark Larson says.) The clearest expression of this comes when you drag a tab containing a Web application like Gmail to its own separate window and specify that you want an "app shortcut." At that point, the tabs, buttons, and address bars fall away and the Web app looks pretty much like a desktop app. Welcome to the cloud era.
Any tab in Chrome can be dragged out to start a new window.
When deciding what buttons and features to include, the team began with the mental exercise of eliminating everything, then figuring out what to restore. The back button? No-brainer. The forward button? Less essential, but it survived. But if you're a big fan of the browser status bar — that meter that tells you what percent of a page has loaded — you're out of luck with Chrome.
And then there was the bookmarks bar. At first, engineers thought they could kill it. Chrome introduces several new navigation methods, including one where the browser figures out where you want to go next with no typing required. And when you do type something in, you use the "omnibox," a combination of address bar and search box: Just tell it what you're thinking and it delivers a Web address, search results, or popular destinations that fit your query, all in non-intrusive text underneath the box. It's a bulked-up version of "I'm Feeling Lucky." Still, user tests showed that some people just love to navigate by clicking on the bookmark bar. The compromise: If the user has previously configured the bar in IE or Firefox, Chrome will import the setup. Otherwise, users won't have a bookmark bar unless they choose to.
It's incredible that something as potentially game-changing as a Google browser has stayed under wraps for two years. It wasn't until mid-2007, about a year into the project, that the team let employees outside the group even see what they were doing. At the first of a series of Tech Talks featuring the current prototype (events designed, in part, as a way of recruiting internally for the ever-growing team) the reaction was volcanic. Googlers broke into spontaneous applause when various features, like dragging a tab into a new window, were demo'd. As the number of people who knew about Chrome increased, the inevitable occurred — word did leak out to a blog or two, yet nothing came of those stray items. No reporter put it all together. "I think it was because rumors about Google browsers have been around so long — it's like sightings of Bigfoot or the Loch Ness Monster," Upson says.
On the eve of the launch, Pichai shares some of his ambitions for Chrome. How many people will use it? "Many millions," he says. "I want my mom to use it. I want my dad to use it." The Google imprimatur doesn't assure success, but Pichai believes that even if Chrome doesn't snare huge market share, its innovations will improve the landscape. "We benefit directly if the Web gets better," he says.
As launch approaches, the team has just moved into new space in a freshly renovated building on the Google campus, and there's another all-hands gathering in the biggest conference room available. It's standing room only. Milk and cookies are provided. After some initial business, Rakowski hands the floor over to Goodger. The rumpled engineer talks about the benefits of making Chrome an open source product — the code will be publicly released and a community will emerge to determine the browser's evolution. "We'll be able to scale our testing efforts," he says. "It'll enable people to do things we haven't thought of. And it'll generate trust that we're not doing something evil."
As the meeting breaks up, the energy level is over the top, and not just because of the sugar rush. The Chrome team is close to unleashing the product that Google was destined to create. First, though, there are five bugs to swat.
Senior writer Steven Levy (steven_levy@wired.com) also writes about Jay Walker's in the October issue of Wired.
