Author Archive

One of the most exciting things about the architecture of the web is how easily it supports mashups—URLs, IFRAMEs, XHR, and more make it easy to build great new services on top of building blocks from others. As more and more people use the web for non-public data, we need new techniques to secure those building blocks. That’s where OAuth comes in—an open, standard way for users to grant permission for an application to access part of their account.

Since we announced support for OAuth in 2008, we've seen tremendous usage growth in our APIs that require user authorization, like Calendar and Docs. While the spec isn't completely finalized, Google is pleased to announce our experimental support of an easier way for developers to obtain user authorization for our APIs: OAuth 2.0 with bearer tokens. Whether you use our updated client libraries or just write to the protocol, you should be able to do more with less code.

In addition to supporting a simplified protocol, we're also introducing a simpler, cleaner consent page for OAuth 2.0:


Google believes in open systems that give users value, transparency and control. We hope the OAuth 2.0 protocol helps developers deliver just that: powerful applications that make use of user data without compromising on safety or security. Check out our documentation to get started with OAuth 2.0.

By Andrew Wansley, Google Developer Team

As Vic announced last week, we will be kicking off our Last Call for Google I/O contest tomorrow. We will be starting promptly at 9:00 A.M. PDT on March 16th with our Android challenge. As a reminder, here’s the contest schedule again:

March 16 - Android, 9:00 am
March 17 - Chrome, 9:00 am
March 18 - App Engine, 9:00 am
March 21 - YouTube APIs, 9:00 am
March 22 - Game Developers, 9:00 am
March 23 - Google Maps / Geo, 4:00 pm
March 24 - Commerce, 9:00 am
March 25 - Developer Tools / GWT, 9:00 am
March 28 - Accessibility, 4:00 pm
March 29 - Google Apps / Enterprise, 4:00 pm

All times are listed in PDT

When you visit the site tomorrow morning, you will see a tab in the navigation that reads “Android”--that’s where you will find all of the questions and submission forms for Round I. We’re excited to see what everyone comes up with!

By Monica Tran, Google I/O Team

We at Google go to great lengths to ensure every step is taken to protect our users’ data. As part of our ongoing effort to improve security everywhere, we will start requiring the use of SSL in many products. Requiring SSL improves security by encrypting data communications between users and Google, better protecting it from being intercepted by a malicious third party.

Some of these changes have already occurred. Many user-facing Google products now allow or require SSL, including encrypting Google web search, defaulting to SSL in Gmail, and requiring SSL in Google Docs. Next on our list is to improve SSL support for our developer facing APIs. For most APIs, our technical documentation, client libraries and code samples already use SSL. Many new APIs and versions will be SSL only. Further, the Google Maps API, which previously offered SSL only to Premier customers, is offering SSL to all developers starting today.

Additionally, beginning September 15, 2011, Google will require that all users of Google Documents List API, Google Spreadsheets API, and Google Sites API use SSL connections for all API requests. Specifically, this change will disallow all HTTP requests, responding with an HTTP 400 Bad Request response. API requests will only be accepted via HTTPS. For example, a request to http://docs.google.com/feeds/default/private/full will no longer pull a list of a user's documents. Instead, a request must be made to https://docs.google.com/feeds/default/private/full.

This change should be transparent if you're using the most recent version of the Google Data client libraries, since they already use SSL for all requests. If you're not using the latest version, then please upgrade as soon as possible. If you're not using our client libraries, then simply change any use of an HTTP URL to its corresponding HTTPS version in your code. Your existing OAuth and AuthSub tokens will continue to work using the HTTPS URLs, even if they were requested with a scope that uses an ‘http://’ scheme.

Although we’re initially requiring SSL for only a few APIs (those whose traffic was already mostly over SSL), we strongly recommend that you convert all your API clients as soon as possible to help protect your users’ data. Check the documentation for each API for more information about that API's SSL support, including the updated Google Documents List API documentation, Google Spreadsheets API documentation, and Google Sites API documentation.

If you have any questions or concerns about this change, please follow up in the forums of the API you are using.

By Adam Feldman, Google Developer Team

By now, many of you have seen our recent announcement regarding 2-step verification for Google Accounts. It’s an optional way of protecting your Google Account from unauthorized access, providing a level of security beyond that of a password alone. The initial announcement did not detail the impact enabling 2-step verification has on programmatic account access from code written against one of Google’s official APIs. We want to go into some more detail regarding the implications of 2-step verification on various authentication (and authorization) techniques, and offer best practices that you as a developer should follow.

There are three forms of authentication supported by almost all of Google’s APIs. AuthSub and OAuth (either version 1 or the newer OAuth 2) are similar web-based authentication mechanisms in which the user logs in on a web page hosted by Google. The other approach to authentication, ClientLogin, relies on your application soliciting the user’s account address and password, and then sending that information to Google.

If your code uses AuthSub or OAuth, then you don’t have to do anything special to accommodate users who have opted-in to 2-step verification. The web-based login flow currently allows users to enter both their normal passwords as well as the additional verification code, and this extra step is transparent to you as the developer.

ClientLogin, however, does not fare as well for accounts that have 2-step verification enabled. There is no concept of an additional verification code in the ClientLogin process, and a user’s account address and password are no longer sufficient for authenticating them once 2-step verification is turned on. If you make a ClientLogin authentication request for such an account, you’ll get back an HTTP 403 error response from our servers with the following in error included in the response body:


Error=BadAuthentication
Info=InvalidSecondFactor


There are two solutions to these failed ClientLogin attempts. The first solution, which does not require changing any existing code, is to ask your users to generate an application-specific password and to provide that, instead of their Google Account passwords, when making your ClientLogin request. You can point your users to this article for a full explanation of how application-specific passwords work.

The second, and recommended, solution requires some work on your part as a developer: moving away from ClientLogin completely, in favor of OAuth 2. If your code runs as part of a web application, then OAuth 2’s web-based login flow is trivial to integrate. Even applications that are installed on a user’s computer or other device can leverage OAuth 2, though. This guide explains how to launch a web browser to handle the login process, and then redirect control back to your application.

While it may take some effort to migrate your code away from ClientLogin, your users will be grateful that you did. Even those who haven’t enabled 2-step verification will benefit from entering their credentials on a web page accessed via HTTPS and hosted by Google, as opposed to sharing their password information directly with your third party code.

By Jeffrey Posnick, Google Developer Relations

At Google we’re constantly trying to make the web faster — not just our corner of it, but the whole thing. Over the past few days we’ve been rolling out a new and improved version of show_ads.js, the piece of JavaScript used by more than two million publishers to put AdSense advertisements on their web pages. The new show_ads is small and fast, built so that your browser can turn its attention back to its main task — working on the rest of the web page — as soon as possible. This change is now making billions of web pages every day load faster by half a second or more.

The old show_ads did lots of work: loading additional scripts, gathering information about the web page it was running on, and building the ad request to send back to Google. The new show_ads has a different job. It creates a friendly (same-origin) iframe on the web page, and starts the old script with a new name, show_ads_impl, running inside that iframe. The _impl does all the heavy lifting, and in the end the ads look exactly the same. But there’s a substantial speed advantage: many things happening inside an iframe don’t block the web browser’s other work.

How much of an effect this has depends on context: a page with nothing but ads on it isn’t going to get any faster. But on the real-world sites we tested, the latency overhead from our ads is basically gone. Page load times with the new asynchronous AdSense implementation are statistically indistinguishable from load times for the same pages with no ads at all.

The new show_ads is a drop-in replacement for the old one: web site owners don’t need to do anything to get this speed-up. But these dynamically-populated friendly iframes are finicky beasts. For now, we’re only using this technique on Chrome, Firefox, and Internet Explorer 8, with more to come once we’re sure that it plays well with other browsers.

And what if you’ve built a page that loads AdSense ads and then manipulates them in exotic ways not compatible with friendly iframes? (This is the web, after all, land of “What do you mean that’s ‘not supported’? I tried it, and it worked!”) You can set “google_enable_async = false” for any individual ad slot to revert to the old blocking behavior. But if your site loads ads in some tortuous way because you were looking for latency benefits, consider giving the straightforward invocation of show_ads.js a whirl. Because now, we’re fast.

By Michael Kleber, Ads Latency Team

In celebration of Google I/O 2011, many Google offices around the world, as well as GTUG partners and Student Ambassadors, are hosting free viewing parties of Google I/O sessions. If you can't attend Google I/O in person, these events are a way to connect with other talented developers and watch live feeds of the conference.

Part viewing party and part community building, Google I/O Extended events are free and worldwide, focused on bringing the developer community together to live-stream the keynote and other major sessions of Google I/O. Each location’s event will be a little different, so check the registration page of the closest location to see what they have planned. With limited space, registration is required. Learn more and find an I/O Extended event near you on the I/O Extended site. These events are being organized by local developer community leaders and university ambassadors, so please reach out to them specifically if you have any questions about the details.

Here are just a few of the locations hosting an I/O Extended event:

Africa

• Cairo, Egypt

Asia

• Manila, Philippines
• Pune, India
• Taipei, Taiwan

Europe

• Aachen, Germany
• Barcelona, Spain
• Berlin, Germany
• Brussels, Belgium
• Bucharest, Romania
• Dublin, Ireland
• London, England
• Madrid, Spain
• Malaga, Spain
• Istanbul, Turkey
• Kyiv, Ukraine
• Munich, Germany
• Murcia, Spain
• Vienna, Austria
• Warsaw, Poland

North America

• Boise, ID, USA
• Charlotte, NC, USA
• Maui, HI, USA
• San Jose, CA, USA
• Twin Cities, MN, USA
• Washington, DC, USA
• Waterloo, Ontario, Canada (link updated)

South America and Central America

• Belo Horizonte, Brazil
• Buenos Aires, Argentina
• Guatemala City, Guatemala

See more locations on the map and register for a Google I/O Extended event in your area.

We look forward to having you join us for Google I/O Extended!

By Amy Walgenbach, Google I/O Team

(Cross-posted from the Google Webmaster Central Blog.)

Today we’re launching the most requested feature for Page Speed, Page Speed for Chrome. Now Google Chrome users can get Page Speed performance suggestions to make their sites faster, right inside the Chrome browser. We would like to thank all our users for your great feedback and support since we launched. We’re humbled that 1.4 M unique users are using the Page Speed extension and finding it useful to help with their web performance diagnosis.

Google Chrome support has always been high on our priority list but we wanted to get it right. It was critical that the same engine that powers the Page Speed Add-On for Firefox be used here as well. So we first built the Page Speed SDK, which we then integrated into the Chrome extension.

Page Speed for Chrome retains the same core features as the Firefox add-on. In addition, there are two major improvements appearing in this version first. We’ve improved scoring and suggestion ordering to help web developers focus on higher-potential optimizations first. Plus, because making the web faster is a global initiative, Page Speed now supports displaying localized rule results in 40 languages! These improvements are part of the Page Speed SDK, so they will also appear in the next release of our Firefox add-on as well.

If your site serves different content based on the browser’s user agent, you now have a good method for page performance analysis as seen by different browsers, with Page Speed coverage for Firefox and Chrome through the extensions, and Internet Explorer via webpagetest.org, which integrates the Page Speed SDK.

We’d love to hear from you, as always. Please try Page Speed for Chrome, and give us feedback on our mailing list about additional functionality you’d like to see. Stay tuned for updates to Page Speed for Chrome that take advantage of exciting new technologies such as Native Client.

By Matthew Steele and Richard Rabbat, Page Speed Team

(Cross-posted with the Google Open Source Blog.)

Google Summer of Code is a global program where university students are given a stipend to write code for open source projects over a three month period. Through Google Summer of Code, accepted students are paired with a mentor from the participating projects, gaining exposure to real-world software development and the opportunity for employment in areas related to their academic pursuits. Best of all, more source code is created and released for the use and benefit of all.

Google Summer of Code is a highly competitive program with a limited number of students being accepted. We are pleased to announce that this year we have enlarged the program so that we can accept as many as 150 additional students. We hope all interested students will apply!

Now it is time for the students to submit their proposals to the accepted mentoring organizations via the Google Summer of Code program website from today through Friday, April 8th 19:00 UTC. For the past 10 days students have had the opportunity to review the Ideas pages for this year’s 175 accepted projects and to research which projects they would like to contribute to for this year’s Google Summer of Code.

Every year we have thousands of students who apply for the Google Summer of Code program but due to the limited number of slots many students are not able to be a part of the program. The quality of your proposal is what will make you stand out from your peers. Students should consult the Google Summer of Code student manual for suggestions on how to write a proposal that will grab the attention of the mentoring organizations. Multiple proposals are allowed but we highly recommend focusing on quality over quantity. The mentoring organizations have many proposals to review, so it is important to follow each organization’s specific guidelines or templates and we advise you to submit your proposal early so you can receive timely feedback.

By Scott Knaster, Google Developer Relations

Hello, esteemed Google Code Blog readers! My name is Scott Knaster, and I’m the new editor of this blog. I’m interrupting the usual flow of posts to let you know about some new things happening around here. This blog has the company’s name on it, but of course, like all blogs, it’s written by individual people, to be read by other individual people, like you. We want to do a little more to celebrate that, starting with these small steps:

• We’re adding a photo and some info about each post’s author. Googlers get around, to hackathons, conferences, and GTUGs, and now you’ll have faces to match up with names when we meet in real life.
• We’ll spend more time responding to comments. As always, we encourage and appreciate your thoughtful, on-topic comments.
• We’ll be tweeting more at @googlecode over on Twitter, too. And you can find a list of Google developer-related Twitter accounts here (choose Developers from the Category drop-down).
• I’ll be hanging around here a lot. Think of me as the host of a big, geeky dinner party. Mostly I’ll be helping edit posts written by others—experts who work on the products they post about—but I’ll also write a few posts myself.

I’ve been working with APIs and platforms for a long time, mostly by writing docs about how to use them. Platforms are full of promise, but they’re only interesting and worthwhile when people build on them.

Please email me at sknaster@google.com if you have any thoughts or feedback for improving this blog. Or, just leave a comment on this post.

Thanks for being here!

By Andrew Oates and Richard Rabbat, Page Speed Team

At Google, we’re striving to make the whole web fast. As part of that effort, we’re launching a new web-based tool in Google Labs, Page Speed Online, which analyzes the performance of web pages and gives specific suggestions for making them faster. Page Speed Online is available from any browser, at any time. This allows website owners to get immediate access to Page Speed performance suggestions so they can make their pages faster.



In addition, we’ve added a new feature: the ability to get Page Speed suggestions customized for the mobile version of a page, specifically smartphones. Due to the relatively limited CPU capabilities of mobile devices, the high round-trip times of mobile networks, and rapid growth of mobile usage, understanding and optimizing for mobile performance is even more critical than for the desktop, so Page Speed Online now allows you to easily analyze and optimize your site for mobile performance. The mobile recommendations are tuned for the unique characteristics of mobile devices, and contain several best practices that go beyond the recommendations for desktop browsers, in order to create a faster mobile experience. New mobile-targeted best practices include eliminating uncacheable landing page redirects and reducing the amount of JavaScript parsed during the page load, two common issues that slow down mobile pages today.

Page Speed Online is powered by the same Page Speed SDK that powers the Chrome and Firefox extensions and webpagetest.org.

Please give Page Speed Online a try. We’re eager to hear your feedback on our mailing list and find out how you’re using it to optimize your site.