Google I/O is just around the corner and all of us in the Chrome team are looking forward to sharing with you what’s new with the open web.

Starting from June 27, we’ve planned more than 20 sessions and code labs. If you are not joining us in San Francisco, you can still watch some of these sessions by attending one of the 350+ I/O extended events or by simply tuning in to the livestream from anywhere in the world. You can also watch these sessions when you are on the move by downloading the Google I/O mobile app.

All other sessions are going to be recorded. Videos from these sessions will be available after the conference on Google Developers Live and the I/O website.

Finally, you can follow our Google+ page and Twitter account for more behind the scenes coverage.
Let the fun begin!

Posted by Brian Rakowski, (Miami) Vice President Product Management

If you’re a Chrome extensions power user, you may be familiar with a task manager that looks like this:



That’s a lot of extensions running! Most of the time, they’re probably just sitting idle, waiting for the user to interact with them. Do they really need to be running and using your memory all the time?

Over the last several months, we've been working on a new feature for the extension system called Event Pages that we think will help reduce the memory used by these idle extensions. 

How They Work 

Event pages are an evolution of background pages, with one major improvement: rather than running in the background all the time, an event page only runs when it is handling events. Once an event page becomes idle, it is unloaded, freeing memory until the next time it’s needed. Learn more from the event page documentation.

To help event pages support some important use cases, we’re also developing a few new APIs.

• The alarms API allows an extension to wake itself up at set times, to support features like periodically syncing data to the cloud. 
• Some new events let extensions know when they have been installed, or when their event page is being unloaded. 
• A declarative version of the webRequest API lets extensions do network interception without the need for a background page at all. 

Try it Out 

We plan to release event pages to Chrome’s beta and stable channels late this summer, but you can start experimenting with them on the developer channel today. Try converting your overweight extension to event pages, and let us know how it works.

Posted by Matt Perry, Software Engineer

As Chrome Web Store apps and extensions have become more popular, users have been generating a large amount of reviews and feedback for developers. Until now, there was no way to separate a user’s review of an app’s features and quality from developer-focused feedback, such as the reporting of bugs, feature requests, and general questions.

To improve the feedback loop between developers and users, we’ve added a new way to get feedback directly from your users:



This feature provides a clean separation between reporting bugs and compatibility issues to developers and the rating / comments users can leave in the store relating to the functionality and usefulness of a given app. The contents of the feedback forum are publicly visible to everyone, which helps to cut down on duplicate issue reporting.

Turning the Feedback Feature On

In order to enable this feature for your store items, go to your developer dashboard and click on the “Edit your User Feedback preferences” option (highlighted below):



Engaging With Your Users

You should encourage your app’s users to engage with you via the new feedback feature by placing links to your app’s feedback page directly on your site after you’ve activated it. To do so, use the url format “https://chrome.google.com/webstore/support/yourappid”. Doing so will increase the likelihood that users will discover the feature and reinforce the idea that you actively support it.

We hope that this new feature will give users a better experience in reporting issues, requesting new features, and asking questions. Similarly, developers will now have a much easier forum to use to have an ongoing social conversation about their products.

If you have any questions about this new feature, you can reach us on our developer forum.


Posted by Siddhartha Saha, Software Engineer

Cross-posted from the Google Developers Blog

Would you like to use your coding skills to significantly improve the world, and have the chance to win tickets to Google I/O 2013 for your efforts? Google.org has joined forces with the I/O Extended team to bring you the "Develop for Good" Hackathon. We’re looking for hackers to tackle issues around repressive regimes, engaging citizens in politics and enabling us all to be greener!

Almost anyone can participate in the hackathon from just about anywhere in the world. Many of the Extended events are already hosting hackathons, so we encourage you to find an event near you or start your own. If you’re in the San Francisco Bay Area, Google.org will be hosting a ‘Develop for Good’ hackathon at the San Francisco I/O Extended event.

Here are the three challenges developed by the Google teams:

1. Google Ideas: Conflict reporting for blackout situations in repressive regimes.
2. Google Politics & Elections: Citizen Engagement for Politics & Elections.
3. Google Green: Help us all be a little bit greener!

Developers can start preparing, and even coding, right away and then bring their ideas to the Extended event Hackathons during I/O (though we welcome you to participate even if you’re unable to attend an event). Pencils down on Friday night—hacks must be submitted by 11:59 p.m. (PDT) on June 29, 2012 via this form.

After June 29th a team of Googlers will judge the submissions for each challenge. We will announce the winning hacks for each challenge by about August 1st, 2012. There will be one winning hack selected from each challenge area, and each will receive up to 5 tickets to I/O 2013, along with the honorary title of "Google Developer for Good, 2012". In addition, we’ll award one of the latest Chromebooks to each member of the team producing the best web app across all three challenges.

If you are interested in getting involved, we recommend signing up for an I/O Extended event near you and then checking with the organizer to see whether a hackathon is part of the agenda -- or hosting your own Extended event and hackathon!

Find further details of the challenges, prizes, submission guidelines and hackathon rules on the I/O Extended organizers' website.


Posted by Anna de Paula Hanika, Product Marketing Manager

Cross-posted from the Google Developers Blog.

A year ago, we released a preview of the PageSpeed Insights Chrome Developer Tools extension, which analyzes the performance of web pages and provides suggestions to make them faster. Today, we’re releasing version 2.0 of the PageSpeed Insights extension, available in the Chrome Web Store.

PageSpeed Insights analyzes all aspects of a web page load and points out the specific things you can do to make your page faster. For instance, PageSpeed Insights can inform you about an expensive JavaScript call that blocks the renderer for too long, remind you about that new photo on the front page of your web site that you might have forgotten to resize or optimize, or recommend changing the way you load third-party content so it no longer blocks the page load.

PageSpeed Insights for Chrome is a Chrome Developer Tools extension that analyzes all aspects of the page load, including resources, network, DOM, and the timeline. If you're already familiar with Chrome Developer Tools, you'll find that PageSpeed Insights integrates with a toolset you're already using.



Using technologies like Native Client, PageSpeed Insights is able to run the open-source PageSpeed Insights SDK securely and with the performance of native code. Leveraging the Insights SDK enables the Chrome extension to automatically optimize the images, CSS, JavaScript and HTML resources on your web page and provide versions of those resources that you can easily deploy on your website.

We hope you’ll give PageSpeed Insights for Chrome a try and start optimizing your web pages today. We’d love to hear from you, as always. Please try PageSpeed Insights for Chrome, and give us feedback on our mailing list with questions, comments, and new features you’d like to see.


Posted by Libo Song and Bryan McQuade, Software Engineers

During these last few weeks, the Chrome Web Store team has been focused on launching the store in more countries and building some new features for developers that can help them reach and engage with more users.

New Countries 

We recently launched the Chrome Web Store in six additional countries: Turkey, Ukraine, Egypt, Saudi Arabia, Morocco and the United Arab Emirates. This means that developers can now distribute and sell their apps to millions of additional potential users.

To be successful in these new markets, we highly recommend localizing your apps in as many languages as possible. This will make them more accessible to users around the world, and more likely to be promoted in the 42 countries the store is available in.

New Offline Apps Collection

To recognize developers who have made their apps work offline - and help users find them - we created a special collection just to highlight them in the store.



If you are a developer, getting your app listed in this collection is as simple as adding the offline_enabled flag to your app’s manifest file (note: to avoid negative user feedback, please ensure that your app does indeed work well offline before you do this).

Better Information in the Developer Dashboard 

One of the common requests we’ve received from developers, is that they’d like better insight into how well their apps are doing in the store. Many of you would especially like to know how many times your apps and extensions are being viewed vs. how many installations are occurring.

To help you with your data needs, we’ve created a new graph view to help you understand the performance of your apps. To make this data more accessible, you can easily download it as a CSV file. Currently, we provide 90 days of history information.



In the near future, we plan to further refine this feature - for example, we may increase the historical period for which data is available and add other features to help you understand how your apps are being adopted.

If you have any questions about these new features, you can reach us on our developer forum.

Posted by Joe Marini, Developer Advocate

When we wrapped up our recent Pwnium event, we praised the creativity of the submissions and resolved to provide write-ups on how the two exploits worked. We already covered Pinkie Pie’s submission in a recent post, and this post will summarize the other winning Pwnium submission: an amazing multi-step exploit from frequent Chromium Security Reward winner Sergey Glazunov.

From the start, one thing that impressed us about this exploit was that it involved no memory corruption at all. It was based on a so-called “Universal Cross-Site Scripting” (or UXSS) bug. The UXSS bug in question (117226) was complicated and actually involved two distinct bugs: a state corruption and an inappropriate firing of events. Individually there was a possible use-after-free condition, but the exploit -- perhaps because of various memory corruption mitigations present in Chromium -- took the route of combining the two bugs to form a “High” severity UXSS bug. However, a Pwnium prize requires demonstrating something “Critical”: a persistent attack against the local user’s account. A UXSS bug alone cannot achieve that.

So how was this UXSS bug abused more creatively? To understand Sergey’s exploit, it’s important to know that Chromium implements some of its built-in functions using special HTML pages (called WebUI), hosted at origins such as chrome://about. These pages have access to privileged JavaScript APIs. Of course, a normal web page or web renderer process cannot just iframe or open a chrome:// URL due to strict separation between http[s]:// and chrome:// URLs. However, Sergey discovered that iframing an invalid chrome-extension:// resource would internally host an error page in the chrome://chromewebdata origin (117230). Furthermore, this error page was one of the few internal pages that did not have a Content Security Policy (CSP) applied. A CSP would have blocked the UXSS bug in this context.

At this point, multiple distinct issues had been abused, to gain JavaScript execution in the chrome://chromewebdata origin.

The exploit still had a long way to go, though, as there are plenty of additional barriers:

• chrome://chromewebdata does not have any sensitive APIs associated with it. 
• chrome://a is not same-origin with chrome://b. 
• chrome://* origins only have privileges when the backing process is tagged as privileged by the browser process, and this tagging only happens as a result of a top-level navigation to a chrome:// URL. 
• The sensitive chrome://* pages generally have CSPs applied that prevent the UXSS bug in question. 

The exploit became extremely creative at this point. To get around the defenses, the compromised chrome://chromewebdata origin opened a window to chrome://net-internals, which had an iframe in its structure. Another WebKit bug -- the ability to replace a cross-origin iframe (117583) -- was used to run script that navigated the popped-up window, simply “back” to chrome://net-internals (117417). This caused the browser to reassess the chrome://net-internals URL as a top-level navigation -- granting limited WebUI permissions to the backing process as a side-effect (117418).

The exploit was still far from done. It was now running JavaScript inside an iframe inside a process with limited WebUI permissions. It then popped up an about:blank window and abused another bug (118467) -- this time in the JavaScript bindings -- to confuse the top-level chrome://net-internals page into believing that the new blank window was a direct child. The blank window could then navigate its new “parent” without losing privileges (113496). The first navigation was to chrome://downloads, which gained access to additional privileged APIs. You probably get a sense of where the exploit was headed now. It finished off by abusing privileged JavaScript APIs to download an attack DLL. The same APIs were used to cleverly “download” and run wordpad.exe from the local disk (thus avoiding the system-level prompt for executing downloads from the internet zone). A design quirk of the Windows operating system caused the attack DLL to be loaded into the trusted executable.

As you can imagine, it took us some time to dissect all of this. Distilling the details into a blog post was a further challenge; we’ve glossed over the use of the UXSS bug to bypass pop-up window restrictions. The UXSS bug was actually used three separate times in the exploit. We also omitted details of various other lockdowns we applied in response to the exploit chain.

What’s clear is that Sergey certainly earned his $60k Pwnium reward. He chained together a whopping 14[*] bugs, quirks and missed hardening opportunities. Looking beyond the monetary prize, Sergey has helped make Chromium significantly safer. Besides fixing the array of bugs, we’ve landed hardening measures that will make it much tougher to abuse chrome:// WebUI pages in the future.

Posted by Ken Buchanan, Chris Evans, Charlie Reis and Tom Sepez, Software Engineers 


[*]14, or thereabouts. It’s easy to lose count.

Back in March, we began work on a Metro-style enabled desktop browser, a version of Chrome that will run in both the Metro and desktop environments of Windows 8 on x86. (Chrome won’t run in WinRT, i.e. Windows 8 on ARM processors, as Microsoft is not allowing browsers other than Internet Explorer on the platform.) If you’re running the Release Preview of Windows 8, you’ll be able to try Chrome in Metro mode in the next Chrome Dev channel release by setting it as your default browser.



The initial releases of Chrome in Metro mode will include integration with the basic Windows 8 system functionality, such as charms and snap view. Over the next few months, we’ll be smoothing out the UI on Metro and improving touch support, so please feel free to file bugs. We’re committed to bringing the speed, simplicity, and security of Chrome into Windows 8, and we look forward to working with you on it.

Carlos Pizano, Software Engineer and Metro Gnome

CSS filters are a powerful, easy-to-use visual effects tool for web developers. Filters can manipulate the appearance of any HTML element and can be stacked together to create unique effects -- all with a single line of CSS. Chromium GPU accelerates these filters to make them super fast. CSS filters are new in Chromium 19.

The current set of supported filters in Chromium include many that are familiar to web developers with image processing experience, such as sepia, saturation, opacity, and blurs. If you’re a web designer looking to add dynamic visuals to your next page layout, a developer building a photo editing app, or a game developer looking for an easy way to add effects to your next title, CSS filters can help you get there easily.


GPU acceleration of these filters brings their performance to the point where they can be used for animating elements in conjunction with CSS animations powered by -webkit-transition or even HTML5 video tags.

To get a sense of how much you can do with CSS filters, check out this interactive abstract painting app.


For more info on CSS filters, including a full list of those available in Chromium and how to use them, check out the new CSS Filter tutorial on HTML5Rocks.

Posted by Stephen “Rose-Colored Glasses” White, Software Engineer