Security is one of the core tenets of Chrome, but no software is perfect, and security bugs slip through even the best development and review processes. That’s why we’ve continued to engage with the security research community to help us find and fix vulnerabilities. Recently, HP’s Zero Day Initiative (ZDI) announced details for the annual Pwn2Own competition, to be held at the CanSecWest security conference taking place March 6-8 in Vancouver, BC. This year we’ve teamed up with ZDI by working together on the Pwn2Own rules and by underwriting a portion of the winnings for all targets. The new rules are designed to enable a contest that significantly improves Internet security for everyone. At the same time, the best researchers in the industry get to showcase their skills and take home some generous rewards.

Today we’re announcing our third Pwnium competition—Pwnium 3. Google Chrome is already featured in the Pwn2Own competition this year, so Pwnium 3 will have a new focus: Chrome OS.

We’ll issue Pwnium 3 rewards for Chrome OS at the following levels, up to a total of $3.14159 million USD:

$110,000: browser or system level compromise in guest mode or as a logged-in user, delivered via a web page.

We believe these larger rewards reflect the additional challenge involved with tackling the security defenses of Chrome OS, compared to traditional operating systems.

The attack must be demonstrated against a base (WiFi) model of the Samsung Series 5 550 Chromebook, running the latest stable version of Chrome OS. Any installed software (including the kernel and drivers, etc.) may be used to attempt the attack. For those without access to a physical device, note that the Chromium OS developer’s guide offers assistance on getting up and running inside a virtual machine.

Standard Pwnium rules apply: the deliverable is the full exploit plus accompanying explanation and breakdown of individual bugs used. Exploits should be served from a password-authenticated and HTTPS-supported Google property, such as Google App Engine. The bugs used must not be known to us or fixed on trunk. We reserve the right to issue partial rewards for partial, incomplete or unreliable exploits.

Pwnium 3 will take place on-site at the CanSecWest conference on March 7.

Native Client (NaCl) enables Chrome to run high-performance apps compiled from your C and C++ code. One of the main goals of Native Client is to be architecture-independent, so that all machines can run NaCl content. Today we’re taking another step toward that goal: our Native Client SDK now supports ARM devices, from version 25 and onwards.

If your app uses Native Client and newlib, you’ll now be able to reach users on ARM devices by simply adding an ARM .nexe to your app and making a small adjustment to the Native Client manifest. Just get the newest SDK, and you’ll have all the tools you need.

While this will help provide more apps to users with ARM devices, we’re far from done. In 2013 the next generation of Native Client, called Portable Native Client, will introduce true architecture-independence by using LLVM bitcode as the wire format. With Portable Native Client, we’ll be able to support not just today’s architectures, but also those of tomorrow – and developers won’t have to recompile their app.

We look forward to your technical questions on Stack Overflow as well as comments in the discussion forum.

Today, when users are signed in to Google, Chrome sends their searches from the Chrome address bar (“omnibox”) over Secure Sockets Layer (SSL). Starting with Chrome 25 (currently in the Dev and Beta channels), we’re doing the same thing for Chrome omnibox searches performed by users who aren’t signed in to Google.

Serving content over SSL provides users with a more secure and private search experience. It helps ensure that malicious actors who might intercept people’s internet traffic can’t see their queries. Many major sites have begun serving content over SSL by default, such as Gmail in early 2010, Twitter in February 2012, and Facebook in November 2012. Search has also been moving toward encryption. Google introduced Encrypted Search in May 2010 and made encryption the default for signed-in users starting in October 2011. Firefox announced a switch to SSL for all Google searches in July 2012, and Safari did the same thing in September 2012. Chrome is continuing this trend.

Users shouldn’t notice any changes. If anything, their searches will be slightly faster due to Chrome’s implementation of the SPDY protocol, but there should be no other user-visible effect.

Unprefixed support for Content Security PolicyContent Security Policy (CSP) helps you reduce the risk of cross-site scripting and other content injection attacks. Starting in today’s Beta release, you can use the unprefixedContent-Security-Policy HTTP header to define a whitelist of trusted content sources. The browser will only execute or render resources from those sources. For example:

Prefixed support for Shadow DOMWeb Components is a set of cutting edge standards that will make it possible to build reusable widgets for the web. Shadow DOM is a key part of Web Components that enables DOM tree encapsulation. Without it, widgets may inadvertently break pages by using conflicting CSS selectors, class or id names, or JavaScript variables.

We think Shadow DOM is an important step forward for the web, so we've submitted a comprehensive test suite to the W3C to help ensure compatibility between implementations.Other platform features
In addition to the highlights above, today’s Beta release introduces various other web platform features:

Last week’s Beta release of Chrome for Android also brought many features already available on other Chrome versions to Android as well. These features are described in detail in the announcement on the Chromium blog.DevTools
Chrome Developer Tools help you debug the web. We’re rolling out several updates to desktop DevTools in today’s Beta release:

console.clear() helps keep your console clean.

The top toolbar is icon-free, though icons can be re-enabled in settings.

Starting today, you can install Chrome Beta channel for phones and tablets on Android 4.0+ from Google Play. This release includes some of the biggest developer updates to Chrome for Android since its launch last year, bringing many features available on other Chrome versions to Android as well:

With prefixed support for CSS Filters you can apply visual effects like grayscale, blur, and contrast adjustment to the mobile web. Try this demo on Chrome for Android to see filters in action.

The dynamic viewport units vw, vh, and vmin can now be used for responsive design.

The <track> element for video provides a simple, standardized way to add subtitles, captions, screen reader descriptions, and chapters. Note that it doesn’t work for fullscreen video on Chrome for Android yet.

The CSS calc() function can be used anywhere a length is required by a CSS properties. It allows mathematical expressions with addition (‘+’), subtraction (‘-’), multiplication (‘*’), and division (‘/’) to be used as component values.

The @sandbox and @srcdoc attributes of the <iframe> element give you more control over inline frames.

Our technique to make desktop web pages more readable on mobile screens (now called Text Autosizing) has been improved and is more consistent with other browsers.

V8 has been updated to 3.15 bringing a big speed boost; performance on the Octane benchmark improved on average by 25-30%.

Lastly, the new beta comes with an updated stack of Developer Tools. Expect big improvements in measuring your mobile performance with the Timeline's frames mode and easily navigate and edit your active scripts in the revised Sources panel.

You can report any issues you find within the app or at mcrbug.com/new. We’ll be pushing periodic updates so you can test out our latest work as soon as it’s ready. Even better, you can install the Beta alongside your current version of Chrome for Android