Labels:

Labels:

Labels:


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
Labels:


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
Labels:


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
Labels: ,


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
Labels: ,