Inside Chrome: The Secret Project to Crush IE and Remake the Web

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."