Friday 29 January 2010
Facebook StumbleUpon Twitter Google+ Pin It

Flashy New Authentication: AuthSub Adds Support for ActionScript

Today, we are happy to announce the launch of AuthSub for ActionScript, a new component of the well-known AuthSub authentication interface for the Google Data Protocol. This new feature enables Flash and Silverlight applications to access data securely on behalf of a user, without the application ever seeing the user’s private login credentials.

To use AuthSub for Actionscript (or as we’re calling it, AuthSubAS), first ensure that the API you are accessing offers cross-domain support. To do this, simply check for a crossdomain.xml file like those offered by the Picasa Web Albums Data API and the YouTube Data API. Then, if the API supports cross-domain scripting, you can simply point your Flash app to https://accounts.googleapis.com/accounts/AuthSub{Request,SessionToken} and authenticate. If you’re familiar with how AuthSub for JavaScript works, AuthSubAS works in much the same way. For more information, see the AuthSub for ActionScript guide and check out this code sample.

Currently, cross-domain requests are only supported by the Picasa Web Albums Data API and the YouTube Data API.  However, as more APIs offer cross-domain scripting through an open crossdomain.xml file, the AuthSubAS authentication will work automatically. For questions about a specific API or to encourage your API to provide AuthSubAS support sooner, visit your API’s support group in Google Groups.

Wednesday 27 January 2010
Facebook StumbleUpon Twitter Google+ Pin It

A proposal to extend the DNS protocol

Today a group of DNS and content providers, including Neustar/UltraDNS and Google are publishing a proposal to extend the DNS protocol. DNS is the system that translates an easy-to-remember name like www.google.com to a numeric address like 74.125.45.104. These are the IP addresses that computers use to communicate with one another on the Internet.

By returning different addresses to requests coming from different places, DNS can be used to load balance traffic and send users to a nearby server. For example, if you look up www.google.com from a computer in New York, it may resolve to an IP address pointing to a server in New York City. If you look up www.google.com from the Netherlands, the result could be an IP address pointing to a server in the Netherlands. Sending you to a nearby server improves speed, latency, and network utilization.

Currently, to determine your location, authoritative nameservers look at the source IP address of the incoming request, which is the IP address of your DNS resolver, rather than your IP address. This DNS resolver is often managed by your ISP or alternately is a third-party resolver like Google Public DNS. In most cases the resolver is close to its users, in which case the authoritative nameservers will be able to find the nearest server. However, some DNS resolvers serve many users over a wider area. In these cases, your lookup for www.google.com may return the IP address of a server several countries away from you. If the authoritative nameserver could detect where you were, a closer server might have been available.

Our proposed DNS protocol extension lets recursive DNS resolvers include part of your IP address in the request sent to authoritative nameservers. Only the first three octets, or top 24 bits, are sent providing enough information to the authoritative nameserver to determine your network location, without affecting your privacy.

The Internet-Draft was posted to the dnsext mailing list today, and over the next few months our group hopes to see this proposal accepted as an official Internet standard. We plan to continue working with all interested parties on implementing this solution and are looking forward to a healthy discussion on the dnsext mailing list.

(Updated 24 Jan 2011 to fix broken links)

Tuesday 26 January 2010
Facebook StumbleUpon Twitter Google+ Pin It

Create and share Google Sites with new Sites Data API features

Several months ago we launched the Google Sites Data API. Since then, we've worked hard to respond to your top feature requests: the ability to list a user's sites, create new sites, copy existing sites, and manage sharing permissions. Today, we are very excited to announce the release of the Site and Access Control List feeds that make these new features possible.

The Site feed allows your client to list sites and update their properties, such as the title or the theme of the site. Google Apps users can also create new sites. Because creating new sites often involves copying existing ones (perhaps using a site template), we've enabled that feature too.

Here's an example of the kinds of applications you can build with those features. Let's say you're a professor at a university and you'd like to create a Google Site for each of the courses you teach. The Site feed makes it possible for you to create a site course template, use the site feed to create several course sites, and personalize them with the content feed.

But what if you want to restrict access to your sites to just the students taking those courses? With the ACL (Access Control List) feed, you can manage sharing permissions. Everything you can do in the Google Sites admin panel, you can do with the API.

To get the full scoop, review the documentation and change log. We've loaded the Java client library and Python client library with the new features, and offer updated developer guides for both.

Visit us in our new developer forum if you have questions!


Monday 25 January 2010
Facebook StumbleUpon Twitter Google+ Pin It

Extensibility + new HTML and JavaScript APIs for Google Chrome

Today's new stable release of Google Chrome for Windows includes a bundle of browser goodness, including extensions and new HTML and JavaScript APIs.

Extensions -- previously available on Google Chrome for Windows on the beta channel -- and are now available to all users. Extensions enable you to provide additional functionality not just on your site, but to bring content and functionality from your site into the browser regardless of what sites the user has open. Google Chrome extensions use the same multiprocess technology that makes the browser fast and more secure, so that extensions won't crash or slow down your browser.


In addition, we're excited to introduce a number of new HTML and JavaScript APIs in Google Chrome, including the Web Storage and Web SQL Database APIs, WebSockets, and more. For more details about these APIs, read further on the Chromium Blog.

If you have questions about the extensions APIs, the extensions discussion group continues to be the best place to get answers. For the new HTML and JavaScript APIs, check out the newly created Chromium HTML5 group. And for those of you who are interested in attending Google I/O, check out the current list of Google Chrome sessions.

Tuesday 12 January 2010
Facebook StumbleUpon Twitter Google+ Pin It

​Documents List API: Upload any file type and more!

As just announced over on the Enterprise blog, Google Docs now allows users to upload any type of file! Over the next couple of weeks we’ll be rolling out the same feature in the Documents List Data API. For now, uploading arbitrary files via the API will be restricted to Google Apps Premier domains. For starters, each user gets 1GB of storage with a maximum size of 250 MB per file.

Combined with the shared folders feature of Google Docs, we think this new feature is a great way to build collaborative applications for exchanging files with coworkers and external parties. No more email attachments!

In addition to arbitrary file upload, we’re launching several top features requested by developers:
Look for resumable upload support in the Java, Python, and Objective-C client libraries in the near future. As always, if you have any questions, please visit us in our new developer forum.

Issues resolved in this release: 72, 1040, 1675, 1260, 1741, 1127

Google I/O 2010: Now open for registration

I'm excited to announce that registration for Google I/O is now open at code.google.com/io. Our third annual developer conference will return to Moscone West in San Francisco on May 19-20, 2010. We expect thousands of web, mobile, and enterprise developers to be in attendance.

I/O 2010 will be focused on building the next generation of applications in the cloud and will feature the latest on Google products and technologies like Android, Google Chrome, App Engine, Google Web Toolkit, Google APIs, and more. Members of our engineering teams and other web development experts will lead more than 80 technical sessions. We'll also bring back the Developer Sandbox, which we introduced at I/O 2009, where developers from more than 100 companies will be on hand to demo their apps, answer questions and exchange ideas.

We'll be regularly adding more sessions, speakers and companies on the event website, and today we're happy to give you a preview of what's to come. Over half of all sessions are already listed, covering a range of products and technologies, as well as speaker bios. We've also included a short list of companies that will be participating in the Developer Sandbox. For the latest I/O updates, follow us (@googleio) on Twitter.

Today's registration opens with an early bird rate of $400, which applies through April 16 ($500 after April 16). Faculty and students can register at the discounted Academia rate of $100 (this discounted rate is limited and available on a first come, first serve basis).

Last year's I/O sold out before the start of the conference, so we encourage you to sign up in advance.

Google I/O
May 19-20, 2010
Moscone West, San Francisco

To learn more and sign up, visit code.google.com/io.

We hope to see you in May!

(Cross-posted with the Official Google Blog)