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. 
• $150,000: compromise with device persistence -- guest to guest with interim reboot, 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.

Posted by Chris Evans, Google Chrome Security Team

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.

Posted by David Sehr, Software Engineer

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.

Posted by Adam Langley, Software Engineer

Earlier today we released Chrome 25 on the Beta channel, and last week we introduced the Beta channel for Chrome for Android. To kick off the new year, we’ve packed these releases full of developer features. You’ll find all the updates described here in both the desktop and Android releases unless otherwise noted.

Unprefixed support for Content Security Policy
Content 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 unprefixed Content-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 DOM
Web 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.

To get started, try the prefixed webkitCreateShadowRoot API available in today’s Beta release. Here’s an example from the HTML5 Rocks Shadow DOM Tutorial:

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:

• The JavaScript Web Speech API enables speech-to-text on the desktop web. Check out this cool tutorial and demo to learn how to add speech to your webpages.
• For speed junkies, the Resource Timing API exposes detailed timing information to JavaScript about subresources loaded by the page, and the User Timing API provides access to high-precision timestamps to help measure web app performance.
• Chromium's IndexedDB implementation now supports concurrent transactions. Some web apps may inadvertently rely on sequential transactions, so be sure to test yours in today’s Beta.
• Various IndexedDB features have been updated to match the spec: setVersion has been replaced with the new upgradeneeded API, and a few old constants have been removed.
• The Web Audio API now exposes an OfflineAudioContext constructor, and a few AudioContext method names have been updated to match the latest spec. Note that Chrome for Android doesn’t support the Web Audio API yet.
• The ::cue pseudo-element lets you style WebVTT cues such as HTML5 video subtitles.

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.
• A timeline setting was added: “Show CPU activity on the ruler.” console.log formatting accepts multiple styles. For example: console.log("%cblue! %cgreen!", "color: blue;", "color: green;").
• The docking toggle switches between most recent modes; “Dock to Right” is now the default alternative.
• Emulate the media type to view print stylesheets and @media blocks.
• The CodeMirror editor, replacing the default DevTools editor in Sources Panel, was updated to v3.

Stay in the loop

Visit chromestatus.com for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates.

We’ll update this post if things change, but at this point all these features are expected to land in the next Stable release. We’ve got a lot more in store for you this year, so get coding!

Posted by Eric Bidelman, Chrome Developer Advocate and Web Platform Enthusiast

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 new Flexible Box Layout Module simplifies the styling of complex layouts.
• 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.
• Unprefixed IndexedDB gives you access to fast, structured client-side storage.
• 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

Posted by Peter Beverloo, Software Engineer and Mobile Web Maestro