The Dev channel has been updated to 23.0.1271.16 (Platform version: 2913.41.0) for Chromebooks (Acer AC700, Samsung Series 5 550, Samsung Chromebook Series 3, and Cr-48) and Samsung Chromebox Series 3. This build contains UI, stability and performance improvements.

Highlights of these changes are: 

• Pepper Flash updated to version 11.4.31.108

Known issues: 

In recent years, video has taken a central role on the web. Developers are using the latest web technologies to make it easier for users to access, watch, and create video content. Today’s Chrome Beta update includes more tools for developers to take video engagement to the next level.

Chrome now includes the PeerConnection API, which allows developers to create web apps with real-time audio and video calling without the need for a plug-in. Together, PeerConnection and the getUserMedia API represent the next steps in WebRTC, a new standard which aims to allow high quality video, audio, and data communications on the web. Check out this funky video chat demo to see how the PeerConnection API can be combined with other web technologies to create fun new video chat experiences. To start the video chat demo, send the url to a friend.

Today’s Chrome Beta update also includes track support for HTML5 video. Track support provides an easy, standard way to add subtitles, captions, descriptions, chapters, and metadata to videos. It can be used to make videos accessible, split videos into sections, and create new unique video experiences. Track provides developers with a unified, programmatic mechanism for doing all these things in the HTML DOM and Javascript. In the following demo, track is used to enhance a video of a bike ride with metadata including a Google Map showing the biker’s route and Google Street View from the biker’s location.

Last but not least, we’ve added the MediaSource API. It provides a video playback solution that adapts video quality based on changing computer and network conditions to prevent excessive buffering and startup delays for videos -- in other words, your video will play silky smooth for users with no annoying stutters. Watch how smooth this demo video plays despite fluctuations in your network speed.

To get your hands on all this tasty video goodness, download Chrome Beta.

Moving the web forward includes enabling new classes of applications. Today’s Chrome Stable release advances this effort with the inclusion of the Pointer Lock JavaScript API (often called Mouse Lock). Now, 3D applications such as first-person games can allow users to control their perspective naturally with the mouse, without moving outside the window or bumping into the edge of their screen. Try it out for yourself in this 3D, first-person shooter demo created by our friends at Mozilla.

• Fixed Crash when closing maximized window via Ctrl+W (147635)

• Fixed Instant search (148578)

• UI improvements

Known Issues:

• 34334 - External display gets cropped after resume from sleep

• 147666 - File Manager downloads "open" button missing. Workaround: Right click to open

Earlier this year at Google I/O, we gave developers a sneak peek at Movi.Kanti.Revo, a new sensory Chrome experiment crafted by Cirque du Soleil and developed by Subatomic Systems that brings the magic of Cirque du Soleil to the web through modern web technologies. The full experiment, which allows users to follow a mysterious character through a beautiful world of Cirque du Soleil performances, was launched today at the Big Tent event in New York City.

The experiment was created using just HTML5, and the environment is built entirely with markup and CSS. Like set pieces on stage, divs, images and other elements are positioned in a 3D space using CSS. To create movement, CSS animations and 3D transforms were applied making the elements appear closer and further away. Everything is positioned and scaled individually to create a highly realistic interactive environment. In addition, the experiment uses HTML5

An option to enable Do Not Track headers landed in today’s Chromium release which web users can make use of to notify servers, websites and scripts that they do not want to be tracked on the Internet. The main aim of Do Not Track is to provide Internet users with an option to opt-out of targeted advertising on the Internet.

The idea here is to provide users with an option in the browser to enable the Do Not Track header there. This has caused some controversy recently when Microsoft announced that it would enable DNT by default for all users of the Internet Explorer 10 browser as it goes against the idea of making DNT a user’s choice (in contrast to a browser developer’s choice for the user).

The browser will send the Do Not Track header with connection requests when the feature is enabled by the user. From there, it depends largely on the advertising companies as there is no legal requirement to accept the request. If it is honored by the advertiser, user tracking is disabled. This does not mean that ads won’t be displayed to the user. The advertisement displayed may however not be as personal as it would have been if the Do Not Track header would not have been included in the header.

Google Chrome is the only major browser that did not support Do Not Track until now. Firefox, Opera and Internet Explorer 10 all support the feature. The feature is available under Privacy in the Chrome settings. The easiest way to get there is to enter chrome://chrome/settings/ in the address bar, scroll down, click on show advanced settings to reveal additional browser preferences including the Privacy section here.

To activate simply check the “Send a ‘Do Not Track’ request with your browsing traffic box. Chrome from that moment on will include the DNT header with all requests that it makes. Expect the setting to go through all versions of Chrome in the coming weeks and months.

Cross-posted on the Google Developers Blog

At Google, we are constantly looking at ways to make web pages load faster. One way to do this is by making web images smaller. This is especially important for mobile devices where smaller images save both bandwidth and battery life. Earlier this month, we released version 0.2 of the WebP library that adds support for lossless and transparency modes to compress images. This version provides CPU and memory performance comparable to or better than PNG, yet results in 26% smaller files.

WebP’s improved compression comes from advanced techniques such as dedicated entropy codes for different color channels, exploiting 2D locality of backward reference distances and a color cache of recently used colors. This complements basic techniques such as dictionary coding, Huffman coding and color indexing transform. We think that we've only scratched the surface in improving compression. Our newly added support for alpha transparency with lossy images promises additional gains in this space, helping make WebP an efficient replacement for PNG.

The new WebP modes are supported natively in the latest Beta version of Chrome. The bit stream specification for these new WebP modes has been finalized and the container specification has been updated. We thank the community for their valuable feedback and for helping us evolve WebP as a new image compression format for the web. We encourage you to try these new compression methods on your favorite set of images, check out the code, and continue to provide feedback.

If you find new issues, please let us know by visiting our help site or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue’ under the wrench menu.

The Google Chrome team is happy to announce the arrival of Chrome 21 to the Stable Channel for Chrome OS.  More detailed updates are available on the Google Chrome Blog.  

The Stable channel has been updated to 21.0.1183.0 (Platform version: 2465.127.0) for Chromebooks (Acer AC700, Samsung Series 5 550, Samsung Series 5, and Cr-48) and Samsung Chromebox Series 3. Machines will be receiving updates to this version over the next several days.

The web is evolving and so should the JavaScript benchmarks that measure its performance. Today, we are releasing Octane, a JavaScript benchmark suite that aims to measure a browser’s performance when running the complex and demanding web applications that users interact with daily.

Most of the existing JavaScript benchmarks run artificial tests that were created on an ad-hoc basis to stress a specific JavaScript feature. Octane breaks with this tradition and extends the former V8 Benchmark Suite with 5 new benchmarks created from full, unaltered [1], well-known web applications and libraries. A high score in the new benchmarks directly translates to better and smoother performance in similar web applications.

Here is an overview of the new tests:

• Box2DWeb runs a JavaScript port of a popular 2D physics engine that is behind many well-known simulations and web games. 
• Mandreel puts a JavaScript port of the 3D Bullet Engine to the test with a twist: The original C++ source code for the engine is translated to JavaScript by Onan Games’ Mandreel compiler, which is also used in countless web-based games. 
• Pdf.js is based on Mozilla’s PDF reader and shows how Javascript applications can replace complex native browser plug-ins. It measures how fast the browser decodes a sample PDF document. 
• GB Emulator is derived from an open source emulator of a famous game console running a 3D demo. 
• CodeLoad measures how quickly a JavaScript engine can bootstrap commonly used JavaScript libraries and start executing code in them. The source for this test is derived from open source libraries (Closure, jQuery). 

Besides an expanded set of benchmarks, Octane also has an interface that makes it easier to read and that adapts automatically to tablet and mobile screens.

You can try out Octane yourself, browse the source code, or read more about each benchmark at the Octane site. Still have some questions? Have a look at the FAQ page.

The first Pwnium competition held earlier this year exceeded our expectations. We received two submissions of such complexity and quality that both of them won Pwnie Awards at this year’s Black Hat industry event. Most importantly, we were able to make Chromium significantly stronger based on what we learned.

We’re therefore going to host another Pwnium competition, called... Pwnium 2. It will be held on Oct 10th, 2012 at the Hack In The Box 10 year anniversary conference in Kuala Lumpur, Malaysia.

This time, we’ll be sponsoring up to $2 million worth of rewards at the following reward levels:

• $60,000: “Full Chrome exploit”: Chrome / Win7 local OS user account persistence using only bugs in Chrome itself. 
• $50,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 kernel bug. 
• $40,000: “Non-Chrome exploit”: 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. 
• $Panel decision: “Incomplete exploit”: An exploit that is not reliable, or an incomplete exploit chain. For example, code execution inside the sandbox but no sandbox escape; or a working sandbox escape in isolation. For Pwnium 2, we want to reward people who get “part way” as we could definitely learn from this work. Our rewards panel will judge any such works as generously as we can. 

Exploits should be demonstrated against the latest stable version of Chrome. Chrome and the underlying operating system and drivers will be fully patched and running on an Acer Aspire V5-571-6869 laptop (which we’ll be giving away to the best entry.) Exploits should be served from a password-authenticated and HTTPS Google property, such as App Engine. The bugs used must be novel i.e. not known to us or fixed on trunk. Please document the exploit.

You may have noticed that we’ve compressed the reward levels closer together for Pwnium 2. This is in response to feedback, and reflects that any local account compromise is very serious. We’re happy to make the web safer by any means -- even rewarding vulnerabilities outside of our immediate control.

Another well-received piece of feedback from the first Pwnium was that more notice would have been nice. Accordingly, we’re giving about two months notice. We hope this gives enough time for the security community to craft more beautiful works, which we’d be more than happy to reward and celebrate.

The Chromium Vulnerability Rewards Program was created to help reward the contributions of security researchers who invest their time and effort in helping us make Chromium more secure. We’ve been very pleased with the response: Google’s various vulnerability reward programs have kept our users protected and netted more than $1 million dollars of total rewards for security researchers. Recently, we’ve seen a significant drop-off in externally reported Chromium security issues. This signals to us that bugs are becoming harder to find, as the efforts of the wider community have made Chromium significantly stronger.

Therefore, we’re making the following changes to the reward structure:

• Adding a bonus of $1,000 or more on top of the base reward for “particularly exploitable” issues. The onus is on the reporter to provide a quick demonstration as part of the repro. For example, for a DOM-based use-after-free, one might use JavaScript to allocate a specific object type in the “freed” slot, resulting in a vtable dereference of 0x41414141. 
• Adding a bonus of $1,000 or more on top of the base reward for bugs in stable areas of the code base—see below for an example. By “stable”, we mean that the defect rate appears to be low and we think it’s harder to find a security bug in the area. 
• Adding a bonus of $1,000 or more on top of the base reward for serious bugs which impact a significantly wider range of products than just Chromium. For example, certain open source parsing libraries—see below for an example. 

The rewards panel has always reserved the right to reward at our discretion. At times, rewards have reached the $10,000 level for particularly significant contributions. An extraordinary contribution could be a sustained level of bug finding, or even one individual impressive report. Examples of individual items that might impress the panel include:

• Nvidia / ATI / Intel GPU driver vulnerabilities. High or critical severity vulnerabilities in the respective Windows drivers, demonstrated and triggered from a web page. Submissions on Chrome OS would also be interesting. Chrome OS typically runs on a device with an Intel GPU. 
• Local privilege escalation exploits in Chrome OS via the Linux kernel. Chrome OS has a stripped-down kernel, so a working exploit against it would certainly be worth examining. We reserve the right to reward more generously if the exploit works inside our “setuid sandbox” and / or our fast-evolving “seccomp BPF sandbox”. 
• Serious vulnerabilities in IJG libjpeg. For well over a decade, there hasn’t been a serious vulnerability against IJG libjpeg. Can one be found? 
• 64-bit exploits. Any working code execution exploit on a 64-bit Chrome release. Sandbox escape not required. 
• Renderer to browser exploit. Any working browser code execution exploit, starting from the assumed precondition of full code execution inside a normal web renderer or PPAPI process. 

Aside from the new bonuses, it’s worth recapping some details of the existing reward structure that aren’t as widely known:

• Our reward program covers vulnerabilities in Adobe Flash as well as other well-known software such as the Linux kernel, various open-source libraries and daemons, X windows, etc. 
• Our base reward is $2,000 for well-reported UXSS bugs, covering both the Chromium browser and also Adobe Flash. (With the new reward bonus for exploitability, UXSS rewards will likely become $4,000.) 
• Our reward program already includes a bonus of $500 to $1,000 when the reporter becomes a more involved Chromium community member and provides a peer-reviewed patch. 
• We have always considered rewards for regressions affecting our Beta or Dev channel releases. It’s a big success to fix security regressions before they ship to the Stable channel. 

To illustrate how the new reward bonuses will work, we’re retroactively applying the bonuses to some older, memorable bugs:

• $1,000 to Atte Kettunen of OUSPG for bug 104529 (new total: $2,000). We believe that our PDF component is one of the more secure (C++) implementations of PDF, hence the $1,000 top-up. 
• $3,000 to Jüri Aedla for bug 107128 (new total: $4,000). There is a $1,000 bonus because this bug affects many projects via core libxml parsing, and we added a $2,000 bonus for exploitability: this is a heap-based buffer overflow involving user-controlled data with a user-controlled length. 

We’re more excited than ever to work with the community and reward their efforts.

Just over a month ago, at Google I/O, we announced significant changes to Chrome’s packaged application platform. These changes are intended to allow apps to break out of the browser, work offline by default, and enable richer, more immersive experiences.

With the latest version of Chrome in the developer channel, you can build, load, debug and test your apps without command-line flags, although you may need to enable experimental APIs in some cases. Because we’re still in developer preview mode, the Chrome Web Store doesn’t yet accept uploads of these new packaged apps. We’ll enable web store support later this year, and when we flip that switch, users will be able to discover and download your apps directly from the store.

In order to get started building apps, visit our developer documentation at developer.chrome.com/apps and check out our growing list of sample applications on Github (thanks for the pull requests; keep them coming). If you’d like to reach us while you’re building apps, you can join us on the #chromium-apps Freenode IRC channel, join the chromium-apps group or report an issue.

We’re also starting a regular weekly hangout every Tuesday at 9:30am (Pacific Time). Our first one will take place on Tuesday, August 14th. You can add a reminder to your calendar and then tune in at Google Developers Live. And be sure to add +Google Chrome Developers to your circles to keep up on the latest from the Chrome team.

A little more than two years ago, engineers on the Chrome team began a very ambitious project. In coordination with Adobe, we started porting Flash from the aging NPAPI architecture to our sandboxed PPAPI platform. With last week’s Chrome Stable release, we were finally able to ship PPAPI Flash to all Windows Chrome users, so they can now experience dramatically improved security and stability as well as improved performance down the line.

To appreciate just what a big step forward this is, it helps to understand a bit more about the history and architecture of NPAPI plug-ins. At its core, NPAPI is a thin layer of glue between the web browser and a native application. In the early days of the Web this provided a tremendous advantage, because it allowed third-party plug-ins to evolve rapidly and implement new capabilities, moving the whole web forward.

Unfortunately, as the web evolved, the past benefits of NPAPI became liabilities. The thinness allowed legacy browser and OS behavior to bleed through and crystallize to the point that it hamstrung future improvements. As browsers add compelling features like sandboxing, GPU acceleration, and a multi-process architecture, the legacy of NPAPI severely impedes or outright prevents us from extending those improvements to any pages with plug-in content.

By porting Flash to PPAPI we’ve been able to achieve what was previously impossible with NPAPI for the 99.9% of Chrome users that rely on Flash. Windows Flash is now inside a sandbox that’s as strong as Chrome’s native sandbox, and dramatically more robust than anything else available. And for the first time ever, Windows XP users (specifically, over 100 million Chrome users) have a sandboxed Flash—which is critical given the absence of OS support for security features like ASLR and integrity levels.

Beyond the security benefits, PPAPI has allowed us to move plug-ins forward in numerous other ways. By eliminating the complexity and legacy code associated with NPAPI, we’ve reduced Flash crashes by about 20%. We can also composite Flash content on the GPU, allowing faster rendering and smooth scrolling (with more improvements to come). And because PPAPI doesn’t let the OS bleed through, it’s the only way to use all Flash features on any site in Windows 8 Metro mode.

Moving forward, we’re finishing off the PPAPI Flash port for Mac OS X and hope to ship it soon. And Linux users have already been benefiting from PPAPI Flash since Chrome 20, along with Chrome OS users who have been running it for almost a year. Soon all Chrome users will have access to the improved security, stability, and performance of PPAPI Flash.

Last year, we posted on the Google Online Security Blog about our desire to end mixed scripting vulnerabilities. A “mixed scripting” vulnerability affects HTTPS websites that are improperly implemented; these vulnerabilities are serious because they eliminate most of the security protections afforded by HTTPS. All web browsers have historically taken it upon themselves to try and work around these bugs by informing or protecting users in some way.

With the recent release of Chrome 21, we’ve taken several steps forward:

• We continue to protect end users by blocking mixed scripting conditions by default, but we now do it in a way that is less intrusive. This change minimizes “security dialog fatigue” and reduces the likelihood that users will expose themselves to risk by clicking through the warning. 
• We’ve improved resistance to so-called “clickjacking” attacks. Electing to run any mixed script is now a two-click process. 
• We now silently block mixed scripting conditions for websites that opt in to the HSTS security standard. This is the strongest default protection available. 

If you visit a non-HSTS web site with a mixed scripting condition, a new shield icon in the omnibox (to the right, next to the star) indicates that Chrome’s protection has kicked in:

You can click on the shield to see the option to run the mixed script, but we don’t recommend it. Instead, if you see the shield icon, we recommend contacting the website owners to make sure they know they may have a security vulnerability.

It has been an interesting journey to get to this point. For about a year, we blocked mixed scripting by default on Chrome’s Dev and Beta channel releases. Rolling out the block to Stable was more challenging because of widespread mixed scripting across the web. To move forward, we turned blocking on for certain web sites, starting with google.com. Later, we reached out to and then collaborated with twitter.com and facebook.com to opt them into blocking, too. All these websites hold themselves to a high standard of security, so this approach worked well. We later took the additional step of opting in sites to mixed script blocking for any site using the HSTS standard.

We bit the bullet and let full mixed script blocking for all sites hit Stable back in Chrome 19. Predictably, we uncovered a range of buggy web sites, and some users were confused about the “infobar” warning displayed by the older versions of Chrome:

Fortunately—and no doubt driven by the high visibility of this warning—some prominently affected websites were able to deploy quick fixes to resolve their mixed scripting vulnerabilities. This work aligns with one of our Core Security Principles: Make the web safer for everyone. Unfortunately, the warning confused some users, which conflicts with another principle: Don’t get in the way. (We’re sorry for any temporary disruption.)

With Chrome 21, we believe we’ve achieved a good balance between top-flight protection for end users, a pleasant UI experience, and notifications that help buggy websites improve their security.

We recently announced initial support for Chrome in Windows 8 Metro mode. One thing that early testers may have noticed is that some existing plug-ins don't work. These plug-ins are built using a technology called NPAPI, which, like ActiveX, is not compatible with Windows 8 Metro mode.

Note that because Adobe Flash Player and Chrome’s PDF viewer have both been bundled as Pepper plug-ins running in a sandboxed environment in Chrome, these two widely-used plug-ins will continue to work in Windows 8 Metro mode on all websites.

We’ve noticed that other than Flash and PDF, usage of plug-ins has been steadily decreasing over the past few years, to the point where a relatively small percentage of our users load any of these plug-ins at all. The following table shows some well-known plug-ins along with the percentage of active Chrome users who instantiated that plug-in during a 28-day window:

This data came from more than 20 million Chrome users who have opted in to share non-identifying usage statistics with Google, which are aggregated to understand how Chrome features are used.

We expect NPAPI plug-in usage to continue declining over time, especially since plug-ins can’t run on most phones and tablets. If the trends continue, we look forward to the day when NPAPI can retire peacefully to the countryside.

Today’s Chrome Beta release includes two new APIs: the getUserMedia API and the Gamepad Javascript API.

The getUserMedia API lets users grant web apps access to their camera and microphone without a plug-in. This is the first step in enabling high quality video and audio communication as part of WebRTC, a powerful new real-time communications standard for the open web platform.

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!