Friday, May 28, 2010

[Gd] Board Nominations Close Tuesday, June 1!

| More

OpenSocial API Blog: Board Nominations Close Tuesday, June 1!


Just a quick reminder for everyone.

Nominations for the OpenSocial Board of Directors community seats are underway and will close on Tuesday, June 1, 2010. Please use the on-line form to nominate someone.

We are looking forward to working with the community and to another great year for OpenSocial.

Posted on behalf of the OpenSocial Foundation by Mark Weitzel

[Gd] Desktop Notifications: Now available to extensions in Chrome

| More

Chromium Blog: Desktop Notifications: Now available to extensions in Chrome

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.

The Gmail Notifier extension was an early adopter of notifications.

As of Chrome 5, we’re happy to announce that notifications are also available to extension developers.

When notifications are used from an extension, there are no permission prompts or infobar warnings. The experience is seamless - it just works.

To learn how to use the notifications API in your extension, review our documentation. We’ll be on the lookout for some great examples of desktop notifications to feature on the Chrome Extensions Gallery, so get cracking!

Posted by Aaron Boodman, Software Engineer

Thursday, May 27, 2010

[Gd] Interact with your Google Docs List from Apps Script

| More

Google Apps Developer Blog: Interact with your Google Docs List from Apps Script

We recently added a new feature to Apps Script: the ability to interact with your Google Docs List. With this new integration, scripts can create, rename, or move files and folders in your Google Docs. In addition, scripts can now create, modify, and clear plain-text files and search through your documents for a specified query string.

For instance, take a company whose website is hosted on Google Sites. They have a Specials page where they want to list seasonal sales depending on upcoming holidays. They store the details about the seasonal sales in plain-text files that are saved in their Google Docs List. By using the Google Docs List and and Sites services within Apps Script along with time-based triggers to run the script once per day, they can keep their Specials page updated automatically. Here’s a code snippet that demonstrates how to update the Specials page:

//The Mother’s Day sale runs from May 1 - May 7, 2011
var MOTHERS_DAY_START = new Date("May 1, 2011");
var MOTHERS_DAY_END = new Date("May 7, 2011");
//The Valentine’s Day sale runs from Feb 6 - Feb 13, 2011
var VALENTINES_DAY_START = new Date("February 6, 2011");
var VALENTINES_DAY_END = new Date("February 13, 2011");

function updateSpecials() {
var today = new Date();
var site = SitesApp.getSite("", "giftshop");
// Get all the web pages in the Site
var pages = site.getWebPages();
// Loop through the web pages to find the specials page
for (var i = 0; i < pages.length; i++) {
if (pages[i].getPageName() == "specials") {
var page = pages[i];
// Set up the default wording for the specials page
var pageText = "There are no specials at this time.";

// If today’s date is within the Mother’s Day sale range
if (today >= MOTHERS_DAY_START && today <= MOTHERS_DAY_END) {
// Find the sale text that’s stored in the file mom.txt
pageText = DocsList.find("mom.txt")[0].getContentAsString();
// If today’s date is within the Valentine’s Day sale range
else if (today >= VALENTINES_START && today <= VALENTINES_END ) {
// Find the sale text that’s stored in the file valentines.txt
var pageText = DocsList.find("valentines.txt")[0].getContentAsString()
// Set the content of the specials page

If this script is then set up to run using a trigger that calls it at the same time each day, then the Specials page will be kept automatically up-to-date.

To help you learn more, we've created a tutorial that demonstrates how to search and display information about files, create files, and read content from files.

Note that certain features of the DocsList service, such as creating files, are only available to Google Apps accounts. For complete information on interacting with your Google Docs List using Apps Script, see the DocsList Service documentation.

We look forward to seeing how you use this integration. If you'd like to learn more about Apps Script and meet the Apps Script team in person, join us at the upcoming Apps Script hackathon in New York City on June 24.

Posted by Jan Kleinert, Google Developer Relations

[Gd] An update on Google Chrome Extensions Hackathons

| More

Chromium Blog: An update on Google Chrome Extensions Hackathons

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 Chrome Extensions hackathon. The winners, Brad Berkin and Timothee Boucher, used the Twilio API to integrate the Twilio and Chrome 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 a Chrome 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

[Gd] Android Cloud To Device Messaging

| More

Android Developers Blog: Android Cloud To Device Messaging

[This post is by Wei Huang, who helped implement this feature. — Tim Bray]

In the just-launched Android 2.2, we’ve added a new service to help developers send data from servers to their applications on Android phones. Android Cloud to Device Messaging (C2DM) makes it easier for mobile applications to sync data with servers.

Most of the useful applications on your mobile phone use the Internet to keep users connected. Traditionally, many apps use polling to fetch data periodically. POP mail clients, for example, connect to the server every 15 minutes or so. Polling is fairly easy to implement, and works well in many situations. It’s tricky, though, to select the frequency: Poll too often, you may not see any new data, and create unnecessary stress on the server and network. Poll too rarely and the data on the device may become stale. Polling is especially problematic on mobile devices, because it consumes precious network bandwidth and battery life.

Having the server push messages to the client asynchronously may be a superior choice for getting the latest data to your applications, resulting in fresher data and more efficient use of the network and your battery. However, it’s also tricky to implement a good push solution, and it isn’t free as there is some overhead in maintaining the required connection. On a mobile device like an Android phone, implementing applications to receive these messages is tricky; you have to worry about patchy network coverage and zombie connections created when the wireless carrier’s routers time out connections that are idle for too long.

Many of the Google applications on Android already use push to keep their data fresh, for example Gmail, Contacts, and Calendar. Starting with Android 2.2, C2DM allows third-party developers to use the same service the Google apps do.

Here are a few basic things to know about C2DM:

  • It requires Android 2.2; C2DM uses Google services which are present on any device running the Android Market.

  • It uses existing connections for Google services. This requires the users to sign into their Google account on Android.

  • It allows 3rd party servers to send lightweight data messages to their apps. The C2DM service is not designed for pushing a lot of user content; rather it should be used like a “tickle”, to tell the app that there is new data on the server, so the app can fetch it.

  • An application doesn’t need to be running to receive data messages. The system will wake up the app via an Intent broadcast when the the data message arrives, so long as the app is set up with the proper Intent Receiver and permissions.

  • No user interface is required for receiving the data messages. The app can post a notification (or display other UI) if it desires.

It’s easy to use the C2DM API. Here is how it works:

  • To enable C2DM, an application on the device registers with Google and get a registration ID, and sends the ID to its server.

  • When the server needs to push a message to the app on the device, it posts the message via HTTP to Google’s C2DM servers.

  • The C2DM servers route the message to the device, and an Intent broadcast is sent to the app.

  • The app is woken up to process the message in its Intent Receiver.

  • The app can unregister with C2DM when the user no longer wants messages to be pushed to it.

That’s about it! All you need is a server that knows to talk HTTP, and an Android app that knows how to use the Intent APIs. Below are some code samples:

// Use the Intent API to get a registration ID
// Registration ID is compartmentalized per app/device
Intent regIntent = new Intent(
// Identify your app
PendingIntent.getBroadcast(this /* your activity */,
0, new Intent(), 0);
// Identify role account server will use to send
regIntent.putExtra("sender", emailOfSender);
// Start the registration process

The registration ID will be delivered back to your app via an intent broadcast with the Intent Action Here is a code sample to receive the registration ID.

// Registration ID received via an Intent
public void onReceive(Context context, Intent intent) {
String action = intent.getAction();
if (“”.equals(action)) {
handleRegistration(context, intent);

public void handleRegistration(Context context, Intent intent) {
String id = intent.getExtra(“registration_id”);
if ((intent.getExtra(“error”) != null) {
// Registration failed. Try again later, with backoff.
} else if (id != null) {
// Send the registration ID to the app’s server.
// Be sure to do this in a separate thread.

On the server side, your server needs to get a ClientLogin Auth token in order to talk to the C2DM servers. When it wants to push a message to the device, it can send an authenticated http POST with:

  • Authorization: GoogleLogin auth=<auth token>

  • URL encoded parameters including the registration id, the data key/value pairs, a “collapse key” used for overriding old messages with the same key on the Google C2DM servers, and a few other optional params.

When you use the C2DM service, you no longer need to worry about dealing with flaky mobile data connections, or when the user isn’t connected to the internet (i.e. Airplane mode). C2DM keeps the messages in the server store, and delivers them when the device comes back online. Basically, you can leave all the hard work of designing a robust push service to Google. Your application can take advantage of push infrastructure we’ve already built and tested, and stay more connected to the internet. Best of all, you won’t ruin the users’ battery life.

Information about how to build C2DM enabled applications on Android is online at the code lab, and more will be coming as we approach general release.


[Gd] Security in Depth: HTML5’s @sandbox

| More

Chromium Blog: Security in Depth: HTML5’s @sandbox

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=””></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.


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=””></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:

if (”sandbox” in document.createElement(”iframe”)) {
// This browser supports @sandbox. We can sandbox untrusted
content with confidence.

Posted by Adam Barth, Software Engineer

[Gd] Chrome Extensions for Web Development

| More

Google Code Blog: Chrome Extensions for Web Development

The Chrome Developer Tools are great for debugging HTML, JavaScript and CSS in Chrome. If you're writing a webpage or even a web app for the Chrome Web Store, you can inspect elements in the DOM, debug live JavaScript, and edit CSS styles directly in the current page. Extensions can make Google Chrome an even better web development environment by providing additional features that you can easily access in your browser. To help developers like you, we created a page that features extensions for web development. We hope you’ll find them useful in creating applications and sites for the web.

For example, Speed Tracer is an extension to help you identify and fix performance issues in your web applications. With Speed Tracer, you can get a better idea of where time is being spent in your application and troubleshoot problems in JavaScript parsing and execution, CSS style, and more.

Another useful extension is the Resolution Test that changes the size of the browser window, so web developers can preview websites in different screen resolutions. It also includes a list of commonly used resolutions, as well as a custom option to input your own resolution.

With the Web Developer extension, you can access additional developer tools such as validation options, page resizing and a CSS elements viewer; all from an additional button in the toolbar.

Another extension you should check out is the Chrome Editor that allows you to easily code within your browser, so you don’t have to flip between your browser and code editor. You can also save a code reference locally to your computer for later use.

These are just a few of the extensions you can find in our extensions for web development page. You can also look for more in the extensions gallery.

By Koh Kim, Google Chrome Team

[Gd] Chrome Extensions for web development

| More

Official Google Webmaster Central Blog: Chrome Extensions for web development

Webmaster Level: All

The Chrome Developer Tools are great for debugging HTML, JavaScript and CSS in Chrome. If you're writing a webpage or even a web app for the Chrome Web Store, you can inspect elements in the DOM, debug live JavaScript, and edit CSS styles directly in the current page. Extensions can make Google Chrome an even better web development environment by providing additional features that you can easily access in your browser. To help developers like you, we created a page that features extensions for web development. We hope you’ll find them useful in creating applications and sites for the web.

For example, Speed Tracer is an extension to help you identify and fix performance issues in your web applications. With Speed Tracer, you can get a better idea of where time is being spent in your application and troubleshoot problems in JavaScript parsing and execution, CSS style, and more.

Another useful extension is the Resolution Test that changes the size of the browser window, so web developers can preview websites in different screen resolutions. It also includes a list of commonly used resolutions, as well as a custom option to input your own resolution.

With the Web Developer extension, you can access additional developer tools such as validation options, page resizing and a CSS elements viewer; all from an additional button in the toolbar.

Another extension you should check out is the Chrome Editor that allows you to easily code within your browser, so you don’t have to flip between your browser and code editor. You can also save a code reference locally to your computer for later use.

These are just a few of the extensions you can find in our extensions for web development page. You can also look for more in the extensions gallery.

Written by Koh Kim, Google Chrome Team

Wednesday, May 26, 2010

[Gd] HTML5 in Gadgets on iGoogle

| More

iGoogle Developer Blog: HTML5 in Gadgets on iGoogle

Did you know gadgets can use html5? The key is in the doctype. Normally the doctype of a gadget isn't mentioned. Specify the html5 doctype in the gadget and it will be used when the gadget is rendered. Let's look at a quick example using the popular canvas drawing API:

<?xml version="1.0" encoding="UTF-8" ?>
 <ModulePrefs title="html5 canvas">
 <Content type="html" view="home,canvas">
   <!DOCTYPE html>
    var demo = {
     init: function() {
      var drawcan = document.getElementById('drawarea');
      if (drawcan.getContext){
       var context = drawcan.getContext('2d');
       var xmax = drawcan.width;
       var ymax = drawcan.height;
       for (var dotix = 0; dotix < 100; ++dotix) {
        var x = Math.random() * xmax;var y = Math.random() * ymax;
        context.strokeStyle = "#888888";
        var blueness = Math.floor(Math.random() * 256);
        context.fillStyle = "rgb(10,90,"+ blueness +")";
   <canvas id="drawarea" width="150" height="150"></canvas>

The top of the gadget still has the usual XML prolog because the gadget spec is, as always, an XML document. The html, in this case html5, is inside a CDATA block. The CDATA block means the structure of the html5 content is pretty much ignored when parsing the XML. iGoogle doesn't do anything extra for compatibility with html5; features specific to html5 will still only work in browsers that support them. Gadgets have the same cross-browser compatibility concerns as any other web page. Have a look at the When can I use guide for an idea of compatibility of features across browsers.

The content of this gadget is pretty straightforward. It includes a canvas element. In the init method it tries to get a drawing context. If it's successful (meaning the browsers supports html5 canvas) it will draw a rectangle around the extents of the element then draw 10 randomly placed dots inside. Use this gadget as a starting point to get your own html5 gadget running.

And yes, this gadget has a canvas in your canvas so you can render when you render.

Posted by Rob Russell, Developer Relations Team

Tuesday, May 25, 2010

[Gd] Introducing AdWords API version v201003 beta

| More

AdWords API Blog: Introducing AdWords API version v201003 beta

Today we’re releasing a new version of the AdWords API: v201003 beta. This version contains many requested features, including: a ReportService beta, Ad Sitelinks, and bid simulator. We know many of you just migrated to v200909, so don’t worry, your v200909 code will continue to work normally – v200909 remains the latest out-of-beta release and is fully supported by our team.

Here’s the full list of what’s new in version v201003 beta:
  • ReportService beta: generate reports about the performance of your AdWords campaigns
  • Bid simulator: see estimated clicks, cost and impressions corresponding to various Max. CPC bids
  • Ad Sitelinks extensions: include up to four additional links in your ads to deeper content on your site
  • Phone extensions: add a phone number to your text ads that appear on mobile devices with full Internet browsers such as iPhone and Android ads
  • Sync for location extensions: synchronize your AdWords location extensions with Google Places (formerly Local Business Center) listings
  • MediaService: upload images and icons for location extensions
  • Position preference: specify in what position range you’d like your ads to appear
  • Target CPA: bid based on the average amount you’d like pay for a conversion
  • Carrier and device targeting: target ads to specific mobile carriers and devices
  • Category targeting: show placement targeted ads on a set of placements with the same theme
  • 1-per-click and many-per-click conversions: get both types of conversion metrics
  • A minimum size for bulk mutate jobs
ReportService is available in beta within v201003, however, TrafficEstimatorService and AccountService are only available within v13. We’ll announce on this blog when all three of these services are fully available within the new AdWords API. You’ll have four months from the date of that announcement to migrate your applications to the new services. You don’t need to migrate to the new ReportService beta at this time, but we encourage you to try it out.

The new AdWords API architecture makes it easier for us to enable new features available in AdWords, so look out for more updates like this one in the coming months. As always, please continue to post your questions and feedback to the developer forum.

–Jason Shafton, Product Marketing Manager

[Gd] Dalvik JIT

| More

Android Developers Blog: Dalvik JIT

[This post is by Dan Bornstein, virtual-machine wrangler. — Tim Bray]

As the tech lead for the Dalvik team within the Android project, I spend my time working on the virtual machine (VM) and core class libraries that sit beneath the Android application framework. This layer is mostly invisible to end users, but done right, it helps make Android devices run smoothly and improves developer productivity.

The 2.2 release is particularly pleasing to me, as it is the first release since before 1.0 in which we have been able to deliver significantly new VM technology. And unlike much of what my team and I do, it is something that can be experienced directly by end users.

“Dalvik” isn’t exactly a household word (at least in my country), and most people wouldn’t know a virtual machine if it hit them in the face, but when you tell them you were able to make their existing device work better — run faster, use less battery — they will actually take notice!

What Makes This Possible?

We added a Just In Time (JIT) compiler to the Dalvik VM. The JIT is a software component which takes application code, analyzes it, and actively translates it into a form that runs faster, doing so while the application continues to run. If you want to learn more about the design of the Dalvik JIT, please watch the excellent talk from Google I/O 2010 given by my colleagues Bill Buzbee and Ben Cheng, which should be posted to YouTube very soon.

To be clear, the differences aren’t always dramatic, nor do they apply uniformly to all applications. Code that is written to run the CPU all-out can now do more in the same amount of time (running faster), and code that is written to be rate-limited can get its work done using less time and less of the CPU (using less battery). On the performance front in particular, we have seen realistic improvements of 2x to 5x for CPU-bound code, compared to the previous version of the Dalvik VM. This is equivalent to about 4x to 10x faster than a more traditional interpreter implementation.

The team is proud of our new JIT in general, but we are especially proud of two aspects of it:

Many previous JIT implementations react slowly, delivering performance improvements only after a long warm up period. In the extreme, it can be minutes or even hours before the code is fully up to speed. On the other hand, the Dalvik JIT reacts quickly, so that mere moments after you hit the “Start” button on your favorite game, you are already benefiting from the work of the JIT.

We are also very pleased with how little memory the JIT uses. The code for the JIT itself is well under 100k, and each process that the JIT runs in will typically only use another 100k or so of RAM. On the current generation of Android phones, device users won’t even notice this additional memory usage; on my own phone, I can still have literally dozens of applications warmed up in memory and ready to go.

The Dalvik team isn’t resting on its laurels, either. We are hoping to see the Dalvik JIT deployed on many devices in the coming months. Looking forward, the team has an endless list of ideas for making the VM and library code better, which we are diligently working on.


[Gd] Announcing the orkut Java Client Library

| More

Google Code Blog: Announcing the orkut Java Client Library

Today, we’re pleased to announce our new orkut Java client library!

If you’ve ever wanted to write desktop or mobile apps for orkut, this open source Java library provides you with that opportunity. Using three-legged OAuth, you can get friends’ profile data, post and retrieve status and activity updates, read and write scraps, create and retrieve photo albums, and upload pictures. To get started, simply download the library, check out the included samples, and start coding.

With this library, it’s easy to have an application up and running with just a few lines of code. The snippet below shows how to create a photo album, share it with your friends, and upload photos:

CreateAlbumTx createAlbum = albumsFactory.createAlbum(
"College Days", "The best days of my life!");
Album album = createAlbum.getAlbum();

byte[] photo = captureImage();
photosFactory.uploadPhoto(album, photo, ImageType.JPG, "My Best Buddies");

And it’s just as simple to reply to scraps from friends and to make friends with new scrappers:

GetScrapsTx scraps = scrapFactory.getSelfScraps();
for(int i = 0; i < scraps.getScrapCount(); ++i) {
ScrapEntry scrap = scraps.getScrap(i);
if(myFriends.contains(scrap.getFromUserId())) {
scrapFactory.replyToScrap(scrap, "hey, thanks for remembering me!");
} else {
scrapFactory.replyToScrap(scrap, "wanna be friends? [:)]");

As you develop your application, we’d love if you’d let us know what you create. We’re excited to see how you use this library to integrate orkut with other exciting products and technologies... and in fact, we already started! Take a look at our new orkut FotoScrapr app, which we built on Google App Engine using a slick Google Web Toolkit interface. If you like what you see, feel free to browse through the FotoScrapr source code.

And finally, if you’re not a Java developer, don’t worry. We’d be thrilled to work with you to port this library to other languages. Just reach out to us on the orkut developer forum.

So dive in and start coding – we can’t wait to see what you’re going to come up with!

By Prashant Tiwari and Sachin Shenoy, orkut team

[Gd] Google Chrome for Linux goes stable

| More

Chromium Blog: Google Chrome for Linux goes stable

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

[Gd] Random Hacks of Kindness: How hackers can save the world

| More

Google Code Blog: Random Hacks of Kindness: How hackers can save the world

Sound interesting? Here's how you can become a part of it: Attend the Random Hacks of Kindness Hackathon and develop software that saves lives, alleviates suffering and helps communities to recover after natural disasters strike.

The Back Story

Photo by Todd Huffman, shared by Creative Commons license

Random Hacks of Kindness is a joint effort founded by Google, Yahoo!, Microsoft, NASA and The World Bank, dedicated to bringing software developers together to respond to challenges facing humanity in the area of natural disaster risk. We start with problem definitions created through consultations with NGOs, governments and experts in the field from around the world, then we invite hackers to a come together to organize and go to work putting their skills to use to solve those problems with software solutions that make a difference on the ground. At a RHoK hackathon, new technologies are born, existing platforms are built upon, and innovative new ideas attract attention and support. At the close of the hackathon, teams present the technologies they have developed and prizes are awarded.

The Details

The next Random Hacks of Kindness Hackathon is happening in Washington, D.C. from June 4th through 6th,, with global satellite events going on around the world in Jakarta, Sydney, Nairobi and Sao Paolo. The evening of June 4th The State Department is hosting a reception for RHoK to kick off two days of intensive hacking on June 5th and 6th at the Microsoft Offices in Chevy Chase, MD. Check out the full agenda or learn more about the global satellites right here.

Why Do This?

  • Save the world: You have the skills to make a difference. Hacks developed at the last RHoK hackathon were used on the ground in Haiti and Chile following the devastating earthquakes there in early 2010. The world needs these solutions.
  • Exposure: Got a new product, idea or technology to share with the hacker community? Put it to work at the hackathon.
  • Assistance: Extend the function and applicability of your existing products or software through global crowdsourced development.
  • Input: Get real-time feedback from Subject Matter Experts in software and disaster risk.
  • Insight: Learn about what other companies and developers are doing in the same space.

Sounds great! How do I sign up?

Sign up on our registration page. We'll see you there!
If you are interested in attending or assisting at one of the global satellite locations, please contact

By Jeff Martin, Google Crisis Response

[Gd] Stable Channel Update

| More

Google Chrome Releases: Stable Channel Update

Google Chrome 5.0.375.55 has been released to the Stable channel for Linux, Mac and Windows.

For more details about the new features in the release, over our previous stable release 4.1, please see the Official Google Chrome blog.

Security Fixes:

Please see the Chromium security page for more detail. Note that the referenced bugs may be kept private until a majority of our users are up to date with the fix.

  • [7713] Medium Canonicalize URLs closer to the Safe Browsing specification. Credit to Brett Wilson of the Chromium development community.
  • [16535] High Possible URL bar spoofing via unload event handlers. Credit to Michal Zalewski, Google Security Team.
  • [30079] Medium Memory error in Safe Browsing interaction. Credit to Google Chrome Security Team (SkyLined).
  • [39740] Medium Bypass of whitelist-mode plugin blocker. Credit to Darin Fisher of the Chromium development community.
  • [41469] Medium Memory error with drag + drop. Credit to kuzzcc.
  • [42228] High Incorrect execution of Javascript in the extension context. Credit to Andrey Kosyakov of the Chromium development community.
In addition, we fixed a range of minor issues such as non-exploitable crashes, hangs and other annoyances. Credit to Sumit Gwalani; Google Security Team, sirdarckcat; Google Security Team, Google Chrome Security Team (Inferno), Carlos Ghan, WHK;, x41, Aki Helin; OUSPG, Jordi Chancel, kuzzcc, Robert Swiecki; Google Security Team, Tavis Ormandy; Google Security Team and Florent; Skyrecon Systems.

Also, we would like to extend our thanks to the following people who helped find bugs so we could fix them before they ever affected the stable channel: Robert Swiecki; Google Security Team, Alexey Proskuryakov; Apple, Florian Rienhardt; BSI, and Ben Davis.

Anthony Laforge
Google Chrome

Monday, May 24, 2010

[Gd] OpenSocial State of the Union 2010 Recap

| More

OpenSocial API Blog: OpenSocial State of the Union 2010 Recap

On behalf of the OpenSocial Foundation, I would like to thank everyone that attended the State of the Union event. A special thank you to the wonderful team at MySpace for arranging and hosting this event. With the participation of about a hundred at he event, I am confident we can move the standard forward.

If you missed it, you can check out the slides for the event. Here a quick summary of some of the key topics we discussed:

  • We have new Board members and great energy (Welcome Cody Simms from Yahoo! and Jason Gary from IBM). Also, please take advantage of the 2 community seats available. Nominations are open and any member of the OpenSocial Foundation is welcome to participate.
  • It is exciting to see OpenSocial adoption outside of “traditional” Social networks and into domain specific networks and even major enterprise vendors.
  • We seek your help in giving our foundation’s pages/navigation an uplift. Feel free to jump in and add your ideas.
  • OpenSocial 1.0 next--Here's what's on tap: improvements to the existing OAuth implementation, inter-gadget communication, and views for Mobile devices. We also need to pay attention to the development & spec process. Our goal is to get prototypes and spec patches in now, followed by a tight, well controlled, editing cycle.
  • The board is excited about engaging OpenSocial’s worldwide community. We are looking to sponsor events outside the U.S. and will be working on figuring this out over the next few weeks.

Here are some more details below about the event. Please feel add your thoughts & suggestions as comments to this blog post.

The event started off with introductions of the Foundation Board members and officers. Cody Simms is Yahoo!’s corporate designate. IBM is a new corporate member and has designated Jason Gary as their representatives. Welcome Cody and Jason. The complete list of your Foundation Officers and Board Members is in the FAQs.

In addition to new corporate members of the OpenSocial Foundation Board, there are two community seats available. Anyone is able to serve on the board. The only requirement to nominate or hold the position is that you must be a member of the OpenSocial Foundation. There are no membership fees to join OpenSocial. All you need to do is fill out a simple on-line membership application.

It’s been an exciting year and a half for OpenSocial! We’ve seen continued adoption of the specification as new containers come on line. Perhaps what is more interesting is that we are starting to see OpenSocial adoption outside of “traditional” social networks. This includes adoption by enterprise vendors such as Jive, Atlassian, and IBM.

Before getting into the heart of the discussion, we reviewed our current Web presence. Right now, we’ve got information buried on existing pages, scattered across different sites, and in general, have an inconsistent way of engaging our members. As a result, we are going to start looking at how to clean this up. Please post a note to the community group list if you’d like to help with this effort. There’s also a wiki page to capture your ideas.

Looking ahead for the remainder of this year and into next, we’ve got some exciting things starting to happen. First of all, we agreed on the scope and timeline for “OpenSocial 1.0 next”. There were three areas that we’d like to start working on for the next version of the spec; improvements to the existing OAuth implementation, inter-gadget communication, and views for Mobile devices. There’s already some code for intergadget communication in Shindig, and the team from Mixi has put together a good starting point for Mobile.

We will be following the development process and incorporating the extensions mechanism that we outlined last year. This means that we should be able to accept patches to the spec and prototypes now! Our goal is to get prototypes and spec patches in now, followed by a tight, well controlled, editing cycle. Ideally, this gives us time to try out the prototypes now, rather than actually developing and prototyping the new features at the same time we are writing the spec. The specification process and extension process will be updated in the next few days to reflect these ideas.

It is also worth noting is that we’d like to get as many of these prototypes as possible into Shindig so it’s easy for people to try them out. Paul Linder and the Shindig community has done a great job over the last few months of refactoring and organizing the code to make this much easier. Thanks to Paul and the Shindig committers!

One of the original goals of OpenSocial was to create a community that could rapidly prototype new ideas. With the development process, the extensions mechanism, and Shindig, we’ve got all the pieces in place to do just that. An example of this is the work that has been done to provide a prototype of the specification.

But we don’t want to stop there! A number of new and exciting ideas in the social Web space are emerging, and as a community, we should be prototyping them as quickly as possible to understand their impact to OpenSocial. Examples of these include Salmon, Pubsubhubbub, Web Finger, and OAuth 2.0. Let’s get prototypes going now so that when these specs become final, it’s easy for us to provide an open source implementation and a clean path into OpenSocial spec. This way, we can move the entire industry forward—together—faster.

So far, most (if not all), of the ‘official’ OpenSocial Foundation sponsored events have been located in the United States. One of our goals for this year is to change that. A number of members have expressed interest in having events in Asia and Europe. This is a great way for our community to engage the large number of world wide container providers and businesses that are successfully implementing OpenSocial. The Board is very excited about reaching out to our worldwide membership and is looking forward to helping the community make this happen.

Thank you, once again, to the team at MySpace. There were great to work with and put on a fantastic event. I would also like to thank our community. It’s because of you that we had a great event.

Now let’s get prototyping!

Posted by Mark Weitzel, on behalf of the OpenSocial Foundation


[Gd] Sandbox Account Viewer Released

| More

AdWords API Blog: Sandbox Account Viewer Released

The Sandbox Account Viewer is a sample application that demonstrates how to use the AdWords API client library to display contents of an AdWords sandbox account. It can be used to visualize the effects of a request on your account and to retrieve information such as IDs that are needed when running examples. We are sharing this code as open source to provide a starting point for new developers and to demonstrate some of the core functionality in the API.

The Sandbox Account Viewer does not attempt to replicate the official AdWords web interface, but rather displays information exactly as it is returned by the API. The objects in the account are displayed in a tree on the left, and when selected their details are displayed in a table to the right.

Sandbox Account Viewer Screenshot

To get started, download the source code and open the project in Eclipse or your favorite Java IDE. Read through the README and javadoc comments to understand how the application works and use the Ant task "run" to launch it. We encourage you to modify the code and experiment with new functionality. If you develop a great feature let us know so we can upstream it in to the official source.

If you have Java enabled in your browser you can click here to launch a preview of the application. Bugs, feature requests, or contributions can be filed on the Java client library issue tracker and any questions can be posted to the AdWords API forum.

- Eric Koleda, AdWords API Team

[Gd] Android Application Error Reports

| More

Android Developers Blog: Android Application Error Reports

[This post, the first in a series about new features in Android 2.2 ("Froyo"), is by Jacek Surazski, a Googler from our Krakow office. — Tim Bray]

The upcoming release of Android will include a new bug reporting feature for Market apps. Developers will receive crash and freeze reports from their users. The reports will be available when they log into their Android Market publisher account. No more blind debugging!

When an app freezes or stops responding, the user can send a bug report to the developer with a click of a button, right from their phone. The new button appears in the application error dialog; if the user chooses to click it, the Google Feedback client running on the device will analyze the offending app and compose a report with information needed to diagnose it. The system is set up with user privacy in mind — the app developer will not receive information which could identify the user in any way. The user can also preview all information that will be sent.

If users choose to do so, they may also send additional system information like device logs. Because there is a chance these may contain private information, they will not be passed on to the developer; they will be used by Google to track down bugs in the Android system itself.

On the receiving end, developers will get tools to diagnose, triage and fix bugs in their apps. A popular app can generate hundreds of thousands of reports. Google Feedback aggregates them into "bugs" - individual programming errors. Bugs are displayed to developers sorted by severity, measured as the rate at which reports for the bug are flowing in.

Clicking on a bug will display information such as stack traces, statistics about which type of hardware the bug occurred on and what versions of the app the user was running. In case of freezes, stack traces for all threads in the app will be displayed. This data should give developers a good idea how well their apps are faring in the wild.

Google is constantly working on improving and extending the feedback feature to provide developers with tools to improve the quality of their apps. The benefits should be felt by both developers and their users.

[I recommend watching the video of this feature's announcement in Vic Gundotra's Google I/O keynote on May 20th, mostly for the audience reaction. I hear that a high proportion of developers are making use of the Market's new "Bugs" tab. — Tim Bray]