Security is one of our core values, alongside speed, stability and simplicity. From day one, we’ve designed Chrome’s extension system with security in mind. Since we launched the extension system, the state of the art in web security has advanced with technologies like Content-Security-Policy (CSP). Extension developers have been able to opt into these features, and now we’re enabling these security features by default.

Unfortunately, securing extensions with CSP by default is incompatible with the legacy extension system. We’re passionate about extension compatibility, so we’re going to make this change gradually to minimize pain for users and developers.

Users can continue to install extensions that are available in the store regardless of whether they are secured with CSP or not. This means they will not lose any of the functionality they've added to Chrome.

Developers will be able to choose when to enable the new behavior. To ease the transition, we've introduced a new manifest version attribute in the extension manifest in Chrome 18 (currently in beta). When a developer updates his or her extension to use manifest_version 2, Chrome will enforce the following CSP policy by default:

script-src 'self'; object-src 'self' 

This policy imposes the following restrictions on extensions:

1. Extensions can no longer use inline scripts, such as <script> ... </script>. Instead, extensions must use out-of-line scripts loaded from within their package, such as <script src="foo.js"></script>. 
2. Extensions can no longer use eval(). Note: If you’re using eval to parse JSON today, we suggest using JSON.parse instead. 
3. Extensions can load plug-ins, such as SWF files, only from within their package or from a whitelist of HTTPS hosts. 

A recent study from researchers at UC Berkeley suggested that these restrictions, taken together, would substantially improve the security of the extension system:

These defenses are extremely effective: adopting one of the recommended CSPs would prevent 96% (49 out of 51) of the core extension vulnerabilities we found. 

For most extensions, updating them to manifest_version 2 will require the developer to move inline scripts out-of-line and to move scripts loaded from the network into the extension package. Developers are not required to update their extensions to manifest_version 2 immediately, but, over time, more of the extension ecosystem will encourage developers to update their extensions. For example, at some point, we’ll likely start requiring new extensions uploaded to the web store to use manifest_version 2. You can find a complete list of changes and more details about CSP in the extension documentation.

We expect these changes will make the security of Chrome’s extension system even better. If you have any feedback, please feel encouraged to email the extension developers mailing list.


Posted by Adam Barth, Chrome Security Engineer

This year at the CanSecWest security conference, we will once again sponsor rewards for Google Chrome exploits. This complements and extends our Chromium Security Rewards program by recognizing that developing a fully functional exploit is significantly more work than finding and reporting a potential security bug.

The aim of our sponsorship is simple: we have a big learning opportunity when we receive full end-to-end exploits. Not only can we fix the bugs, but by studying the vulnerability and exploit techniques we can enhance our mitigations, automated testing, and sandboxing. This enables us to better protect our users.

While we’re proud of Chrome’s leading track record in past competitions, the fact is that not receiving exploits means that it’s harder to learn and improve. To maximize our chances of receiving exploits this year, we’ve upped the ante. We will directly sponsor up to $1 million worth of rewards in the following categories:

$60,000 - “Full Chrome exploit”: Chrome / Win7 local OS user account persistence using only bugs in Chrome itself.

$40,000 - “Partial Chrome exploit”: Chrome / Win7 local OS user account persistence using at least one bug in Chrome itself, plus other bugs. For example, a WebKit bug combined with a Windows sandbox bug.

$20,000 - “Consolation reward, Flash / Windows / other”: Chrome / Win7 local OS user account persistence that does not use bugs in Chrome. For example, bugs in one or more of Flash, Windows or a driver. These exploits are not specific to Chrome and will be a threat to users of any web browser. Although not specifically Chrome’s issue, we’ve decided to offer consolation prizes because these findings still help us toward our mission of making the entire web safer.

All winners will also receive a Chromebook.

We will issue multiple rewards per category, up to the $1 million limit, on a first-come-first served basis. There is no splitting of winnings or “winner takes all.” We require each set of exploit bugs to be reliable, fully functional end to end, disjoint, of critical impact, present in the latest versions and genuinely “0-day,” i.e. not known to us or previously shared with third parties. Contestant’s exploits must be submitted to and judged by Google before being submitted anywhere else.

Originally, our plan was to sponsor as part of this year’s Pwn2Own competition. Unfortunately, we decided to withdraw our sponsorship when we discovered that contestants are permitted to enter Pwn2Own without having to reveal full exploits (or even all of the bugs used!) to vendors. Full exploits have been handed over in previous years, but it’s an explicit non-requirement in this year’s contest, and that’s worrisome. We will therefore be running this alternative Chrome-specific reward program. It is designed to be attractive -- not least because it stays aligned with user safety by requiring the full exploit to be submitted to us. We guarantee to send non-Chrome bugs to the appropriate vendor immediately.

Drop by our table at CanSecWest to participate and check the latest news.

Posted by Chris Evans and Justin Schuh, Google Chrome Security Team

Cross posted to the Google Code Blog

An attractive feature of Web programming is a rapid development cycle. Reloading the application after the source code has changed takes a fraction of a second. We want to offer you that same experience when using Dart, and today we’re making Mac and Linux binaries available that integrate the Dart VM into Chromium.

This technology preview allows you to run your Dart programs directly on the Dart VM in Chromium and avoid a separate compilation step. Over time, these programs will take advantage of the VM’s faster performance and lower startup latency.

Dart has been designed from the start to work with the entire modern web, and we’re simultaneously continuing to improve our fast Dart-to-JavaScript compiler. Both the Dart VM and modern JavaScript engines are first-class targets for Dart.

This release of Chromium with Dart VM integration is a technology preview, and should not be used for day-to-day browsing. After more testing and developer feedback, we plan to eventually include the Dart VM in Chrome.

Today’s release of the Chromium + Dart VM integration is another step forward for the open source "batteries included" Dart platform. Our goal is to help you build complex, high performance apps for the modern web, and we encourage you to try Dart and let us know what you think.

 Posted by Anton Muhin, Vijay Menon, and Pavel Podivilov, Software Engineers

When we launched the Chrome Web Store a year ago, our app taxonomy system reflected the apps that were available in the store at the time. However, since then, the store’s app inventory has grown and changed in composition. So, yesterday we made important changes in the Chrome Web Store’s app category system to allow more great apps of all kinds to stand out.

Until now, you could list your app into two categories. With the new category structure, we will show your app only in the primary category that you select for your app in the developer dashboard. We've found that secondary app categories contributed to a confusing experience for Chrome users and developers so from now on, we're going to start ignoring the secondary category.

We also updated the list of top level app categories and created multiple sub categories in each of them.

More specifically, given the growing use of Chrome and Chromebooks in large and small businesses, we created a new category called “Business Tools” that can help enterprise focused developers target these users. Also, “Shopping” has been reclassified as a subcategory, within the “Lifestyle” category.

The new structure of the store will improve discoverability for apps. For example, users searching for a photo album app can now easily drill down to the “Photos” subcategory level and track down the app they are looking for. At the same time, apps assigned to a subcategory show up in the category page as well giving them wider exposure; an app in "Photos" will appear on both the "Photos" page and the "Entertainment" page.

The categories will continue to evolve over time. To that effect, in the Developer Dashboard you will see a few more subcategory options than the ones that are live in the Chrome Web Store today. We plan to expose these subcategories to users once we confirm we have enough interesting apps in each one of them. In the meantime, items assigned to these subcategories will show up at a related subcategory. For example all items on “Online Documents & File Storage” will show up for now in “Office Tools”.

This transition required our team to take a stab at automatically assigning all apps to one of our new categories / subcategories. Please take a look at the developer dashboard and make sure the placement of your app accurately reflects your business goals and the experience you offer.

Learn more about these category changes on our developer site. If you have any questions about these changes, please don't hesitate to post to our developer forum.


Posted by Jia Tam, Software Engineer

All good things come in threes. So, this week, the Chrome Developer Relations team is releasing three new resources for developers.

First, we are making available a brand new Field Guide to Web Applications, to help developers create great web apps. This guide walks you through topics like app design fundamentals, tips for creating great experiences and a few case studies that put the best practices to use. Whether you're building your first web app or are just looking for ways to improve your existing apps, we hope you'll find the field guide useful.


Second, our popular HTML5 site, HTML5Rocks.com, was also remodeled to better organize the site's content. You’ll now find new "persona pages" with catered content in 3 different verticals (Games, Business, Mobile). In addition, we consolidated many of the different components, and deeply integrated the HTML5 technology classes to bring a better identity to the site.

Finally, we've also joined Google+ with a new page specifically for Chrome Developers. Whether you’re building modern web apps, using Dart or WebRTC, we’ll be there to help you! Keep your eyes open for our weekly hangouts and add us to your circles.

Posted by Eric Bidelman & Pete LePage

The ECMA committee is working hard on designing the next version of JavaScript, also known as "Harmony". It is due by the end of next year and it is going to be the most comprehensive upgrade in the history of this language.

Chrome and V8 are committed to pushing JavaScript forward and have already started implementing the new features. You can try some of them today in the latest dev channel release. Here’s a summary:

• Lexical scoping. Now "let" is the new "var" – traditional "var" declarations are complemented with "let" and "const". Both are properly block-scoped bindings, eliminating a common source of errors and weird behaviour. Function declarations are now officially allowed in local scope as well, and also obey lexical scoping. (Note: Lexical scoping is only available in ES strict mode.)

• Collections. Efficient maps and sets will make your life easier. Any value can be used as a key or element, including objects. No surprises, no more need to abuse objects as dictionaries. (Caveat: Iteration over collections is not yet specified.)

• Weak maps. A special kind of map for which the garbage collector determines when a key is no longer reachable, so that the key-value pair can be removed from the map automatically. This goes a long way towards avoiding memory leaks in long-lived tables and relieves the developer from worrying about stale entries.

• Proxies. A proxy simulates a JavaScript object or function, and can customize just about any aspect of their behaviour that you can imagine. This is a real power feature, that takes reflection to a new level and can be used to implement various advanced abstractions and interfaces. 

 ...and there is a lot more to come, as the V8 team will continue working on bringing new Harmony features to you.

To enable Harmony features in the latest dev channel release of Chrome, go to chrome://flags and toggle on "Experimental JavaScript features". We encourage you to try them out and give us feedback!

Posted by Andreas Rossberg and Michael Starzinger, Software Engineers

Today’s Beta release brings 2D Canvas improvements and a software rasterizer to Chrome.

For most Windows and Mac users, we’ve enabled GPU-accelerated rendering of 2D Canvas content, so that canvas-based games and animations run faster and feel smoother. You can go to chrome://gpu to see which features are being accelerated. This is a tricky area to optimize, due to the wide variety of hardware and operating system configurations found in the wild. We’ve made a series of small improvements to the way this acceleration works in the latest release, and we're seeking feedback on it from our Beta users. If you notice performance problems with 2D Canvas graphics content, particularly if you’re a web developer using 2D Canvas on your site, please file a bug.

At the same time, we recognize that many people with older GPUs and graphics drivers have not been able to experience the rich content provided by technologies such as WebGL. Chrome is now able to display 3D content via SwiftShader, a software rasterizer we licensed from TransGaming, Inc. Although SwiftShader won’t perform as well as a real GPU, it will be an improvement for many of our users on older operating systems such as Windows XP.

SwiftShader automatically kicks in for those users who cannot run content on the GPU. If you want to take a peek at what the performance is like with SwiftShader, you can use the --blacklist-accelerated-compositing and --blacklist-webgl flags, wait a few minutes for the automatic download to complete, and then load the relevant web page.

As always, we appreciate your willingness to try out our creaky Beta software and look forward to your feedback and bug reports.

Posted by John Bauman and Brian Salomon, Software and Pixel Engineers

It’s hard for us to believe, but it’s been just over two years since we first announced the Chromium Security Rewards Program.

We’ve been delighted with the program’s success; we’ve issued well over $300,000 of rewards across hundreds of qualifying bugs, all of which we promptly fixed. It also helped inspire a wave of similar efforts from companies across the web, including Google’s own vulnerability reward program for web properties, which has also been a big hit.

We’ve been fascinated by the variety and ingenuity of bugs submitted by dozens of researchers. We’ve received bugs in roughly every component, ranging from system software (Windows kernel / Mac OS X graphics libraries / GNU libc) to Chromium / WebKit code and to popular open source libraries (libxml, ffmpeg). Chromium is a more stable and robust browser thanks to the efforts of the wider security community.

Today we’re expanding the scope of the Chromium program to formally include more items that deserve recognition:

• High-severity Chromium OS security bugs are now in scope. Chromium OS includes much more than just the Chromium browser, so we’re rewarding security bugs across the whole system, as long as they are high severity and present when “developer mode” is switched off. Examples of issues that may generate a reward could include (but are not limited to): 
• Renderer sandbox escapes via Linux kernel bugs. 
• Memory corruptions or cross-origin issues inside the Pepper Flash plug-in. 
• Serious cross-origin or memory corruption issues in default-installed apps, extensions or plug-ins. 
• Violations of the verified boot path. 
• Web- or network-reachable vulnerabilities in system libraries, daemons or drivers.

Chromium OS security bugs should be reported in the Chromium OS bug tracker, whilst security bugs affecting the desktop Chromium browser should be reported in the Chromium bug tracker.

• We may elect to issue “bonuses” ranging from $500 to $1000 if a bug reporter takes on fixing the bug they have found themselves. For eligibility, this process involves working with the Chromium community to produce a peer reviewed patch. These bonuses are granted on top of the base reward, which typically runs between $500 and $3133.70. 

• The base reward for a well-reported and significant cross-origin bug (for example a so-called UXSS or “Universal XSS”) is now $2000. 

Perhaps most importantly, this program reflects several of our core security principles: engaging the community, building defense in depth, and particularly making the web safer for everyone.

Related to this third core principle, we’re particularly excited by all the work that has been done on shared components. For example, a more robust WebKit not only helps users of two major desktop browsers, but also a variety of tablet and mobile browsers.

Posted by Chris Evans, Google Chrome Security

Today, we introduced Chrome for Android Beta, which brings Chrome’s capabilities to phones and tablets running Android 4.0, Ice Cream Sandwich. This is made possible by a range of innovative features and by building a mobile browser from the ground up that makes full use of the underlying architecture built into Android 4.0.



Chrome for Android brings support for many of the latest HTML5 features to the Android platform. With hardware-accelerated canvas, overflow scroll support, strong HTML5 video support, and new capabilities such as Indexed DB, WebWorkers and Web Sockets, Chrome for Android is a solid platform for developing web content on mobile devices.

In addition to support for the latest web technologies, we hope to make interactive web content super easy to develop. Chrome for Android introduces remote debugging through Chrome Developer Tools to make it simple for developers to debug web sites running live on their mobile devices.

Much of the code for Chrome for Android is already shared with Chromium and over the coming weeks, the Chromium team will be upstreaming many new components developed for Chrome for Android to Chromium, WebKit and other projects.

We’ve got a lot more planned to make Chrome as feature-rich on mobile devices as it is on the desktop. We encourage you to follow any of the ongoing development via the issue tracker or join in on chromium-dev@chromium.org.

Posted by Arnaud Weber, Engineering Manager, Chrome