Many Chrome extensions use browser actions as a notification area. Notifications can be very valuable to users, but there’s only so much a developer can do with an icon’s worth of pixels.

As it turns out, web sites have a great way to deliver non-modal message like these with the notifications API, which was first introduced in Chrome 4 for Windows.

As part of the Developer Relations team at Google, we get the chance to run lots of different types of events. Some of the most rewarding are hackathons that involve writing Google Chrome Extensions. We always love watching developers create useful features for Google Chrome in just a few hours.

Recently, our friends at Twilio ran their own online Google Chrome Extensions hackathon. The winners, Brad Berkin and Timothee Boucher, used the Twilio API to integrate the Twilio and extensions platforms, adding cool new functionality to Google Chrome.

Brad’s Chro-wilio extension tells you how many notifications, calls, and messages you’ve received in your Twilio account in the last day, week, or month. Timothee’s Notwilfications extension lets you know when a call is routed to your account. You can check who’s calling and either ignore the call or send it to voicemail without ever having to pick up your phone. When voicemail messages are recorded, a toolbar badge will show you the number of messages you have and let you play them right in the browser.

We’d like to thank all the developers who participated in this contest, as well as the Twilio team for organizing it. You can find more info about the contest on Twilio’s blog.

For those of you who missed this opportunity and are based in New York, we’re planning an extensions hackathon in our local office on June 10th. If you’re interested in attending, all you need to do is fill out this form before June 6th. Space is limited, but we’ll try to accommodate everyone who signs up. We hope to see you there!

Posted by Brian Kennish and Arne Roomann-Kurrik, Developer Advocates

With the latest release of Google Chrome, Chrome is the first browser to include support for a new HTML5 feature that lets web developers reduce the privileges of parts of their web pages by including a "sandbox" attribute in iframes:

<iframe sandbox src="http://attacker.com/untrusted.html"></iframe>

When displaying untrusted.html in a sandboxed iframe, the browser renders untrusted.html with reduced privileges (e.g., disabling JavaScript and popups), similar in spirit to how Google Chrome sandboxes its rendering engine.

Whitelisting

You can give untrusted.html some of its privileges back by whitelisting the privileges in the value of the sandbox attribute. For example, if you wanted untrusted.html to be able to run scripts and contain forms, you could use the following markup:

<iframe sandbox="allow-scripts allow-forms" src="http://attacker.com/untrusted.html"></iframe>

Because @sandbox is a white list, the browser still imposes the remainder of the sandbox restrictions on untrusted.html. For example, untrusted.html does not have the privilege to create popup windows or instantiate plug-ins. The full list of supported directives is listed in the HTML5 specification.

Legacy browsers

When using the sandbox attribute, you need to think carefully about how legacy browsers (which do not support @sandbox) will interpret your HTML. The easiest way to use @sandbox is for "defense-in-depth." Instead of relying upon @sandbox as your only line of defense, you can use it as an additional security mitigation in case your first line of defense (such as output encoding) fails. Because legacy browsers ignore attributes they do not understand, you can add @sandbox to existing iframes and improve security for users of newer browsers.

If you want to display untrusted content only in browsers that support @sandbox, you can detect whether the browser supports @sandbox using the follow code:


Posted by Adam Barth, Software Engineer

Since the initial beta release of Google Chrome for Linux last December, we've been hard at work adding the polish necessary to upgrade the browser to our stable channel.

With continued improvements in plugin support, extensions functionality, and desktop integration, as well as new features such as desktop notifications and bookmark sync, we believe this release of Google Chrome for Linux to be a solid, high-performance, fully-featured, all-purpose browser. From the early porting days of layout test fixing, deep and hairy posix and raw X11 code, to designing a truly native UI and building a host of new and polished features, we’re thrilled to work with the larger community to deliver a fast, stable, secure, and sophisticated browser.

Going forward, we are committed to continuing to deliver all the security, performance, and features (old and new) of Google Chrome for Windows, while integrating as seamlessly as possible with the Linux desktop ecosystem on a variety of popular Linux distributions.

Posted by Evan Stade and Elliot Glaysher, Software Engineers

A developer preview of WebM, a high-quality, open, freely implementable, and web-optimized video format was announced today. Initial support for WebM, including its video codec VP8 will be checked into Chromium later tonight. You can try it by building Chromium yourself or watch for it in the dev channel build in the coming weeks.

Posted by Jim Bankoski, Engineering Manager and Frank Galligan, Tech Lead

We believe it should be easier for users to discover web apps and for developers to reach a large audience. That’s why today at Google I/O, we announced the Chrome Web Store, an open marketplace for web apps.

Google Chrome users who find web apps in the store will be able to create convenient shortcuts in Chrome for easy access. Also, developers will have the option to easily sell their apps through the store using a convenient and secure payment system.

To give you a preview of what it means to prepare a web app for the store, we've published some preliminary documentation. We look forward to your feedback and sharing our progress with you openly as many of the technical details will likely change before we launch. To stay up-to-date, subscribe to our developer group and look for news on the Chromium blog.

The Chrome Web Store will be available to users later this year. We plan to share more technical details soon. In the meantime, visit chrome.google.com/webstore for more information.



Posted by Erik Kay, Lead Software Engineer

Today, we’re happy to make available a developer preview of the Native Client SDK – an important first step in making Native Client more accessible as a tool for developing real web applications.

When we released the research version of Native Client a year ago, we offered a snapshot of our source tree that developers could download and tinker with, but the download was big and cumbersome to use. The Native Client SDK preview, in contrast, includes just the basics you need to get started writing an app in minutes: a GCC-based compiler for creating x86-32 or x86-64 binaries from C or C++ source code, ports of popular open source projects like zlib, Lua, and libjpeg, and a few samples that will help you get you started developing with the NPAPI Pepper Extensions. Taken together, the SDK lets you write C/C++ code that works seamlessly in Chromium and gives you access to powerful APIs to build your web app.



To get started with the SDK preview, grab a copy of the download at code.google.com/p/nativeclient-sdk. You’ll also need a recent build of Chromium started with the --enable-nacl command-line flag to test the samples and your apps. Because the SDK relies on NPAPI Pepper extensions that are currently only available in Chromium, the SDK won’t work with the Native Client browser plug-ins.

We’ll be updating the SDK rapidly in the next few months, so download a copy, develop some cool apps, share them with the community and send us your feedback! If you build useful libraries in the process, please also consider submitting a patch to the SDK packages directory – chances are, what’s been useful to you will be useful to others. Finally, if you’re attending Google I/O, come to our Beyond JavaScript session, or meet the team at the Developer Sandbox.

Posted by David Springer, Senior Software Engineer

We launched the O3D API about a year ago to start a discussion within the web community about establishing a new standard for 3D graphics on the web. Since then, we’ve also helped develop WebGL, a 3D graphics API based on OpenGL ES 2.0 that has gradually emerged as a standard, and is supported by other browser and hardware vendors like Mozilla, Apple and Opera.

At Google, we’re deeply committed to implementing and advancing standards, so as of today, the O3D project is changing direction, evolving from its current plug-in implementation into a JavaScript library that runs on top of WebGL. Users and developers will still be able to download the O3D plug-in and source code for at least one year, but other than a maintenance release, we plan to stop developing O3D as a plug-in and focus on improving WebGL and O3D as a JavaScript library.

We did not take this decision lightly. In initial discussions we had about WebGL, we were concerned that JavaScript would be too slow to drive a low-level API like OpenGL and we were convinced that a higher level approach like the O3D scene graph would yield better results. We were also cognizant of the lack of installed OpenGL drivers on many Windows machines, and that this could hamper WebGL’s adoption.

Since then, JavaScript has become a lot faster. We've been very impressed by the demos that developers have created with WebGL, and with the ANGLE project, we believe that Chromium will be able to run WebGL content on Windows computers without having to rely on installed OpenGL drivers.

The JavaScript implementation of O3D is still in its infancy, but you can find a copy of it on the O3D project site and see it running some of the O3D samples from a WebGL enabled browser (alas, no Beach Demo yet). Because browsers lack some requisite functionality like compressed asset loading, not all the features of O3D can be implemented purely in JavaScript. We plan to work to give the browser this functionality, and all capabilities necessary for delivering high-quality 3D content.

We’d like to thank the developers who have contributed to O3D by delivering valuable feedback, submitting changes to the plugin and developing applications. To help you convert your application to the new WebGL implementation of O3D, we will keep our discussion group open where our engineering team will answer your questions and provide you with technical advice. For those of you concerned about support for Internet Explorer, we’ll recommend using Google Chrome Frame once it supports WebGL, and hope to see IE implement WebGL natively someday. We hope you will continue working with us and the rest of the WebGL community on moving 3D on the web forward.


Posted by Matt Papakipos, Engineering Director, and Vangelis Kokkevis, Software Engineer

The Google Chrome Developer Relations team has been working hard to spread the word about Google Chrome’s extensions platform and support for HTML5. Besides speaking at developer events around Silicon Valley, we’ve made it a priority to connect with developers in other locations in and out of the United States.

Following our trips last year to the Czech Republic, Russia, and Argentina, we spent a good chunk of the past few months on the road meeting with hundreds of developers and Google Technology User Groups.



For starters, Brian Kennish spoke about advanced extensions at Google DevFest in Tokyo, Japan and Google’s South by Southwest Interactive booth in Austin, Texas. You can check out a video of Brian’s DevFest session.

Next, Ernest Delgado, Jeremy Orlow, and Arne Roomann-Kurrik presented extensions and HTML5 to developers in London, England. Both presentations were actually implemented using HTML5 — the extensions deck as an extension and the HTML5 deck as a webpage.

Ernest and Arne went on to deliver this content to developers in Spain, Germany, and the Czech Republic. Here’s a video of the talk they gave to the Brno, Czech Republic Google User Group.



We love to help developers get their “hands dirty” with code too, so the team organized several hackathons during these trips. Brian led a hackathon in Sydney, Australia and another in Austin, where developers built lots of great extensions. Meanwhile, Ernest and Arne led students through building extensions at universities in Madrid and Brno.

We’re keen to continue connecting with developer communities around the world. If we haven’t visited a location near you yet, we hope the resources above come in handy. And for those of you who want the thrill of a hackathon experience, our friends at Twilio recently launched an online extensions hackathon with awesome prizes. We look forward to trying out what you create.

Keep an eye on this blog for future announcements and event plans. We won’t be traveling for the next couple weeks as we prepare new content for Google I/O, but perhaps some of you will be making trips of your own to see us there!


Posted by Arne Roomann-Kurrik and Brian Kennish, Developer Advocates

Since our launch last December, all of us on the Google Chrome Extensions team have been excited to see a steady stream of new developers trying out our platform. Besides reading our documentation, Twitter account and our blog posts, a great way for an interested developer to get up to speed has been to participate in the extensions community. For example, in our discussion group, experienced developers often provide advice and answer questions for those working on their first extensions.

We wanted to take this community knowledge sharing process a step further. We reached out to our friends at Aviary, Zemanta, Web of Trust and Glue and had them discuss their experiences with Chrome extensions on camera. In the videos below, you’ll learn some of the innovative approaches developers from these companies used to create their extensions. You’ll also hear about the technical challenges they faced, the techniques they used to make their extensions more popular, and some of their upcoming plans:



We’re sure that these short videos did not answer all the questions you have, so if you’re attending the Google I/O conference on May 19th, make sure to stop by the sandbox area and meet the Zemanta, Aviary, Web of Trust and Glue teams in person. They’ll be happy to share the benefit of their experiences with anyone looking to write a Google Chrome extension. If you can’t attend, make sure to get involved with the community and we’ll get you on your way to making an excellent Google Chrome extension.


Posted by Arne Roomann-Kurrik, Developer Advocate and Christos Apartoglou, Product Marketing Manager