Years ago, I remember watching a webcast of the introduction of the Aqua user interface when Mac OS X Public Beta was first demoed. The part I distinctly remember was realizing the brilliance of sheets. Like many great innovations, they were simple in retrospect and solved a problem you didn't realize you had: the modality problem — the fact that dialog boxes blocked interacting with the whole application even though only one window needed the information that you, as the user, had to provide. I watched in wonder as a save dialog blocked only the one window that needed saving, leaving all the other windows free. Finally, a solution to limit the modality.

Because modality sucks.

Back in 2000, sheets worked well because the smallest unit of user interaction with an application was a window. Soon after, though, things started to change. Web browsers in particular were among the first to start using tabs to put more than one document in a window. This caused a snag. A web page can require modal interaction from the user: picking a file, or supplying a username and password. Yet we don't want to prevent the user from switching to a different tab and continuing to interact with other websites. If the finest-grained modality control we have is per-window, how can we achieve that outcome?

Chromium's current answer comes from combining Cocoa's child window support with sheets to get tab-modal sheets:

While this looks like a normal sheet, you can switch between open tabs while the password request is up. You can't, however, interact with the web page.

The implementation, like all of the code used in Chromium, is open source, and can be found in the Google Toolbox for Mac, a collection of reusable components from the Mac developers at Google. The technical details of the GTMWindowSheetController can be found on the Google Mac blog. The other thing to note is that right now tab-modal sheets are only used for website authentication. The other sheets we use (for file selection, etc) are currently window-modal; we hope to convert them over soon.

The fate of tab modal sheets, however, isn't certain. A way to enforce tab-modal interaction is certainly needed. But is attaching sheets to the tabs the right way to achieve that goal? At the last WWDC, I talked to some graphic designers who were opposed to the idea. "Reusing sheets in a context that isn't window modality will only confuse the user!" On the other hand, my position is that the concept of modality is the same, and the context is similar enough that users will find that sheets help them understand the modality in which they must interact.

So the story isn't over. Tab-modal sheets are our contribution to the ongoing discussion, an experiment to see what works and what doesn't. Together we can work out the best way to help users interact with their computers.

Posted by Avi Drissman, Software Engineer

The seven days since our beta launch have been busy and exciting for the Google Chrome Extensions team.

Besides having fun trying out some of the 800+ new extensions in our gallery, we hosted an event for developers on our Mountain View campus to discuss the design principles of the Google Chrome's extensions system and to present the team's roadmap. Approximately 140 developers attended, representing more than 50 companies. Aaron Boodman and Erik Kay, technical leads for the extensions platform, provided insights across several topics, including the UI design and the security model for the extensions system. They also demonstrated the platform's flexibility by building and publishing an "Email this page" extension in less than 5 minutes.





Aaron and Erik were joined on stage by the Xmarks, eBay and Google Translate teams, who discussed their own experiences with Google Chrome Extensions, highlighting the ease of development and the advanced capabilities that HTML5 provides to extension developers. Finally, Nick Baum, product manager for Google Chrome Extensions, closed the event by walking through the extensions gallery approval process, tips for successful extensions, as well as the team's near-term goals.

To learn more on these topics you can check out the videos from the event below:



We also met many extensions developers last week at Add-on Con, an annual conference for browser add-ons. Erik and Aaron presented a quick overview of the extension system's design for those who had missed our earlier event. In addition, Aaron shared his thoughts on a panel about cross-browser extension development while Linus Upson, Google's engineering lead for client products, presented his views on a panel about the future of the browser.

We'd like to thank developers for building and uploading some great extensions in our gallery and for giving us plenty of feedback. This week, we plan to continue our discussions with the developer community by hosting several online tutorial sessions. You can still sign up for one of these sessions, but if you aren't able to attend, we encourage you to submit your questions through our discussion group.

Posted by Arne Kurrik, Developer Advocate, Google Chrome Extensions

In our earliest discussions about the extension system, we knew we wanted to raise the bar for security, but how can we secure the platform while still letting developers create awesome extensions that have rich interactions with web pages? During our threat analysis, we realized there were two main security concerns: malicious extensions and "benign-but-buggy" extensions.

A malicious extension is an extension written by an ill-intentioned developer. For example, a malicious extension might record your passwords and send them to back to a central server. The tricky part about defending against malicious extensions is that there are well-intentioned extensions that do exactly the same thing. Our defenses against malicious extensions focus on helping the user avoid installing malicious extensions in the first place:

1. We expect most users to install extensions from the gallery, where each extension has a reputation. We expect malicious extensions will have a low reputation and will have difficulty attracting many users. If a malicious extension is discovered in the gallery, we will remove it from the gallery.
   
   
2. When installing extensions outside the gallery, the user experience for installing an extension is very similar to the experience for running a native executable. If an attacker can trick the user into installing a malicious extension, the attacker might as well trick the user into running a malicious executable. In this way, the extension system avoids increasing the attack surface.

To help protect against vulnerabilities in benign-but-buggy extensions, we employ the time-tested principles of least privilege and privilege separation. Each extension declares the privileges it needs in its manifest. If the extension is later compromised, the attacker will be limited to those privileges. For example, the Gmail Checker extension declares that it wishes to interact with Gmail. If the extension is somehow compromised, the attacker will not be granted the privilege to access your bank.

To achieve privilege separation, each extension is divided into two pieces, a background page and content scripts. The background page has the lion's share of the extensions privileges but is isolated from direct contact with web pages. Content scripts can interact directly with web pages but are granted few additional privileges. Of course, the two can communicate, but dividing extensions into these components means a vulnerability in a content script does not necessarily leak all the extension's privileges to the attacker.

Finally, we utilize our multi-process architecture and sandboxing technology to provide strong isolation between web content, extensions, and the browser. Extensions run in a separate operating system process from the browser kernel and from web content, helping prevent malicious web sites from compromising extensions and malicious extensions from compromising the browser kernel. To facilitate rich interaction, content scripts run in-process with web content, but we run content scripts in an "isolated world" where they are protected from the page's JavaScript.

Of course, attackers will write malicious extensions and well-intentioned developers will write buggy extensions. The extension system improves security by making it easier for developers to write secure extensions. If you would like to learn more about the security of the extension system, you can watch our video or read our academic paper describing all the details.

Posted by Adam Barth, Software Engineer

I'm excited to announce four new tech talks on the guts of Chromium have been posted to YouTube! These should be especially useful for developers who work on Chromium whether they're fairly new to the project or have been around the block.

We've done tech talks before, but this time we asked Chromium developers what they'd most like to hear about. Once we knew what was most in demand, we found experts on each subject and asked them to make a presentation. The talks were given before a live studio audience of Googlers last Friday with extra attention paid to creating high quality recordings. Now we're excited to make these widely available to all Chromium contributors!

The WebKit API

with Darin Fisher

Darin Fisher talks about the recently upstreamed Chromium WebKit API. The API is a critical step in our path to becoming completely integrated into the WebKit project. Like the other WebKit APIs, ours is a veneer which shields developers (including many of our own) from the internal details of WebKit (named WebCore). Darin talks at a high level about the API, dives into some code examples, and talks about the history and future of the API.

Layout Tests

with Pam Greene

Layout Tests are the tests we inherit from the WebKit project and are a very important part of the Chromium's testing infrastructure. Pam Greene talks about what they are, how to run them, how to debug problems within them, and even touches on how to write your own. She also covers advanced (but easy to use) tools for rebaselining and tracking flakyness. Any Chromium developer that works on WebKit really should check this out!

Painting in Chromium

with Brett Wilson

Because of Chromium's multi-process architecture, painting within Chromium is far from typical. In this talk, Brett Wilson starts from Skia and the WebKit render tree, follows the bits across the process boundaries, and continues all the way to your screen. He also details many of the differences in painting between platforms, how things work in test shell, and interesting corner cases like resizing.

WebKit's Guts

with Eric Seidel

A large percentage of Chromium's code (and part of what makes it so fast) is WebKit. In this talk, Eric Seidel gives us a 30,000 foot view of how WebKit actually renders a page. He starts with how resources are loaded, explains how they're parsed into a DOM tree, and then talks about the various trees involved in rendering. In addition, he touches on many other important topics like hit testing (figuring out what you're hovering over and clicking on). This is a must-see for anyone working on the guts of WebKit.

Also note that all the tech talks are posted to the Chromium developer website.

Posted by Jeremy Orlow, Software Engineer

The last couple of weeks since we open sourced Chromium OS have been pretty exciting. The discussion groups have been buzzing and a number of sites have put up Chromium OS builds for download. While we're happy that developers have been building Chromium OS there are a few things we would like to clarify:

1. This is not ready for consumers yet — everything you see can and probably will change by the time Google Chrome OS-based devices are available late next year.
2. Please note that Google has not released an official binary for Chromium OS and therefore if you download Chromium OS binaries please ensure that you trust the site you are downloading them from.
3. While we will try our best to help you through the Chromium discussion forums, we will not be officially supporting any of these builds. Remember that you are downloading that specific site/developer's build of Chromium OS.

We have also received a number of questions that we wanted to answer directly and so we put together the following FAQ to clarify some of these issues.

One of the top questions has been around the distinction between Google Chrome OS and Chromium OS. Google Chrome OS is to Chromium OS what Google Chrome browser is to Chromium. Chromium OS is the open source project, used primarily by developers, with code that is available for anyone to checkout, modify and build their own version with. Meanwhile, Google Chrome OS is the Google product that OEMs will ship on Netbooks next year. Therefore, dear developers who have built and posted Chromium OS binaries, you're awesome and we appreciate what you are doing, however we have to ask you to call the binaries you've put up for download "Chromium OS" and not "Google Chrome OS".

Thanks!

Posted by Martin Bligh, Software Engineer

Google is one of the Khronos member companies helping to develop the WebGL specification, bringing hardware accelerated 3D rendering to the web via the Canvas element. Today is the release of the initial public draft of the WebGL spec. We're happy to announce that Chromium contains provisional WebGL support on Linux (32- and 64-bit), Mac and Windows. This implementation was developed in close collaboration with Apple Computer and utilizes much shared code from WebKit.

See Getting a WebGL Implementation for instructions on getting a Chromium build and enabling WebGL support. This is an early version with many caveats, but with it you can get a taste of the new functionality coming to the web.

Here are a few demos to whet your appetite:

• San Angeles futuristic cityscape demo
• Shiny teapot demo illustrating compositing of 3D graphics with the web page
• Particle system demo showing how to use the GPU to animate particles

The WebGL wiki is the central location for information about the evolving specification, including the draft spec, introductory articles, tutorials, mailing lists and forums. See the WebGL demo repository for more demos and instructions on how to check out their source code.

We're looking forward to finalizing the WebGL specification and making this functionality available to web developers, and look forward to your feedback. For Chromium-specific questions, use the Chromium-dev mailing list, for more general WebGL questions, use the WebGL forums or WebGL public mailing list.

Posted by Ken Russell, Software Engineer

Starting in the Google Chrome developer channel release 4.0.249.0, Web Sockets are available and enabled by default. Web Sockets are "TCP for the Web," a next-generation bidirectional communication technology for web applications being standardized in part of Web Applications 1.0. We've implemented this feature as described in our design docs for WebKit and Chromium.

The Web Sockets API enables web applications to handle bidirectional communications with server-side process in a straightforward way. Developers have been using XMLHttpRequest ("XHR") for such purposes, but XHR makes developing web applications that communicate back and forth to the server unnecessarily complex. XHR is basically asynchronous HTTP, and because you need to use a tricky technique like long-hanging GET for sending data from the server to the browser, simple tasks rapidly become complex. As opposed to XMLHttpRequest, Web Sockets provide a real bidirectional communication channel in your browser. Once you get a Web Socket connection, you can send data from browser to server by calling a send() method, and receive data from server to browser by an onmessage event handler. A simple example is included below.

if ("WebSocket" in window) {
  var ws = new WebSocket("ws://example.com/service");
  ws.onopen = function() {
    // Web Socket is connected. You can send data by send() method.
    ws.send("message to send"); ....
  };
  ws.onmessage = function (evt) { var received_msg = evt.data; ... };
  ws.onclose = function() { // websocket is closed. };
} else {
  // the browser doesn't support WebSocket.
}

In addition to the new Web Sockets API, there is also a new protocol (the "web socket protocol") that the browser uses to communicate with servers. The protocol is not raw TCP because it needs to provide the browser's "same-origin" security model. It's also not HTTP because web socket traffic differers from HTTP's request-response model. Web socket communications using the new web socket protocol should use less bandwidth because, unlike a series of XHRs and hanging GETs, no headers are exchanged once the single connection has been established. To use this new API and protocol and take advantage of the simpler programming model and more efficient network traffic, you do need a new server implementation to communicate with — but don't worry. We also developed pywebsocket, which can be used as an Apache extension module, or can even be run as standalone server.

You can use Google Chrome and pywebsocket to start implementing Web Socket-enabled web applications now. We're more than happy to hear your feedback not only on our implementation, but also on API and/or protocol design. The protocol has not been completely locked down and is still in discussion in IETF, so we are especially grateful for any early adopter feedback.

Posted by Yuzo Fujishima (藤島 勇造), Fumitoshi Ukai (鵜飼 文敏), and Takeshi Yoshino (吉野 剛史), Software Engineers

These last few days, it seems that the extensions team has developed a newfound love for the F5 key. We all keep refreshing the "Most recent" page of our new gallery, obsessively checking the newest amazing extensions that developers have uploaded. Today, we get to share this nervous tic with millions of Google Chrome's users. We're launching extensions in the beta channel for Windows and Linux (Mac is in progress). We're also opening our gallery, which, as of now, contains more than 300 extensions!

An extension system has been one of our most requested features for Google Chrome. It's a tribute to Mozilla and the Firefox project that nowadays, users just expect all browsers to have built-in extensibility.

We started the project by presenting a design doc that outlined our vision to create an extensions system based on web technologies - a system that is easy to use, stable, more secure and that wouldn't slow down Google Chrome. It wasn't always easy to balance our goals, and sometimes we had to make tough trade-offs.

Since we built all of this in the open, we had tons of help. Developers started using our code shortly after the first check-in, and have been sending us feedback on our mailing list ever since. Being able to see the extensions people were trying to build and the problems they faced made it more fun to design the system, and motivated us to keep fixing the bugs.

Today, we're really happy to release a beta of extensions that begins to deliver on our initial vision. Extensions are as easy to create as webpages. Users can install and uninstall them quickly without restart, and extensions have a great polished look that fits in with Google Chrome's minimalist aesthetic. When developers upload an extension it is available to users immediately, with limited restrictions and manual reviews only in a few situations.

On the technical side, we've been able to use Google Chrome's multiprocess architecture to help keep extensions stable and safe. And Chromium's extensive performance monitoring infrastructure has helped us ensure extensions affect Google Chrome's speed as little as possible. You can learn more details about the internals of our system in the videos below.



We still have a long way to go - next up, we're going to be working hard to get extensions to all Google Chrome users, and we're already brainstorming the next set of API improvements. Oh and, we should also fix some bugs ;-).

For those of you who want to learn more about extensions, let us know if you want to join us in a small get together tomorrow in our campus in Mountain View. Space is limited - we'd love to see many of you there so do RSVP early and we'll email you more information if are selected to attend. You can also meet with our team at Add-on Con, where we are going to participate in a couple of panels. Finally for those of you who are far away, we are planning some online developer tutorial sessions. If you are interested in attending these, please fill in this form.

Posted by Erik Kay and Aaron Boodman, Software Engineers

Google Chrome for Linux is finally ready for beta. Like the Windows version, it's fast, secure, stable, simple, extensible, and embraces open standards like HTML5.

But bringing Google Chrome to Linux wasn't just a straight port -- it was a labor of love. Google Chrome works well with both Gnome and KDE, and is updated via the normal system package manager. It has also been developed as a true open source project, using public mailing lists, IRC channels, bug tracker, code repository, and continuous build and test farm -- following in large part the trail blazed by Mozilla. Where we noticed problems in system libraries, we pushed fixes upstream and filed bugs. This open approach to development seems to be working: so far, about 50 developers outside Google have contributed code (for instance, thanks to Ibrar and Paweł for our FTP stack), and several Linux distributions even maintain preliminary open source builds of Google Chromium.

In short, we really love Google Chrome for Linux, and we think you will, too. Please try it and let us know what you think.

(One more thing: if you've already installed the dev channel version, you may need to uninstall that before installing the beta version -- we tried to make that work smoothly, but a few rough edges remain.)

Posted by Dan Kegel and Evan Martin, Software Engineers

We've introduced a new way for web developers to take advantage of Google Chrome's multi-process architecture, as of version 4.0.229.1. Google Chrome already uses separate OS processes to isolate independent tabs from each other in the browser, so that crashes or slowdowns in one tab won't affect the others. Google Chrome even switches a given tab's process if you type a different site's URL into the Omnibox.

In many cases, though, Google Chrome needs to keep pages from related tabs in the same process, since they may access each other's contents using JavaScript code. For example, clicking links that open in a new window will generally cause the new and old pages to share a process.

In practice, web developers may find situations where they would like links to other pages to open in a separate process. As one example, links from messages in your webmail client would be nice to isolate from the webmail client itself. This is easy to achieve now, thanks to new support in WebKit for HTML5's "noreferrer" link relation.

To cause a link to open in a separate process from your web page, just add rel="noreferrer" and target="_blank" as attributes to the <a> tag, and then point it at a URL on a different domain name. For example:

<a href="http://www.google.com" rel="noreferrer" target="_blank">Google</a>

In this case, Google Chrome knows that the page will be opened in a new window, that no referrer information will be passed to the new page, and that the window.opener value will be null in the new page. As a result, the two pages cannot script each other, so Chrome can load them in separate processes. Google Chrome will still keep same-site pages in the same process, to allow them to share caches and minimize overhead.

We hope you find this useful on your own sites!

Posted by Charlie Reis, Software Engineer

Earlier this year, we heard from many of you on how important speed is to your daily activities on the web. We kicked off a series of discussions with the Internet community on ways to make the web faster: from Internet protocols and best practices in website development, to improvements in the browser itself.

A lot of engineering effort is involved in making sure that a browser continually provides a fast, responsive, and satisfying experience on the web. We're excited to see modern browsers continue to push the envelope in designing and optimizing browser architecture for speed and performance.

We've often been asked what makes Google Chrome so fast -- from its snappy start-up time and fast page-loading, to the ability to run complex web applications quickly. To walk through some of the thought processes and technical decisions involved in making Google Chrome a fast browser, we've put together three technical interviews on DNS pre-resolution, the V8 JavaScript engine, and DOM bindings. In a future post, we'll also cover other important areas like WebKit and UI responsiveness.

DNS pre-resolution
with Jim Roskind

1. What is DNS pre-resolution, and how does it make Google Chrome even faster?
2. Why is DNS pre-resolution difficult to do?
3. Explain in more detail how adaptive pre-resolution works.
4. How else is DNS pre-resolution beneficial? Can it help with browser start-up time?
5. How do we measure and benchmark the benefits of DNS pre-resolution?
6. What's next for DNS pre-resolution?

V8 JavaScript engine
with Mads Ager

1. What is V8?
2. What are we currently doing to speed up JavaScript performance on V8?
3. How do we achieve big boosts in JavaScript speed, such as the recent 150% improvement since our initial launch?
4. How do we measure V8's performance?

DOM bindings and more
with Mike Belshe

1. What are DOM bindings?
2. What are the most recent improvements in DOM bindings, for Google Chrome as well as other browsers?
3. The Google Chrome beta release in August 2009 included improvements in DOM bindings. Tell us more.
4. How do we measure and benchmark improvements in DOM bindings?
5. In general, what are the biggest performance impediments for a browser?
6. What are some of the performance benefits of Google Chrome's multiprocess architecture?

Posted by Min Li Chan, Product Marketing Manager