Chromium Blog: February 2011

Chrome Developer Tools: Back to Basics

Thursday, February 24, 2011

Google Chrome Developer Tools

Network aspects of your web page are now inspected in the Network panel. This gives you access to even more information at a single glance. You can sort and clear data, preserve log information upon navigation and even export network data into HAR format.

All the timing information about your resource loads now comes from the network stack, not WebKit, so timing information now adequately represents raw network timing. You can see detailed timing for different phases of the loading by hovering over the log entry.

We now push raw HTTP headers and status messages into Chrome Developer Tools. As a result, you now see precisely what the browser received from the server and not just how the rendering engine interpreted that information.

Similarly to the old Resources panel, you can see syntax-highlighted resource contents.

CSS sidebar

home pageWebKit blog postPosted by Pavel Feldman and Alexander Pavlov, Software Engineers

Amping Up Chrome’s Background Feature

Wednesday, February 23, 2011

background pagesChrome Web Store

developer’s guidePosted by Andrew Wilson, Software Engineer and Michael Mahemoff, Developer Relations

Extending the Omnibox

Tuesday, February 22, 2011

omnibox APIthis extension

Posted by Matt Perry, Software Engineer

Native Client: Getting Ready for Takeoff

Friday, February 18, 2011

Over the last few months we have been hard at work getting Native Client ready to support the new Pepper plug-in interface. Native Client is an open source technology that allows you to build web applications that seamlessly and safely execute native compiled code inside the browser. Today, we’ve reached an important milestone in our efforts to make Native Client modules as portable and secure as JavaScript, by making available a first release of the revamped Native Client SDK.
The SDK now includes support for a comprehensive set of Pepper interfaces for compute, audio, and 2D Native Client modules. These interfaces are close to being stable, with some important exceptions that are listed in the release notes.
In addition, we’ve focused on improving security. We have enabled auto-update and an outer sandbox. This allowed us to remove the expiration date and localhost security restrictions we had adopted in previous research-focused releases. Beyond security, we’ve also improved the mechanism for fetching Native Client modules based on the instruction set architecture of the target machine, so developers don’t need to worry about this any more.
We are excited to see Native Client progressively evolve into a developer-ready technology. In the coming months we will be adding APIs for 3D graphics, local file storage, WebSockets, peer-to-peer networking, and more. We’ll also be working on Dynamic Shared Objects (DSOs), a feature that will eventually allow us to provide Application Binary Interface (ABI) stability.
Until the ABI becomes stable, Native Client will remain off by default. However, given the progress we’ve made, you can now sticky-enable Native Client in Chrome 10+ through the about:flags dialog. Otherwise, you can continue using a command line flag to enable Native Client when you want to.
A big goal of this release is to enable developers to start building Native Client modules for Chrome applications. Please watch this blog for updates and use our discussion group for questions, feedback, and to engage with the Native Client community.
Posted by Christian Stefansen, Product Manager

Chrome Web Store International Support: Developer Preview

Thursday, February 17, 2011

When we recently announced the availability of the Chrome Web Store to Chrome users in the US, we mentioned that we were hard at work making the store available globally. Today we’re excited to announce a preview release of the upload flow for several international markets as a step towards that goal.
Starting today, when you upload an app via the developer dashboard, you’ll have the option of selecting from the following sixteen countries to list your app: Argentina, Australia, Brazil, Canada, France, Germany, India, Italy, Japan, Mexico, Netherlands, Poland, Portugal, Spain, United Kingdom and the United States. If you are using Chrome Web Store Payments to charge for your app, you will also be able to set the app price for each country although if you’re not based in the United States you will not be able to complete your merchant account sign up just yet (this will be enabled soon).

Note that these apps will not yet be published to countries outside the United States. This will happen when the Chrome Web Store opens to consumers in these countries later this year. We are releasing this developer preview ahead of the consumer release so you have enough time to prepare your apps for international users.
We hope you can use this release to get familiar with the app upload process and take time to localize your app listing to make it accessible to more people. If you have additional questions, please take a look at our FAQ or join our developer discussion group.
Posted by Qian Huang, Software Engineer

Chrome@GDC2011

Wednesday, February 9, 2011

Games are some of the most popular apps on the web platform. Representatives from the Chrome team will be at the Game Developers Conference, to connect with game developers and deliver tech talks on some of the latest web technologies.
On February 28th, as part of Google Developer Day at GDC, Vincent Scheib will present an overview of how the latest HTML5 technologies can be used to create games. On the same day, Gregg Tavares will explain how to get GPU-accelerated graphics with WebGL, and Bill Budge will show how you can program Web games in C++ using Native Client. For a full list of other Google talks check out google.com/gdc2011.
We will also be present at Google’s booth on the GDC expo floor. Representatives from our 3D Graphics, Native Client, HTML5 and Chrome Web Store teams will be there to answer your questions on how you can use web technologies to create compelling games for Chrome’s 120+ million active users.
We can’t wait to see you there!Posted by Ian Lewis, Developer Advocate

Chromium to Feature in Pwn2Own Contest!

Monday, February 7, 2011

We’re excited that the Google Chrome browser will feature in this year’s Pwn2Own contest. Chrome wasn’t originally going to be included as a target browser in the competition, but Google volunteered to sponsor Chrome’s participation by contributing monetary rewards for Chrome exploits. For the past year we’ve enjoyed working with the security community and rewarding researchers for high quality work through our Chromium Security Reward program. Sponsoring this contest to discover more bugs was a logical step. We thought we’d answer some frequently asked questions in the form of a Q&A session:
Q) Is Chrome OS a target?A) No, not this year, as Chrome OS is still in beta. Per HP TippingPoint / ZDI guidelines, the actual target will be the latest stable version of the Chrome browser at the time, running on an up-to-date Windows 7 system. A Chrome OS device will, however, be awarded in addition to the prize money.
Q) Are you betting that Chrome can’t be hacked?A) No. We think the Chrome browser has a strong security architecture, and Chrome has fared well in past years at Pwn2Own. But we know that web browsers from all vendors are very large pieces of software that invariably do have some bugs and complex external dependencies. That’s why the Chromium Security Reward program exists, along with our newer web application reward program. As a team comprised largely of security researchers, we think it’s important to reward the security community for their work which helps us learn. Naturally, we’ll learn the most from real examples of Chrome exploits.
Q) How do the rules work?A) We worked with ZDI to come up with a rules structure that would reward exploits in code specific to Chromium and in third-party components such as the kernel or device drivers.
Of course, we prefer to pay rewards for bugs in our own code because we learn more and can make fixes directly. On day 1 of the competition, Google will sponsor $20,000 for a working exploit in Chrome, if it uses only Chrome bugs to compromise the browser and escape the sandbox. Days 2 and 3 will also allow for bugs in the kernel, device drivers, system libraries, etc., and the $20,000 prize will be sponsored at $10,000 by Google and $10,000 by ZDI to reflect the occurrence of the exploit partially outside of the Chrome code itself.
Note that ZDI is responsible for the rules and may change them at their own discretion.
Q) Does this competition impact the Chromium Security Reward program?A) The program still pays up to $3,133.7 per bug. As always, submissions to the program don’t require exploits in order to be rewarded. In addition, we continue to reward classes of bugs (such as cross-origin leaks) that would otherwise not be eligible for prizes at Pwn2Own. We encourage researchers to continue submitting their bugs through the Chromium Security Reward program.
Posted by Chris Evans, Google Chrome Security Team

Chromium Blog