In the two years since we announced SPDY, we’ve been working with the web community on evolving the spec and getting SPDY deployed on the Web.

Chrome, Android Honeycomb devices, and Google's servers have been speaking SPDY for some time, bringing important benefits to users. For example, thanks to SPDY, a significant percentage of Chrome users saw a decrease in search latency when we launched SSL-search. Given that Google search results are some of the most highly optimized pages on the internet, this was a surprising and welcome result.

We’ve also seen widespread community uptake and participation. Recently, Firefox has added SPDY support, which means that soon half of the browsers in use will support SPDY. On the server front, nginx has announced plans to implement SPDY, and we're actively working on a full featured mod-spdy for Apache. In addition, Strangeloop, Amazon, and Cotendo have all announced that they’ve been using SPDY.

Given SPDY's rapid adoption rate, we’re working hard on acceptance tests to help validate new implementations. Our best practices document can also help website operators make their sites as speedy as possible.

With the help of Mozilla and other contributors, we’re pushing hard to finalize and implement SPDY draft-3 in early 2012, as standardization discussions for SPDY will start at the next meeting of the IETF.

We look forward to working even closer with the community to improve SPDY and make the Web faster!

To learn more about SPDY, see the link to a Tech Talk here, with slides here.

Posted by Roberto Peon and Will Chan, Software Engineers

One of my favorite features of Chrome got a boost earlier today, as we announced support for an experimental new “autocomplete type” attribute for form fields. The new attribute will allow web developers to unambiguously label text and select fields with common data types such as ‘full-name’ or ‘street-address’ and guarantee that their site’s forms work correctly with Chrome Autofill and other form-filling providers.

We’ve been working on this design in collaboration with several other autofill vendors. Like any early stage proposal we expect this will change and evolve as the web standards community provides feedback, but we believe this will serve as a good starting point for the discussion on how to best support autofillable forms in the HTML5 spec. For now, this new attribute is implemented in Chrome as x-autocompletetype to indicate that this is still experimental and not yet a standard, similar to the webkitspeech attribute we released last summer.

For more information, you can read the full text of the proposed specification, ask questions on the Webmaster help forum, or you can share your feedback in the standardization discussion!


Posted by Ilya Sherman, Software Engineer

Since we open sourced WebRTC this past summer, we’ve been working hard with browser vendors to integrate WebRTC technology in their products. Today, we reached an important milestone: WebRTC is now integrated in the Chrome browser available on the dev channel.

Building industry-leading voice and video capabilities into the browser makes it easier for web developers to incorporate real time communications in their apps. Instead of relying on custom, OS specific, proprietary plug-ins, they can now easily build and maintain their apps using a few simple JavaScript APIs and have the browser do the heavy lifting.

Even though WebRTC is still evolving, we are receiving feedback from the standards process in W3C and IETF and there are already plenty of apps in development. For example, companies like Polycom, Vonage, Vehix.com, Firespotter, Siemens, Nimbuzz and PCCW are currently actively developing browser based solutions using WebRTC. If you are interested to learn more on how you can use WebRTC in your app, review our documentation, join our developer discussion group and go to the WebRTC blog for more details. We are looking forward to seeing what you come up with!


Posted by Niklas Enbom, Software Engineer

When we first set out to design Chrome, we knew we had a unique opportunity to improve the security of the web. In addition to speed and simplicity, we’ve been adamant that security be a central tenet of everything we build. Chrome and the web have since come a long way, and we’ve been challenged to protect a complex and rapidly changing browser against the many threats that emerge on the web.

After spending tens-of-thousands of hours working on ways to make users safer on the web, we thought it might be worth sharing the Chrome security principles that guide the work that we do.

There are lots of technical details, but the fundamentals have always been simple. Security should compliment your browsing experience, not detract from it, and your browser should be secure by default -- no configuration required. No defense is ever perfect, so we rely on multiple layers of protection to help guard against single points of weakness. We support and fund the security research community in their work to identify weaknesses, and when vulnerabilities are found, we pride ourselves on patching them faster than any other browser.

These principles have served us well in protecting users while keeping Chrome super fast and easy to use. If you develop software, we hope you find them helpful in securing your own product, and if you’re a Chrome user, that they give some insight into the many ways we work to help you surf with confidence.

Posted by Justin Schuh and Travis McCoy, Chrome Security Team

(Cross-posted on the Official Google Code and Commerce Blogs)

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.

Developers using In-App Payments are seeing strong conversions and revenue streams thanks to these key features:

• 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.

Posted by Pali Bhat, Product Manager, Google Commerce Team

Updated on December 14th with the video of the event.

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 OSs
In 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 work
If 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 languages
The 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.

Posted by Christian Stefansen, Product Manager

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.

Posted by Vangelis Kokkevis, Software Engineer