Since Google In-App Payments launched in July for developers in the United States, we’ve received great feedback on how easy it is to integrate as well as how simple it is for consumers to use. While the API has been off to a strong start, there’s been a growing demand for availability outside of the United States.

So starting today, we are opening developer enrollment for Google In-App Payments to 17 additional countries. In addition to the United States, developers from Australia, Austria, Belgium, Canada, Denmark, Finland, France, Germany, Ireland, Italy, Japan, the Netherlands, Norway, Portugal, Spain, Sweden, and the United Kingdom can now use the Google In-App Payments API to incorporate an in-context payment experience into applications on the Chrome Web Store and their own sites.

Ease of use: the short payment process for consumers takes place right in the developer’s app or site.

Large existing user base: there are millions of Google Wallet online users in over 140 countries.

Low fees: developers pay just 5% on all transactions.

You can get started accepting payments in your web apps by following the tutorial and get answers to any questions in the forum. We look forward to expanding to even more countries in the future, as well as continuously working to improve the Google In-App Payments experience.

Since we launched Native Client late last summer, our team has been working hard to make the technology more useful to developers. Yesterday at an event held at Google we shared the progress we’ve made towards this goal and showcased work from some of the early adopters of the technology, including Square Enix, Unity Technologies, and Bungie.

One code base for all OSsIn September, we started supporting a set of core Pepper interfaces, suited for 2D graphics, audio, and compute-intensive applications. Since that release, we’ve shipped additional APIs and capabilities, providing native code with more of the capabilities available from JavaScript. These include hardware-accelerated 3D graphics via OpenGL ES 2.0, a mouse lock API, a full-screen API, and much more. One example of the kind of experience Native Client can currently support is Bastion, an award-winning role-playing game from Supergiant Games. Previously limited to Microsoft Windows® and Xbox® systems, the Native Client port of Bastion allows Supergiant to reach users on all popular desktop operating systems, with the safety and simplicity of the web.

Easy porting of previous workIf you have existing code bases in C, C++, or C#, Native Client now allows you to port your existing apps to the web while maintaining just one code base. This was particularly appealing to Spacetime Studios. They ported their multiplayer online game Star Legends to the web in less than two weeks from an existing code base of more than half a million lines of code. The side benefit of being able to maintain their existing development and testing infrastructure further accelerated their delivery of a shipping title.More choices of programming languagesThe community is actively involved in Native Client, porting some of the most popular application middleware. Ports include Unity and Moai game engines, programming language environments Mono and Lua, audio middleware such as fmod and Wwise, as well as the Bullet physics engine. These Native Client ports make the web more accessible to hundreds of thousands of application developers. At the event, we showcased upcoming applications from Heartwood, Silvertree, Exit Strategy, and Dedalord, who used those tools to bring their apps to the web with very little effort. We’ll continue to work with the community to get even more languages and middleware systems ported to Native Client.

We recognize that building a Native Client app is only the start of a successful app. That’s why we’ve enabled distribution of Native Client-based apps via the Chrome Web Store. The Chrome Web Store gives developers a simple, effective strategy to reach over 200 million active users of Google Chrome.

If all this sounds exciting, please visit our new documentation site at gonacl.com. There you’ll find a growing collection of tutorials, examples, videos, reference documentation, and much more.

Questions or suggestions? Join us in the discussion forums. We look forward to seeing some great new apps from Native Client developers.

In March of last year we introduced ANGLE as the engine that would power Chrome's GPU rendering on Windows. At the time it was announced, ANGLE only supported a subset of the OpenGL ES 2.0 API. Thanks to continued work from TransGaming, in collaboration with Google engineers and other contributors, ANGLE has reached an important milestone: It now passes the rigorous OpenGL ES 2.0 test suite and ANGLE version 1.0 has been certified as a compliant GL ES 2.0 implementation. This is a major step forward for the project, and a major event for OpenGL ES support on Windows.

Mac and Linux already enjoy solid OpenGL support, but on Windows OpenGL drivers are not sufficiently widespread to be relied upon. Using ANGLE allows us to issue OpenGL ES commands in Chrome's graphics systems and not worry about the user's computer having OpenGL drivers -- ANGLE translates these commands into Direct3D 9 API calls.

ANGLE helps Chrome use a single, open graphics standard and remain portable across platforms. Because it's a standalone library, open-source project ANGLE can help other software projects in the same way. Firefox, for instance, is already using ANGLE to render WebGL content on Windows.

ANGLE is a necessary step in our continued efforts to push the web platform forward. Without ANGLE, it would be impossible to reliably run WebGL on many Windows computers, so we couldn't enable great applications like MapsGL. We hope WebGL developers and implementors will continue to join us in making ANGLE, and the open web platform, successful.

Today we are announcing the release of Chrome’s new incremental garbage collector (GC) which dramatically improves interactive performance of web apps and HTML5 games.

The V8 project has made huge progress improving peak performance of web apps. With the advent of technologies like WebGL we’re seeing the emergence of highly interactive and graphically intensive apps, such as the new version of Google Maps, new games and demos. But with these new uses comes a need for better interactive performance in JavaScript.

Avoiding pauses is vital to achieving good interactive performance. Previously, garbage collection pause times depended on the amount of memory used. Therefore, large interactive apps were impacted by pauses that caused hiccuping. V8’s new GC reduces pause times dramatically while maintaining great peak performance and memory use.

To evaluate the new GC, we took the most memory intensive peak performance test from the V8 Benchmark Suite and used it to make a stress test for interactive performance. In our testing the maximum time to render a frame including pause time is reduced from 272ms to 50ms.

The new GC in Chrome improves interactive performance and opens up new possibilities for the interactive web. If you are developing highly interactive web apps or games, please try it out and share your experiences. It is available now on the dev channel.

In September 2010 we announced the WebP image format with lossy compression. WebP was proposed as an alternative to JPEG, with 25–34% better compression compared to JPEG images at equivalent SSIM index. We received lots of feedback, and have been busy improving the format. Last month we announced WebP support for animation, ICC profile, XMP metadata and tiling. Today, we introduce a new mode in WebP to compress images losslessly, and support for transparency – also known as alpha channel – in both the lossless and lossy modes.

With these new modes, you can now use WebP to better compress all types of images on the web. Photographic images typically encoded as JPEG can be encoded in WebP lossy mode to achieve smaller file size. Icons and graphics can be encoded better in WebP lossless mode than in PNG. WebP lossy with alpha can be used to create transparent images that have minimal visual degradation, yet are much smaller in file size. Animations compressed as GIFs can use animation support in WebP.

New lossless mode

Our main focus for lossless mode has been in compression density and simplicity in decoding. On average, we get a 45% reduction in size when starting with PNGs found on the web, and a 28% reduction in size compared to PNGs that are re-compressed with pngcrush and pngout. Smaller images on the page mean faster page loads.

New transparency mode

Today, webmasters who need transparency must encode images losslessly in PNG, leading to a significant size bloat. WebP alpha encodes images with low bits-per-pixel and provides an effective way to reduce the size of such images. Lossless compression of the alpha channel adds just 22% bytes over lossy (quality 90) WebP encoding. Smaller alpha overhead means richer images on webpages.

You can find a more detailed compression study for these modes here and sample images in the WebP-Gallery. The bit stream specification has not been finalized, and the encoding and decoding implementations have not yet been optimized for processing speed. We encourage you to try it out on your favorite set of images, check out the code, and provide feedback. We hope WebP will now handle all your needs for web images, and we're working to get WebP supported in more browsers.

Interested in making your Chrome Extension (or packaged app) talk using synthesized speech? Chrome now includes a Text-to-Speech (TTS) API that’s simple to use, powerful, and flexible for users.

Let’s start with the "simple to use" part. A few clever apps and extensions figured out how to talk before this API was available – typically by sending text to a remote server that returns an MP3 file that can be played using HTML5 audio. With the new API, you just need to add "tts" to your permissions and then write:

chrome.tts.speak('Hello, world!');

It’s also very easy to change the rate, pitch, and volume. Here’s an example that speaks more slowly:

chrome.tts.speak('Can you understand me now?', {rate: 0.6});

How about powerful? To get even fancier and synchronize speech with your application, you can register to receive callbacks when the speech starts and finishes. When a TTS engine supports it, you can get callbacks for individual words too. You can also get a list of possible voices and ask for a particular voice – more on this below. All the details can be found in the TTS API docs, and we provide complete example code on the samples page.

In fact, the API is powerful enough that ChromeVox, the Chrome OS screen reader for visually impaired users, is built using this API.

Finally, let's talk about flexibility for users. One of the most important things we wanted to do with this API was to make sure that users have a great selection of voices to choose from. So we've opened that up to developers, too.

The TTS Engine API enables you to implement a speech engine as an extension for Chrome. Essentially, you provide some information about your voice in the extension manifest and then register a JavaScript function that gets called when the client calls chrome.tts.speak. Your extension then takes care of synthesizing and outputting the speech – using any web technology you like, including HTML5 Audio, the new Web Audio API, or Native Client.

Here are two voices implemented using the TTS Engine API that you can install now:

These voices both use Native Client to synthesize speech. The experience is very easy for end users: just click and install one of those voices, and immediately any talking app or extension has the ability to speak using that voice.

If a user doesn't have any voices installed, Chrome automatically speaks using the native speech capabilities of your Windows or Mac operating system, if possible. Chrome OS comes with a built-in speech engine, too. For now, there's unfortunately no default voice support on Linux – but TTS is fully supported once users first install a voice from the Chrome Web Store.

Now it's your turn: add speech capability to your app or extension today! We can't wait to hear what you come up with, and if you talk about it, please add the hashtag #chrometts so we can join the conversation. If you have any feedback, direct it to the Chromium-extensions group.

Editor's note: The Chromium WebGL team worked closely with the Maps team to help make MapsGL a reality. We invited a member of the Maps team to talk about their experience with MapsGL in the hope that it would help inform others who are interested in deploying a large scale WebGL app.

At this point it's almost hard to remember, but when Google Maps was first released in 2005, it was one of the first web applications to demonstrate what was possible with AJAX and the web platform. This project was a challenge technically but we’d like to think that it helped to fire the imaginations of web developers around the world.

Today, the Maps team is launching a beta of a brand new experience we call MapsGL. MapsGL is one of the first large scale applications to be built on top of WebGL. MapsGL makes use of 3D rendering and hardware graphics acceleration to provide an experience that is seamless, smooth, and runs directly in the browser.

Technically, MapsGL brings significant changes to how map and image tiles are rendered on the client and server. Rather than loading pre-rendered image tiles from servers, vector data for the map is sent to the browser and rendered on the fly using WebGL. This generally means that less data needs to be sent to the browser, but also that every aspect of the map needs to be rendered on the order of ~20ms per frame in order to achieve a reasonable frame rate. Imagery transitions in Maps are also enhanced by loading 3D metadata along with image tiles, allowing Maps to provide rich 3D transitions between different levels and angles of imagery.

While developing MapsGL, we found that WebGL draws from both native and web app backgrounds. For those used to working on web applications, WebGL adds a lot of functionality, but also increases the complexity of what you need to build and test. Even though WebGL is cross platform, performance varies dramatically across graphics hardware and operating systems - and what improves performance on one may hurt performance elsewhere - so testing across a wide array of setups is critical.

We also found that performance dependent Javascript and WebGL optimizations were needed in order for MapsGL to run properly on slower hardware. For example, there are a number of users with graphics cards that can't currently run WebGL content. In these cases, we don’t give the user the ability to opt-in and they can continue with the current Maps experience. Other graphics cards have somewhat poor performance for some key operations, which we measure with a small benchmark when the user first opts-in. In these cases, MapsGL falls back on a hybrid approach where we use pre-rendered raster tiles for the background of the map and only dynamically render labels on top of these.

We hope that MapsGL makes you excited to use WebGL in your own app. WebGL enables 3D graphics and immersive experiences in the browser that were formerly impossible. As WebGL becomes more robust and graphics card drivers improve, we can't wait to see what web developers will create with it. Check out the WebGL documentation and get started!

Today we are introducing an early preview of Dart, a class-based optionally typed programming language for building web applications. Dart’s design goals are:

Create a structured yet flexible language for web programming.

Make Dart feel familiar and natural to programmers and thus easy to learn.

Ensure that Dart delivers high performance on all modern web browsers and environments ranging from small handheld devices to server-side execution.

Dart targets a wide range of development scenarios: from a one-person project without much structure to a large-scale project needing formal types in the code to state programmer intent. To support this wide range of projects, Dart has optional types; this means you can start coding without types and add them later as needed. We believe Dart will be great for writing large web applications.

Dart code can be executed in two different ways: either on a native virtual machine or on top of a JavaScript engine by using a compiler that translates Dart code to JavaScript. This means you can write a web application in Dart and have it compiled and run on any modern browser. The Dart VM is not currently integrated in Chrome but we plan to explore this option.

The language comes with a set of basic libraries and tools for checking, compiling, and running Dart code, all of which will evolve further with your participation. We've made the language and preliminary tools available as open source on dartlang.org. Check out the site to give feedback, learn more about Dart, and participate in its development.

We look forward to rapidly evolving Dart into a solid platform for structured web programming.

Are you already a happy user of Chrome Developer Tools but always wanted that particular feature added to make you even more productive? Then we have some exciting news for you: our developer tools are now extensible!

You can now add new panels and sidebar section panes, retrieve network requests data, evaluate scripts on the page being inspected, and add custom audit rules.

The extension support is still experimental, but we wanted to let you know early, so we can incorporate your feedback before releasing the APIs.

Here’s how to get started with writing extensions for Chrome Developer Tools:

Use the dev channel of Chrome as the APIs are still under development;

The developer tools extension pages get access to the chrome.experimental.devtools.* APIs which are described further in our docs. Be sure to check out the sample extensions, which include extensions for jQuery and FirePHP users and a simple audit extension that finds broken links.

For a richer example, you can also check out Page Speed for Chromium, which uses the extensions API to provide Page Speed suggestions right in the Chrome Devtools UI.

We recently expanded the reach of the Chrome Web Store from the U.S. to 24 more countries. Developers from around the world have already launched successful apps in the Chrome Web Store to US users. Now all developers can reach a global user base.

What makes this global reach even more interesting is the global payments infrastructure that goes along with it. The store allows developers from 20 countries to sell apps in the store, and users to buy apps in their local currency. We also recently launched the In-App Payments API, which allows developers (U.S.-only for now; international soon) to sell virtual goods in their apps. Integration is easy and transaction fees are only 5%. Graphicly, an early user of in-app payments, saw its net revenues double after starting to use the API and experienced an even bigger rise in profit margins due to increased conversions and lower transaction fees.

In keeping with our international theme, we’d like to highlight a few developers from different parts of the world who have utilized Chrome’s global reach to find success in the store:

Audiotool is an online music production app that was built by a team of German developers. They saw the Chrome Web Store as a way to present their app to an international audience. Audiotool’s traffic increased by 20% after launching in the store, and this motivated the team to release another app in the store.

Psykopaint is the brainchild of French developer Mathieu Gosselin. The Chrome Web Store provided Mathieu an opportunity to get his photo painting app noticed outside of France. Traffic to Psykopaint has jumped by 700% since it launched in the store and Mathieu has found that Chrome Web Store users tend to be more engaged than other users.

Finally, Nulab, a Japanese company, launched its online diagramming app, Cacoo, in the store to expand its user base outside Japan. In just a few months after Cacoo was released in multiple languages in the Chrome Web Store, the app already accounts for 20% of Cacoo’s user base.

The experience of Audiotool, Psykopaint and Nulab shows that no matter where you’re located, you can always find a global audience for your applications in the Chrome Web Store. To learn more about the stories of these and other successful Chrome Web Store developers, read our case studies. And if you want to find out more about posting your app in the store, visit our documentation at code.google.com/chrome/webstore.

This year at the Game Developers Conference (GDC) Online we have organized a Developer Day on Oct. 10th full of Google information for game developers. It will feature hardcore technical information on Google products and platforms delivered by Google engineers and developer advocates. We’ll discuss the latest projects we’re working on and how our online technologies can help you better create, distribute, and monetize games that reach a larger audience than ever before. We’ll present everything from how developers can build hardware accelerated 3D games for the browser with WebGL to the game framework used to bring Angry Birds to the Web.

In addition to the Developer Day, we will also have a booth on the Expo floor on Oct. 11th-12th where we’ll have representatives from the Chrome Web Store, Native Client, WebGL, App Engine, Google+, In-App Payments, Google TV, and AdSense/AdMob demoing technologies and platforms for game developers. Come by booth 503 to try out Google products and ask questions, or hang out in our Google TV lounge.

A few months ago, we introduced Non-Admin Google Chrome Frame on the developer channel for testing. We deployed it to the beta channel two weeks ago and we are now bringing Non-Admin to the stable channel. Head over here to install it and let us know how it goes.

If you have installed the developer or beta channel version and wish to switch to the stable version, you'll need to uninstall Chrome Frame and then install via the above link. Note that the uninstall experience is smoothest if you close all Internet Explorer windows prior to uninstalling Chrome Frame.

In addition to Non-Admin Chrome Frame moving to the stable channel, we are rolling out a change to the default Chrome Frame installer; it will now run at Admin level by default and will fall back to Non-Admin mode if the user does not have the necessary permissions on their machine. This will allow all users to download a single installer that just works. This installer is available at the Chrome Frame download page.

Yesterday we made a small change in Chrome Web Store’s app upload flow: when you upload new apps and extensions to the Chrome Web Store, or edit one of your existing items, you'll be prompted to provide us with new promotional image assets. We are asking you for these assets so that we can highlight your apps and extensions in a brand new store layout that our team is working on.

What's new:

(Required) You’ll need to provide us with a large rectangular image to identify your app, in addition to assets you already provide - your app icon and at least one screenshot.

(Optional) You can provide us with an even larger rectangular image format as well.

What's different

The screenshot dimensions have grown larger with a wider aspect ratio.

The (optional) marquee image dimensions have also grown larger.

What's the same

The specification and dimensions for the icon file

To make things easier, we only require screenshots in the new dimensions going forward -- we'll automatically scale them as needed to make them visible in the current store layout. You can read the details about the new requirements on our image guidelines page. If you have any questions on these changes, feel free to reach us at our discussion group.

I’ve been a bit too busy playing and testing new browser-based games such as Monster Dash, Angry Birds, and the newly released SONAR. Bigger and better games are coming to the browser rapidly (and just wait until Native Client with 3D lands in Chrome), and it’s hard to keep up with the technology and scene. So what better way to bring everyone together to share stories and keep up to date than to hold a conference dedicated to HTML5 game development?

New Game, the first North American conference for HTML5 game developers, is now open for registration. You are invited to join hundreds of HTML5 game developers for two days of technical sessions and case studies from developers and publishers who brought their games to the open web platform. The event will take place November 1-2, 2011 at the beautiful Yerba Buena Center for the Arts in San Francisco, CA.

This year, New Game looks at what is possible in the browser today. Sessions will focus on the technologies that have elevated the browser-based gaming experience, such as WebGL, Canvas, and JavaScript performance techniques. In addition, the conference will feature sessions exploring and analyzing lessons-learned from recent HTML5 game launches.

New Game is honored to have Rich Hilleman, EA’s Chief Creative Officer, keynote the event. The schedule also includes sessions from Mozilla, Spil, Opera, Google, Bocoup, GameSalad, Moblyng, and others. After the first day, we’ll network with our colleagues and share high scores at the New Game party, open to all registered attendees.

Wouldn’t it be great if you could create web apps using your existing C and C++ code? Native Client lets you do just that, and it is now enabled for Chrome Web Store apps in Google Chrome’s beta channel.

Native Client apps live on the web platform, so you don’t need to create separate versions of your app for each operating system. Rather than relying on OS-specific APIs, Native Client apps use Pepper, a set of interfaces that provide C and C++ bindings to the capabilities of HTML5. This means that once you’ve ported your code to Native Client, it will work across different operating systems, and you only need to maintain one code base.

Today Native Client supports the Pepper APIs for 2D graphics, stereo audio, URL fetching, sandboxed local file access (File API), and asynchronous message passing to and from JavaScript. In future releases we will be adding support for hardware accelerated 3D graphics (OpenGL ES 2.0), fullscreen mode, networking (WebSockets and peer-to-peer connections), and much more. As new capabilities are added to HTML5 and Pepper, they will become available to Native Client.

This functionality does not come at the expense of security. To ensure that Native Client is as safe as JavaScript, Native Client code is isolated from the operating system by two nested security sandboxes: the Native Client sandbox and the Chrome sandbox. And unlike NPAPI plugins or ActiveX controls, Native Client apps do not have access to the underlying OS APIs.

We encourage you to start developing apps with Native Client. You can download the SDK and find tutorials, examples, API documentation, and our FAQ on the Native Client site. Once version 14 of Chrome hits stable channel, you’ll be able to upload your Native Client apps to the Chrome Web Store, where you can reach Chrome’s 160 million users.

The next milestone for Native Client is architecture independence: Portable Native Client (PNaCl) will achieve this by using LLVM bitcode as the basis for the distribution format for Native Client content, translating it to the actual target instruction set before running. Until then the Chrome Web Store will be the only distribution channel for Native Client apps. This will help us ensure that all Native Client apps are updated to PNaCl when it’s ready – and in the meantime avoid the spread of instruction set architecture dependent apps on the web. We’ll be providing updates on the progress of PNaCl on this blog.

In today’s browser ecosystem, web apps are completely disconnected or require the use of complicated APIs in order to make use of a third-party service, e.g., posting a comment to Twitter from your custom publishing domain. What if we could give sites the ability to leverage these services without any knowledge of the chosen service, except that it provides some set of predefined functionality?

Android OS addresses this problem with Intents, a facility for late run-time binding between components in the same or different applications. In the Intents system, the client application requests a generic action, e.g. share, and specifies the data to pass to the selected service application. The user is given a list of applications which have registered that they can handle the requested intent. The user-selected application is created in a new context and passed the data sent from the client, the format of which is predefined for each specific intent type.

We are hard at work designing an analogous system for the web: Web Intents. This web platform API will provide the same benefits of Android Intents, but better suited for web applications. When designing the system, we have first and foremost been interested in creating a simple, easy-to-use API. With Web Intents, you will be able to connect your web app to a service with as little as two lines of code! Chrome will perform the heavy lifting for you. As with Android, Web Intents documents an initial set of intent actions (edit, view, share, etc.) that likely cover the majority of use cases on the web today; however, as the web grows and sites provide more functionality, new intent actions will be added by services that document these intents, some more popular than others. To foster development and use of intents, we plan to create a site to browse existing intents and add new intents.

Consider an online photo storage site run by a cash-strapped startup: the developers don’t have the resources to add image editing abilities to their app, but they feel the site won’t be a hit without it. The Web Intent system will make it easy for them to offer this with little effort.

// This callback will be called when the service replies with the edited// image data.function loadEditedImage(data) { var image = document.getElementById(‘image’); setImageData(image, data);}

When the user visits her favorite memegen service, the site will request registration to handle the EDIT intent for files of type ‘image/*’ using the following declaration:

<intent action=”http://webintents.org/edit” type=”image/*” />

When the user initiates the EDIT action, this service is presented to the user, along with other registered image editors. Once the user selects Meme Generator, the referenced site is opened in a new context and is able to load the image data from the intent payload:

// Send the generated meme back to the client. intent.postResult(getImageData(memeImg));};

Once postResult() is called, the Meme Generator context is closed and the output data is sent back to the client via the callback passed to startActivity().

Mozilla is also actively exploring this problem space. In fact we’re working closely with Mozilla engineers to unify our two proposals into one simple, useful API. Visit the examples page to try out the feature in any current browser. To explore using the API in your site, check out out the JavaScript shim, which provides an implementation of the API for browsers that have not implemented this feature. We are rapidly prototyping this feature, so check back soon for an announcement when Web Intents is available behind a flag in Chrome.

The WebSocket protocol specification is now largely stable, having solved previous security concerns. As such, we’ve updated Chromium to support the latest version (draft-ietf-hybi-thewebsocketprotocol-10) on the dev channel (14.0.835.2). Given that the specification is now in “last-call” and and no further breaking changes are expected, it should now be safe to use WebSockets for production application development.

Please note that the new protocol is incompatible with one which Chromium previously supported (draft-ietf-hybi-thewebsocketprotocol-00), so existing WebSocket-based services may break. Please upgrade your servers to ones which support HyBi 10. Existing JavaScript code still works once the protocol version used by the browser and server match.

The new protocol introduces some exciting new features like binary message support and compression support, but these are not quite ready yet in Chrome and will come shortly - hang tight!

We recently launched the much awaited In App Payments API in the US. This API provides a simple and effective way to monetize your apps in the Chrome Web Store, allowing you to complete transactions with buyers from 140 countries. Integration is simple - all you need is to do is to insert a few lines of code. An even more exciting feature of the API is the 5% flat transaction fee pricing. To learn more about In-App Payments, check out our docs and a sample app complete with source code or watch our short video. We look forward to expanding this service to additional developer locations as quickly as possible.

With our in-store payments, developers in Australia, Austria, Belgium, Canada, Denmark, Finland, France, Germany, Hong Kong, Italy, Japan, Netherlands, New Zealand, Norway, Portugal, Singapore, Spain, Sweden, Switzerland, United Kingdom can now complete merchant account sign up and start adding their paid apps to the Chrome Web Store. Paid apps will be published to international users later this year. In the meantime, you can localize your app listing to make it accessible to more people and be eligible for promotion in local store fronts.

We’ve also added the ability to target or exclude specific markets. In this launch, Chrome Web Store developers can publish their apps to the following regions: Argentina, Australia, Austria (new), Belgium (new), Brazil, Canada, Czech Republic (new), Denmark (new), Finland (new), France, Germany, Hong Kong (new), India, Indonesia (new), Israel (new), Italy, Japan, Mexico, Netherlands, New Zealand (new), Norway (new), Philippines (new), Poland, Portugal, Russia (new), Singapore (new), Spain, Sweden (new), Switzerland (new), United Kingdom and United States. Our users will only see apps that were published for their market. We also added support for our various featured lists to be targeted by market, allowing users to see the best apps for their market.

Extensions are powerful pieces of software in modern browsers, and as such, you should help ensure that your extensions are not susceptible to security exploits. If an attacker manages to exploit a vulnerability in an extension, it’s serious business because they may gain access to the same privileges that the extension has.

The Chrome extensions system has a number of built-in protections to make it more difficult to introduce exploitable code, but certain coding patterns can still open up the risk of exploits like a cross-site scripting (XSS) attack. Many of these mistakes are common to web programming in general, so it wouldn’t be a bad idea to check out one of the many good articles on the net about XSS bugs. Here are some of our recommendations for writing healthier extensions.

Minimize your permissions

The most important thing to consider is whether you’re declaring the minimal set of permissions that you need to function. That way, if you do have a security bug in your code, the amount of permissions you’re exposing to the attacker is minimal as well. Avoid requesting (*/*) permissions for hosts if you only need to access a couple, and don’t copy and paste your manifest from example code blindly. Review your manifest to make sure you’re only declaring what you need. This applies to permissions like tabs, history, cookies, etc. in addition to host permissions. For example, if all you’re using is chrome.tabs.create, you don’t actually need the tabs permission.

Use content_security_policy in your manifest

Starting in Chrome 14, we will begin supporting Content Security Policy in extensions via the content_security_policy manifest field. This allows you to control where scripts can be executed, and it can be used to help reduce your exposure to cross-site scripting vulnerabilities. For example, to specify that your extension loads resources only from its own package, use the following policy:

"content_security_policy": "default-src 'self'"

If you need to include scripts from specific hosts, you can add those hosts to this property.

Don’t use <script src> with an HTTP URL

When you include javascript into your pages using an HTTP URL, you’re opening your extension up to man-in-the-middle (MITM) attacks. When you do so in a content script, you have a similar effect on the pages you’re injected into. An attacker on the same network as one of your users could replace the contents of the script with content that they control. If that happens, they could do anything that your page can do.

If you need to fetch a remote script, always use HTTPS from a trusted source.

Don’t use eval()

The eval() function is very powerful and you should refrain from using it unless absolutely necessary. Where did the code come from that you passed into eval()? If it came from an HTTP URL, you’re vulnerable to the same issue as the previously mentioned <script> tag. If any of the content that you passed into eval() is based on content from a random web page the user visits, you’re vulnerable to escaping bugs. For example, let’s say that you have some code that looks like this:

If it turned out that you had a bug in your parsing code, the address might wind up looking something like this:

'); dosomethingevil();

There’s almost always a better alternative to using eval(). For example, you can use JSON.parse if you want to parse JSON (with the added benefit that it runs faster). It’s worth the extra effort to use alternatives like this.

Don’t use innerHTML or document.write()

It’s really tempting to use innerHTML because it’s much simpler to generate markup dynamically than to create DOM nodes one at a time. However, this again sets you up for bugs in escaping your content. For example:

This would allow an attacker to make an address like the following and once again run some script in your page:

<script>dosomethingevil();</script>

Instead of innerHTML, you can manually create DOM nodes and use innerText to insert dynamic content.

Beware external content

In general, if you’re generating dynamic content based on data from outside of your extension (such as something you fetched from the network, something you parsed from a page, or a message you received from another extension, etc.), you should be extremely careful about how you use it. If you use this data to generate content within your extension, you might be opening your users up to increased risk.

You can also read a few more examples of the issues discussed here in our extension docs. We hope these recommendations help you create better and safer extensions for everyone.

In Chrome 13, we added some new capabilities to content scripts and proxy management.

First, you can now make cross-origin XMLHttpRequest calls with the privileges of the extension directly from your content script. You will no longer need to relay these requests through a background page; this should simplify your code. In some cases, it may even eliminate your need to use a background page. Here’s a sample extension which demonstrates the old way a content script could make a cross domain request. As you can see, the extension required a background page to route the cross-origin calls through a chrome.extension.onRequest listener. Using the new content script cross-origin capabilities, we were able to successfully rewrite the extension to completely eliminate the background page requirement. This reduces the memory required to run the extension, and reduces code complexity as well. This also means that Greasemonkey scripts that use GM_xmlhttpRequest - such as the classic Book Burro - will now work in Chrome.

Second, we improved how match patterns work. Until this release you could specify a matches array for your content script - the URLs over which it should operate. In Chrome 13 you can now also specify an exclude_matches array, where you can indicate the pages in which your content scripts should not work. This should allow more precise targeting of your content script.

Finally, we added support for the @run-at command for imported Greasemonkey scripts, so you can control when your script is loaded in the same way you’ve been able to do for content scripts. Running scripts at different points in a page's lifecycle can enable additional functionality. For example, we've written a script which runs at "document-start" and lists all of the HTTP resources included in the current page.

In addition to these improvements to scripts, we’ve been working hard to allow extensions to manage Chrome’s proxy settings using different configuration options. With the Proxy Extension API, you can now configure proxy settings by choosing from several options including auto detection, the host OS’s system default, PAC scripts or fixed ProxyRules.

These new configuration options allow for more fine grained proxy controls, which we invite you to try out. There are already several 3rd party extensions available in the Chrome Web Store that showcase the API and its new capabilities, including Proxy Anywhere and Proxy SwitchyPlus.

Let us know what you think of these new features and what else you might like to see us do by joining the discussion at chromium-extensions@chromium.org.

A few weeks ago, we became aware of a security issue with WebGL: shaders could be used to indirectly deduce the contents of textures uploaded to the GPU. As a result, the WebGL specification was updated to be more restrictive when it comes to using cross-domain images and videos as WebGL textures.

As a result, Chrome 13 (and Firefox 5) will no longer allow cross-domain media as a WebGL texture. The default behavior will be a DOM_SECURITY_ERR. However, applications may still utilize images and videos from another domain with the cooperation of the server hosting the media, otherwise known as CORS.

CORS support for MediaElements has also been fully implemented in WebKit by setting a new .crossOrigin attribute. This means that sophisticated applications that were using cross-origin textures before, can continue to do so, assuming the hosting image server grants the necessary cross-origin permission using CORS. If you want to enable CORS request on an image, all you have to do is add one line of code:

Another nice property that we gain from this new setting is the ability to read cross-domain image data set on a 2D canvas. Normally, filling a canvas with a remote image (e.g. ctx.drawImage()) flips the origin-clean flag to false. Attempting to read back the pixels using ctx.toDataURL() or ctx.getImageData() throws a SECURITY_ERR. This is to prevent information leakage. However, when .crossOrigin is set (and the remote server supports CORS), the read is possible. For example:

Unfortunately, this new restriction in WebGL means that some existing content will break. We’ve already started working with external image and video hosting services like Flickr to evangelize the use of CORS on their images.

You can test this new behavior today using images from Picasa, which already sends a CORS header allowing cross-origin requests, and the Chrome dev channel.

When we talk Chromebooks with our developer friends, a common reaction we get is “I can see why my [insert-relative-here] would use it, but I need my PC for coding”. Over the last few years, browser-based coding has grown from a research topic to a viable practice. You can already find many development apps on the Chrome Web Store today. Some are conventional code editors and IDEs, built right into the browser. Others are oriented more around prototyping and design. There are also many tools for project management.

First up, IDEs. You can now code, debug, and deploy real programs from the browser. A popular example at Google IO was Cloud9, an IDE for JavaScript, Python, PHP, and Ruby. Cloud9 uses the HTML5 FileSystem capability and AppCache to sync files, so you can even code offline. There are many other IDEs in the web store too, such as Kodingen, Codey, Akshell, eXo Cloud IDE, and PHPAnywhere.

It’s not all about coding though. There are also apps focusing on web design, for people who want to make a web page without coding or perhaps experiment with a few concepts early on. Being able to edit and design web pages inside the tool that will display them is a very powerful concept. BuildorLite and BuildorPro let you construct a web page via a graphical user interface, and publish it straight on their servers. Handcraft and Mockingbird are two apps aimed at design and prototyping. And if you want a scratchpad to try a few coding experiments, check out JSFiddle.

Launching software isn’t just about designing and coding your apps; it’s also about managing the entire workflow, from planning release schedules to triaging bug reports. One example is GitHub Issues, providing a quick, app-like, way to track project issues. Another is Launchlist Pro, a checklist you can use to launch your website.

Chrome aims to bring simplicity, speed, and security to all users, and that includes developers. Being cloud-based means these tools are always up to date, and running inside the browser’s sandbox minimises the security risk to your machine. There’s no complicated install process and the only dependency is Chrome itself, which is automatically kept up to date. Just install the app and get coding.

We’re especially excited about what this means for new developers, as programming tools have never been more accessible to everyone. So whether you’re a seasoned veteran or just looking to get started, visit the Chrome Web Store today and build something awesome in your browser!

We released Google Chrome Frame in September 2009 to expand the reach of modern web technologies and help developers take advantage of HTML5's capabilities. Since then, we've seen great adoption of the plug-in by end users and developers. Even more exciting, we’ve heard from developers that Google Chrome Frame is enabling them to create legacy-free apps that are easier to build, maintain, and optimize.

However, there was one remaining obstacle to making Chrome Frame accessible to users of older browsers - users needed to have administrative privileges on their machines to install Chrome Frame. At this year's Google I/O we announced this obstacle has finally been removed.

Non-Admin Chrome Frame runs a helper process at startup to assist with loading the Chrome Frame plug-in into Internet Explorer. The helper process is designed to consume almost no system resources while running. Once installed, non-admin users will have the same no-friction experience that admin users of Chrome Frame have today.

You can try it yourself by installing the new non-admin version of Chrome Frame here. This is now available in our developer channel and is coming to stable channel very soon.

For more technical details, please see the Chrome Frame FAQ. Please share your feedback in our discussion group and if you encounter any bugs while using Chrome Frame, please file them on Chromium's issue tracker. We’ll be working hard to bring Non-Admin Chrome Frame up to the beta and stable channels over the coming weeks. You can help us move this up to stable as quickly as possible by trying out the current release and sending us your feedback!

Valgrind is a great tool for detecting memory errors. We are running many Chromium tests under Valgrind and it has helped us find hundreds of significant bugs. However, when we run binaries under Valgrind, testing becomes at least 10 times slower. This huge slowdown costs us more than just machine time; our trybots and buildbots can’t provide fast feedback and some tests fail due to timeouts.

A month ago we released AddressSanitizer (aka ASan), a new testing tool. ASan consists of two parts:

A compiler which performs instrumentation - currently we use a modified LLVM/Clang and we're trying to contribute our code to the core LLVM package.

A run-time library that replaces malloc(), free()and friends.

The custom malloc() allocates more bytes than requested and “poisons” the redzones around the region returned to the caller. The custom free() “poisons” the entire region and puts it into quarantine for some time. The instrumented code produced by the compiler checks if the address being accessed is poisoned and if so, reports an error. The compiler also inserts poisoned redzones between objects on stack to catch stack buffer overrun/underrun.

ASan helps us find a subset of bugs that are detectable by Valgrind like heap buffer overrun/underrun (out-of-bounds access) and “Use after free.” It can also detect bugs that Valgrind can not find, such as stack buffer overrun/underrun. Last month alone, ASan helped us find more than 20 bugs in Chromium including some that could have potentially led to security vulnerabilities.

What makes ASan even more powerful than other comparable tools is its speed. On SPEC CPU2006 benchmarks the average slowdown is about 2x. On Chromium’s “browser_tests”, the slowdown is about 20%. If you are curious to learn why ASan is faster than comparable tools read this article.

Today ASan works only on Linux (x86 and x86_64) and ChromiumOS, but we're planning to port it to other platforms in the near future. In the coming months we also plan to setup various ASan buildbots and trybots for Chromium.

The AddressSanitizer home page has the instructions for running it with your favorite project outside of Chromium. If you are working on Chromium, refer to this page for instructions. If you have any questions or suggestions, feel free to contact address-sanitizer@googlegroups.com

When the Google Chrome Security Team isn’t busy giving prompt attention to finding and fixing bugs, we’re always looking for new security features to add and hardening tweaks to apply. There are some changes worth highlighting in our current and near-future Chromium versions:

Chromium 11: strong random numbers for the webWe added a new Javascript API for getting access to a good source of system entropy from a web page. The new API is window.crypto.getRandomValues. Web pages should not currently be using Math.random for anything sensitive. Instead of making a round-trip to the server to generate strong random numbers, web sites can now generate strong random numbers entirely on the client.

You can now force HTTPS for any domain you want, and even “pin” that domain so that only a more trusted subset of CAs are permitted to identify that domain.

It’s an exciting feature but we’d like to warn that it’s easy to break things! We recommend that only experts experiment with net internals settings.

Chromium 13: blocking HTTP auth for subresource loadsThere’s an unfortunate conflict between a browser’s HTTP basic auth dialog, the location bar, and the loading of subresources (such as attacker-provided <img&gt tag references). It’s possible for a basic auth dialog to pop up for a different origin from the origin shown in the URL bar. Although the basic auth dialog identifies its origin, the user might reasonably look to the URL bar for trust guidance.

To resolve this, we’ve blocked HTTP basic auth for subresource loads where the resource origin is different to the top-level URL bar origin. We also added the command line flag switch --allow-cross-origin-auth-prompt in case anyone has legacy applications which require the old behavior.

Chromium 13: Content-Security-Policy supportWe added an initial implementation of Content Security Policy, which was first introduced in Firefox 4. You can use the X-WebKit-CSP header to experiment with our implementation. We’re working with Mozilla and others through the W3C to finish the standard. Once that’s done, we’ll remove support for the X-WebKit-CSP header and add support for the final header name. Please feel encouraged to kick the tires and let us know how we can improve this feature!

Chromium 13: built-in certificate pinning and HSTSWe’re experimenting with ways to improve the security of HTTPS. One of the sites we’re collaborating with to try new security measures is Gmail.

As of Chromium 13, all connections to Gmail will be over HTTPS. This includes the initial navigation even if the user types “gmail.com” or “mail.google.com” into the URL bar without an https:// prefix, which defends against sslstrip-type attacks.

The same HSTS technology also prevents users from clicking through SSL warnings for things such as a self-signed certificate. These attacks have been seen in the wild, and users have been known to fall for such attacks. Now there’s a mechanism to prevent them from doing so on sensitive domains.

In addition in Chromium 13, only a very small subset of CAs have the authority to vouch for Gmail (and the Google Accounts login page). This can protect against recent incidents where a CA has its authority abused, and generally protects against the proliferation of signing authority.

Chromium 13: defenses for self-XSS via javascript URLsWorking together with Facebook and other browser vendors, we’re trialing a self-XSS defense that makes it harder for users to shoot themselves in the foot when they are tricked into pasting javascript: URLs into the omnibox.

This is an interesting area because it’s hard to know what detail of instruction it is possible to trick a user into following. It is also hard to measure success until a large percentage of installed browsers have the defense (thus forcing the attackers to adapt their approach).

Still hiring!We are always looking to expand the Google Chrome Security Team, and we’re looking for a wide range of talents for both Chrome and ChromeOS. We can promise exciting and varied work, working to protect hundreds of millions of users and working alongside the best in the industry. Why not have a look at our job posting?

Google.com's new Instant Pages feature, announced earlier today, makes some sites appear to load almost instantly when you click on them from the search results page. The feature is enabled by prerendering, a technology that we built into the upcoming version of Chrome, currently in the Dev channel. You can see Instant Pages in action in this video:

What is prerendering? Sometimes a site may be able to predict with reasonable accuracy which link the user is most likely to click on next--for example, the 'next page' link in a multi-page news article. In those cases, it would be faster and better for the user if the browser could get a head start loading the next page so that when the user clicks the page is already well on its way to being loaded. That's the fundamental idea behind prerendering. The browser fetches all of the sub-resources and does all of the work necessary to display the page. In many cases, the site simply seems to load instantly when the user clicks.

Although Google.com is the most high profile site to use prerendering, it's a technology that is available to any site. Triggering prerendering well, however, is challenging to do correctly and will only be useful to a handful of sites that have a high degree of certainty of where their users will click next. Triggering prerendering for the wrong site could lead to the link the user did click on loading more slowly.

The vast majority of sites will automatically work correctly when a third party like Google.com asks Chrome to prerender them. If you're interested in testing how your page behaves when being prerendered you can use this sample page. If you want your page to behave differently, you can use Chrome's new experimental page visibility API to detect prerendering.

The page visibility API - which is in the early stages of standardization in the webperf working group - can help developers understand the visibility status of their page: whether it's in a foreground tab, a background tab, or being prerendered. This is still an experimental implementation and it may change or even be removed in the future, which is why for the time being we've prefixed the property names with "webkit.” Although the page visibility API is useful for detecting prerendering, it also has many other applications--for example, allowing a site to pause expensive physics calculations when the page isn't visible.

Modern web applications are becoming increasingly complex. To achieve functionality previously only available in desktop applications, they often comprise many frameworks glued together. As a result, memory usage by an application can grow unexpectedly. That’s why it is important to keep memory usage under control from the moment you start building it. In this post, we will cover four tools in Google Chrome that can help you understand how your application makes use of JavaScript memory.The simplest one is the built-in Task Manager. It is available under > Tools > Task Manager. The “JavaScript memory” column isn't visible by default, but you can turn it on via the context menu [1]:

The numbers are updated in the real time.

If you’d like to visualise memory usage over time, try the Memory Graph of Chrome Developer Tools’ Timeline panel. To start using it, open Developer Tools, switch to the Timeline panel, and click on the “Memory” item. After you start capturing Timeline events, the graph starts updating itself:

The most functional tool in controlling JavaScript memory usage and finding leaks is the new powerful Heap Profiler available in Chrome Dev Channel. To get a heap snapshot, open the Profiles panel in Developer Tools and press the “Take heap snapshot” button:

Snapshots contain every object from the JavaScript heap, so you can explore them in detail and find out how much memory every object of your application consumes. The heap profiler also offers the following features:

snapshots diffing

grouping objects by constructor

calculating retained sizes of objects

showing dominators tree

revealing paths to GC roots or window objects

In addition, the heap profiler takes into account native DOM nodes, and allows you to uncover DOM-related memory leaks.

It is also possible to measure how much JavaScript memory is currently used from within the page itself. You can sample values from the performance.memory window property at different points of your application lifetime. Please note, that the property does not report anything, unless you run Chrome with --enable-memory-info command-line argument.

For a more complete reference on working with the Chrome Developer Tools heap profiler, check out the tutorial.

Since we announcedWebP, a new image format based on WebM technology and the VP8 codec, we’ve been working hard with the open web community to improve and enhance it. Today we are happy to share news about a few new features and expanded support for WebP.

New Features

WebP's compression algorithms have been significantly improved while remaining completely

compatible with the previous releases. We hope the quality of a few sample images in the new gallery will delight you.

On the decoding side, we have integrated a fancy upsampler. Fancy upsampling reduces the pixelation of strong edges. You can see this feature when you zoom in, for example on a WebP image with red edges converted from this PNG original:

Original image in PNG format

Without fancy upsampling: strong stair-like pattern

With fancy upsampling: smoother edge

We also introduced the ability to incrementally decode the data as your computer downloads it from the web, a feature that allows the browser to display images without having to wait for the whole file to download. This feature is already enabled in Chrome 12.

On the encoding side, to further improve quality, we focused on segmenting the picture into areas with similar compressibility. For each of these segments, we tune the amount of compression and filtering differently, and bits are redistributed where they are most useful. Take for instance the image reproduced below [1]:

The easy segment contains lot of disparate signals and can be compressed more than the difficult one, which will be assigned more bits. In this example, the encoder only used two segments. By using even more segments (up to four), WebP is now able to retain many of the original details of the image [2]. This is in contrast to the frequent ringing artifacts one can clearly see in JPEG images.

The uneven distribution of bits between difficult and easy area is controlled in the new encoder using the -sns parameter, short for Spatial Noise Shaping. Its value can be set from 0 to 100 (0 meaning OFF) and with a default of 80. Note that when you enable SNS, PSNR may be degraded, but the overall visual quality is much improved.

We’ve added simple encoding and decoding example binaries to the libwebp library. In addition, we’ve added JNI support that allows Java programs to decode WebP images. Next up is transparency, also known as Alpha channel; we’re experimenting with it now and planning to add it to the next stable version of the codec. In parallel, we continue to improve the codec’s speed and will release a complete specification for the metadata format.

Increased adoption

WebP is now natively supported in Chrome and Opera. Google products including Gmail and Picasa Web Albums, have also added support to WebP so you can share, send and receive WebP images. WebP support is coming to AppEngine. In addition, Google Instant Previews now store images in WebP to reduce their storage needs.

The new features, quality improvements and increased adoption of WebP get us excited about its future. As always, we’re looking for more feedback as well as code contributions from the community. Let us know on the mailing list how your experiments are panning out and what new features you’d like to see in the future.

Image credits:

[1]: "Kayaker at Ekstremsportveko 2010, Voss". Image Author: Kjetil Birkeland Moe. Reproduced with permission of the author. PNG source, and Blog post by author with comparison of JPEG and WebP.