Today, we are launching Discover DevTools, an interactive Code School training course that will teach you how to take advantage of Chrome DevTool's powerful suite of resources and speed up the development and debugging of your web apps.
In each of the seven chapters of this interactive course, you can watch an overview video teaching you the latest techniques, and follow a series of challenges where your knowledge will be put to the test. We've integrated the Chrome DevTools themselves into the course, so as you explore the functionality within them, you'll get immediate feedback and earn points and badges.

Even regular users of the Chrome DevTools may be surprised to find some lesser-known features from this course that can really boost productivity. You'll learn a debugging workflow to go from an uncaught exception to a live fix without ever refreshing your app. In addition, the course will share time-saving tricks to improve your efficiency while debugging CSS, improving reflow issues, and interpreting your network and JavaScript bottlenecks. You'll also uncover the DOM bottlenecks that are blocking you from delivering a slick 60 FPS experience.

We hope you’ll try out the Discover DevTools course and see how Chrome DevTools can make you a more productive developer.

Posted by Paul Irish, Senior Developer Advocate (completed the course in 14:52) and Peter Lubbers, Program Manager (best time: 15:05)

Earlier this month at the CanSecWest security conference, the Chrome team took part in another Pwn2Own and hosted our third-edition Pwnium competition. This year’s participants once again impressed us with their talent and security prowess. We’re excited about what lessons we can learn from their work to make Chrome and Chrome OS even more secure.

At Pwnium, we didn’t receive any winning entries, but did reserve the right to issue “partial” rewards. We’re pleased to reward $40,000 to Pinkie Pie, who submitted a plausible bug chain involving video parsing, a Linux kernel bug and a config file error. The submission included an unreliable exploit demonstrating one of the bugs. We’ve fixed most of these bugs already.

In particular, we’d like to thank Pinkie Pie for honoring the spirit of the competition by disclosing a partial exploit at the deadline, rather than holding on to bugs in lieu of an end-to-end exploit. This means that we can find fixes sooner, target new hardening measures and keep users safe.

In the parallel Pwn2Own contest, participants attacked many different browsers and plug-ins. There was a top prize on the line for Chrome, which was claimed by Nils and Jon of MWR Labs. Of the two bugs used, one bug was in Chrome code, which we fixed in 24 hours. Thankfully, recently deployed hardening measures protected Chrome OS users. The second bug was in the Windows kernel. The new Pwn2Own rules required the researcher to hand the bug and exploit over to Microsoft, so we’re delighted that the Chrome entry will make other products safer, beyond just Chrome.

While these security gatherings and live competitions are fun, we also want to highlight the ongoing Chromium Vulnerability Reward Program, which covers not only the Chrome desktop browser, but also all Chrome OS components and Chrome on mobile devices. We’ve given away more than $900,000 in rewards over the years and we’re itching to give more, as engaging the security community is one of the best ways to keep all Internet users safe.

Posted by Chris Evans, Chief Reward Officer

The latest Dart SDK now provides a cohesive API for asynchronous programming. Some of the new or improved classes in this release include Stream, a sequence of asynchronous events, and Future, a single asynchronous result.

The Stream class is new and delivers on a common developer request for a more unified approach to events. An event can be any Dart object, which makes Streams very flexible. Consumers of a Stream can listen for events, and streams can be piped, transformed, filtered, and more. We are working to apply them across HTML, I/O, isolates, and more. Here is an example of using streams with the HTML library, treating clicks as a stream of events:

query('#button').onClick.listen((e) => submitForm());

Here is an example of streaming the contents of a file. Notice how streams can be transformed.

Stream<int> stream = ...
stream
  .transform(new StringDecoder())
  .transform(new LineTransformer())
  .listen((String line) { /* Do something with line. */ },
          onDone: () { /* No more lines */ },
          onError: (e) { /* Error on input. */ });

The Future class, which represents a single value available in the future, was cleaned up and is much easier to use. In many cases this allows you to write asynchronous code very similar to its synchronous counterpart:

// Synchronous code, does not use Future
bool writeFile(String data, File file) {
 try {
  var io = file.openSync(FileMode.WRITE);
  io.writeStringSync(data);
  io.closeSync();
  return true;
 } catch (error) {
  return false;
 }
}

// Asynchronous code, does use Future
Future<bool> writeFile(String data,
                       File file) {
 return file.open(FileMode.WRITE)
   .then((io) => io.writeString(data))
   .then((io) => io.close())
   .then((io) => true)
   .catchError((error) => false);
}

Some of these changes are not backwards compatible. Luckily, you can use Dart Editor's Clean Up feature to help automatically port your code from the old API to the new API. Here is an example of Clean Up at work:

Over the following months we will continue to work on the libraries, applying the new asynchronous models. We always appreciate the feedback, please let us know what you think at dartbug.com and misc@dartlang.org.

To get started, you can download the Dart SDK, learn about the language and libraries, and follow our tutorials. If you already have Dart Editor, it can auto-update to the latest release for you.

Posted by Florian Loitsch, Software Engineer and Corelib Hacker

Today’s Chrome Beta for Android update brings your saved passwords and autofill entries from your desktop to your phone and tablet. This release also introduces an experimental data compression feature that will yield substantial bandwidth savings. This feature is powered by a connection to a SPDY proxy running on Google’s servers, paired with content optimization performed by our open-source PageSpeed libraries, specifically tuned for Chrome Beta on Android.

By using SPDY, the proxy is able to multiplex multiple request and response streams in parallel over a single TCP connection to your phone or tablet. When this new feature is enabled (enable the “Experimental Data Compression Proxy” under chrome://flags) the browser-to-proxy connection is over SSL, for a more secure browsing experience. In addition, only HTTP traffic is routed through and optimized by the proxy, so secure (HTTPS) requests will bypass the proxy and continue to connect directly to the destination. Furthermore, DNS lookups are performed by the proxy, instead of on the mobile device. Turning on this experimental feature also enables Safe Browsing.

For an average web page, over 60% of the transferred bytes are images. The proxy optimizes and transcodes all images to the WebP format, which requires fewer bytes than other popular formats, such as JPEG and PNG. The proxy also performs intelligent compression and minification of HTML, JavaScript and CSS resources, which removes unnecessary whitespace, comments, and other metadata which are not essential to render the page. These optimizations, combined with mandatory gzip compression for all resources, can result in substantial bandwidth savings.

For a deeper dive into the technical details, check out our whitepaper in Chrome for Android’s developer documentation. The latest version of Chrome Beta for Android is available on Google Play (use the link, you won't find it in search)! We look forward to your early feedback.

Posted by Matt Welsh, Software Engineer & Mobile Web Performance Gearhead

Update April 10, 2013: To enable this experimental data compression feature, go to “Bandwidth Management” in Settings and enable “Reduce Data Usage.” From the most recent Chrome Beta for Android release onwards, no need to look under chrome://flags.