We've been hard at work adding proactive security features to Google Chrome, and we're particularly excited about five new security features that make it easier for developers to build secure web sites.

Strict-Transport-Security

Strict-Transport-Security lets a high-security web site tell the browser that it wants to be contacted over a secure connection only. That means the browser will always use HTTPS to connect to the site and will treat all HTTPS errors as hard stops (instead of prompting the user to "click through" certificate errors). This feature strengthens the browser's defenses against attackers who control the network, such as malicious folks disrupting the wireless network at a coffee shop.

Originally proposed in a research paper in 2008, Strict-Transport-Security is now an open specification. In addition to being in Google Chrome 4, Strict-Transport-Security has also been implemented in NoScript, a security add-on for Firefox, and a native implementation is underway in Firefox. A number of high-security web sites have already started to use the feature, including PayPal. As with all of our security improvements, we hope that every browser will adopt Strict-Transport-Security, making the web, as a whole, more secure.

Cross-Origin Communication with postMessage

The postMessage API is a new HTML5 feature that lets web developers establish a communication channel between frames in different origins. Previously, when you wanted to add a gadget to your web page, you had two options: (1) include the gadget via a script tag, or (2) embed the gadget using an iframe tag. If you used a script tag, you could have a rich interaction with the gadget (e.g., the Google Maps API), but you had to trust the gadget author not to inject malicious script into your web page. Alternatively, if you used an iframe tag to embed the gadget (e.g., the Google Calendar web element), you had strong security properties, but it was difficult to interact with the gadget.

postMessage changes the game. By using postMessage to communicate with the gadget, you get the security advantages of an iframe with all the interactivity of a script tag. What's more, you can use postMessage to create more secure versions of existing gadgets. postMessage is now available in the latest versions of all the major browsers: Google Chrome, Internet Explorer, Firefox, Safari, and Opera. A number of web sites, including Facebook, are already using postMessage to make their site safer.

CSRF Protection via Origin Header

The Origin header is a new HTML5 feature that helps you defend your site against cross-site request forgery (CSRF) attacks. In a CSRF attack, a malicious web site, say attacker.com, instructs the user's browser to send an HTTP request to a target server, say example.com, that confuses the example.com server into performing some action. For example, if example.com is a webmail provider, the CSRF attack might trick example.com into forwarding an email message to the attacker.

The Origin header helps sites defend against CSRF attacks by identifying which web site generated the request. In the above example, example.com can see that the request came from the malicious web site because the Origin header contains the value http://attacker.com. To use the Origin header as a CSRF defense, a site should modify state only in response to requests that either (1) lack an Origin header or (2) have an Origin header with a white-listed value.

The details of the Origin header are still being finalized. We will update the implementation in Google Chrome as the specification evolves based on feedback from Mozilla and from the W3C and IETF communities at large. We welcome your feedback on the last draft of the specification.

ClickJacking Protection with X-Frame-Options

First introduced in Internet Explorer 8, X-Frame-Options is a security feature that lets web sites defend themselves against clickjacking attacks. To defend against clickjacking, a web developer can request that a web page not be loaded inside a frame by including the X-Frame-Options: deny HTTP header. X-Frame-Options is implemented in Google Chrome, Internet Explorer 8, and Safari 4.

Reflective XSS Protection

One of the most difficult parts of building a secure web site is protecting against cross-site scripting (XSS) vulnerabilities. In Google Chrome 4, we've added an experimental feature to help mitigate one form of XSS, reflective XSS. The XSS filter checks whether a script that's about to run on a web page is also present in the request that fetched that web page. If the script is present in the request, that's a strong indication that the web server might have been tricked into reflecting the script.

The XSS filter is similar to those found in Internet Explorer 8 and NoScript. Instead of being layered on top of the browser like those filters, our XSS filter is integrated into WebKit, which Google Chrome uses to render webpages. Integrating the XSS filter into the rendering engine has two benefits: (1) the filter can catch scripts right before they are executed, making it easier to detect some tricky attack variations, and (2) the filter can be used by every WebKit-based browser, including Safari and Epiphany.

We are aware of a few ways to bypass the filter, but, on balance, we think that the filter is providing enough benefit to enable it by default in this release. If you discover a new way to bypass the filter, please let us know. We're very interested in improving the filter in subsequent releases. We're grateful to the security researchers who have helped us with the filter thus far (especially Eduardo "Sirdarckcat" Vela), and we welcome even more participation.

Posted by Adam Barth, Software Engineer

This morning, we announced a new stable channel update of Google Chrome. For developers, this update represents some significant advances in terms of extensibility and new HTML and JavaScript APIs. Extensions are now available to all Google Chrome users, which enables you to provide additional functionality not just on your site, but to also bring content and functionality from your site into the browser, regardless of what sites a user may have open at any given time.

Google Chrome also includes a number of new HTML and JavaScript APIs. For instance, we now support the Web SQL Database API, which allows you to store data in a structured manner on the user's computer. If you're looking for a simpler client-side storage mechanism for relatively small amounts of data, check out the localStorage portion of the Web Storage API. We're already working on making these new APIs more useful and you should see a couple of improvements on the developer channel soon. In particular, we're working on Application Cache which gives you the ability to serve HTML and JavaScript that references content in the Web SQL Database. SessionStorage, the little brother of localStorage, is coming soon as well.

Besides working on these four storage focused APIs, we have also implemented WebSockets. This is a new API for sending data over a persistent bi-directional communication channel, designed to be easier, more powerful, and less resource intensive than using XHR. Finally, today we are also making available -- in Windows only -- the new notification API that allows you to present information to users, such as event reminders or status updates, via a panel in the user's status-bar area. This panel allows you to provide more styling than window.alert(). It should also be much less irritating to your users - with this API notifications are still visible but do not get a user's attention by stealing cursor, tab or window focus.

If you have questions about the extensions APIs, the extensions discussion group continues to be the best place to get answers. For the new HTML and JavaScript APIs, we've just created a new Chromium HTML5 group. We're excited about these and the other capabilities we'll be adding soon but we're even more excited to see all of the amazing stuff you'll be creating with them!

Posted by Ian Fette, Product Manager

Starting with Google Chrome developer channel release 4.0.288.1 and beta channel release 4.0.249.64 for Windows, an internationalization (i18n) framework for Google Chrome Extensions is available and enabled by default. This framework lets extension developers translate user-visible parts of the extension manifest — such as the name and description, and localize messages using simple JavaScript calls to the chrome.i18n.getMessage() method. We've implemented this feature as described in the design docs for Chromium.

The following screenshots show a browser action's tooltip that has been translated into English, Spanish, Serbian, and Korean.

To localize the extension manifest, extract all user-visible strings into message catalogs, and define the default locale.

{
"name": "__MSG_name__",
"description": "__MSG_description__",
...
"default_locale": "en",
...
}

To get translated messages in JavaScript code, including extension code and content scripts, invoke one of the following forms of chrome.i18n.getMessage().

chrome.i18n.getMessage("messagename")
chrome.i18n.getMessage("messagename", "one parameter")
chrome.i18n.getMessage("messagename", ["one", "to", "nine", "parameters"])

For more details, see the documentation.

We're more than happy to hear your feedback, not only on our implementation and documentation, but also on the API design. You can reach us at the chromium-extensions group.

Posted by Nebojsa Ciric, Software Engineer

If you've been waiting for extensions to be available for the Mac version of Google Chrome, you finally have a chance to try them out. Extensions are now available on the new developer channel of Google Chrome for Mac. Just like the Windows version, Google Chrome for the Mac again has a developer channel. If you're willing to put up with some rough edges, you can download the developer channel version. You'll be regularly updated to the latest (but not always the greatest) version of Google Chrome for the Mac. If not, sit tight--we're working on bringing extensions to the beta channel.

Note that all of the original developer channel users prior to the Google Chrome for Mac beta release were migrated to the beta channel as a part of the first beta rollout. If you were on the Mac developer channel at some point, you'll have to reinstall the developer channel version just this once.


Posted by Mike Smith, Product Manager

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