Thursday, 30 October 2008
Facebook StumbleUpon Twitter Google+ Pin It

Moving another step closer to single-sign on

By Eric Sachs, Google Security Team

Yesterday we announced one step we took to help increase adoption of single-sign on across websites on the Internet. For more details, you can watch today's episode of which covers the launch. While we announced that we would initially provide limited access to our OpenID IDP to make sure it was working properly, we were delighted to see that the number of sites that registered to receive access was significantly more than we had expected. So instead of having our engineers spend time manually maintaining that list of registered sites, we are now taking another step further and removing that restriction so any site can use the API.

That registration requirement also led to some confusion because users wanted to be able to use existing websites that accept OpenID 2.0 compliant logins by simply entering "" (or in some cases their full E-mail address) into the login boxes on those websites. Normally what would happen after a user typed is that the relying party website would look for a special type of file (XRDS) on the servers that would check if Gmail run an OpenID identity provider. For yesterday's launch, we specifically chose not to publish that special XRDS file on because if we had published the file, users would have received an error at Google if the website they were trying to log into had not registered with us. Now that we have removed the registration requirement, we will work on pushing that XRDS file as quickly as possible. Once the XRDS file is live, end-users should be able to use the service by typing in the OpenID field of any login box that supports OpenID 2.0, similar to how Yahoo users can type or their Yahoo E-mail address. (In the meantime, if you feel really geeky, you can type "" into an OpenID 2.0 compliant login box and see the directed identity workflow in action.)

However, as we we noted in the Designing a Login User Interface section of our documentation, we do not place any requirements on the design of a federated login box on a relying party website. There are many approaches used by websites today, and the community is still experimenting with new approaches.

One other question that a lot of people asked yesterday is when a large provider like Google will become a relying party. There is one big problem that stands in the way of doing that, but fortunately it is more of a technology problem than a usability issue. That problem is that rich-client apps (desktop apps and mobile apps) are hard-coded to ask a user for their username and password. As an example, all Google rich-client apps would break if we supported federated login for our consumer users, and in fact they do break for the large number of our enterprise E-mail outsourcing customers who run their own identity provider, and for which Google is a relying party today. This problem with rich-client apps also affects other sites like Plaxo who are already relying parties.

Google is committed to working on this problem. If community members also want to help in this area, please take a look at our research on combining rich-client apps with federated login which was discussed at the recent UX summit and discussed further in a blog post here. A key thing to notice is that this research is about another open source technology called OAuth, and is agnostic to the particular federated login technology used, i.e. SAML or OpenID. It is also agnostic to the type of strong authentication method (if any) that is used to authenticate the user.

To further increase the adoption of federated login, we need standard open-source components on as many platforms as possible to enable those rich-client apps to support OAuth. That includes a lot more platforms then just Windows and Mac. The harder part is mobile devices (Blackberry, Symbian, Windows Mobile, iPhone, and yes even Android), and other Internet connected devices like Tivos, Apple TVs, Playstations, etc. that have rich-client apps that ask users for their passwords to access services like Youtube, Google photos, etc. If the community works together to build these components, they will be useful not only to Google, but also to any other relying parties that have rich-client apps or that expose APIs, and it will also help enterprise SaaS vendors like Salesforce.

If you want to help further these efforts, join the OpenID and OAuth mailing lists and tell people which platform you are targeting in case others want to help. For example, Mike Malone from Pownce did some work a few months ago to use OAuth on an iPhone and described how he got it working. And just yesterday another member of the open source community, Sean Sullivan, built a working OAuth enabled rich-client app for Android and posted the open source code.

Wednesday, 29 October 2008
Facebook StumbleUpon Twitter Google+ Pin It

Google moves towards single sign-on with OpenID

Currently users are required to create individual passwords for many websites they visit, but users would prefer to avoid this step so they could visits websites more easily. Similarly, many websites on the Internet have asked for a way to enable users to log into their sites without forcing them to create another password. If users could log into sites without needing another password, it would allow websites to provide a more personalized experience to their users.

In September we announced some research that we shared as part of an effort by the OpenID community to evaluate the user experience of federated login. Other companies like Yahoo have also published their user research. Starting today, we are providing limited access to an API for an OpenID identity provider that is based on the user experience research of the OpenID community. Websites can now allow Google Account users to login to their website by using the OpenID protocol. We hope the continued evolution of both the technical features of OpenID, as well as the improvements in user experience. will lead to a solution that can be widely deployed for federated login. One of the companies using this new service is Raju Vegesna at ZoHo says that "We now offer all our users the ability to login to ZoHo using their Google Account to avoid the need to create yet another login and password."

The initial version of the API will use the OpenID 2.0 protocol to enable websites to validate the identity of a Google Account user, including the optional ability to request the user's e-mail address. Below is an example of the flow that a user might see if he or she starts at a website that uses this new feature:

The website could use a modified login box that looks like the one below. If the user enters a Gmail address and indicates that he or she does not have a password for this site, then the site can redirect him or her to Google.

The user would then be taken to the Google website and asked to confirm whether he or she wants to sign in to KidMallPics.

Finally, the user would be redirected back to KidMallPics, where he or she would be immediately signed in.

More information about this new API can be found on the Open ID page in Google Code. To request access to the limited trial, please visit our Google Federated Login discussion group and register using the online registration form.

Google is also working with the open source community on ways to combine the OAuth and OpenID protocol in the future. That way a website can not only request the user's identity and e-mail address, but can also request access to information available via OAuth-enabled APIs such as Google Data APIs as well as standard data formats such as Portable Contacts and OpenSocial REST APIs. In the future, this should allow a website to immediately provide a much more streamlined, personalized and socially relevant experience for users when they log in to trusted websites.

Friday, 24 October 2008
Facebook StumbleUpon Twitter Google+ Pin It

Looks Good To Me, Part Deux -- Assigned Code Reviewers

In our continuing effort to improve project hosting, we have just launched a new code review feature called "assigned reviews". Assigned reviews builds on the post-commit source code review tool we announced back in July, providing your team a more structured approach to soliciting feedback and improving the quality of your code base.

Now projects that use code reviews have two choices: post-commit reviews for code reviews after submission, and assigned code reviews for all code heading into trunk. Of course, you can also not use any reviews at all. Use whatever style or styles that work best for your team.

How does it work? Simple. Commit your code to a branch of your choosing, then create a new "Type-Review" Issue requesting that another team member do a code review for your branch. Review requests can be labeled, commented on, and assigned (or reassigned) like any other issue. Once created, review requests show up both in your project's issue tracker, and in a new table at the top of your project's recent source code changes list. Check it out:

For detailed instructions, see the code review tool documentation.

Be on the lookout for more improvements to the review process in the future. Happy reviewing!

Tuesday, 21 October 2008
Facebook StumbleUpon Twitter Google+ Pin It

Introducing the Gears Geolocation API for all laptop WiFi users

By Charles Wiles, Product Manager, Google Mobile Team

I am thrilled to announce that today we have enhanced the Gears Geolocation API so that developers can now securely locate users to within 200m accuracy in major desktop browsers in hundreds of cities around the world. Whether your users are Chrome, Internet Explorer, Safari, Firefox or (soon) Opera users, you can now automatically deliver an experience that is tailored to their current location. For example,'s new Radar application allows users to find nearby hotels, ITN's Google Earth mash up in Firefox allows users to see nearby news stories and Rummble's social discovery site allows users to automatically set their current location for friends to see.

When we originally proposed the Gears Geolocation API our goal was to make it easy for developers to deliver location enabled web sites on mobile phones. However we realized laptop users would benefit from location enabled web sites too. Today we are adding WiFi signals to the Geolocation API so that laptop users can benefit from location enabled web sites for the first time and mobile users from the increased accuracy. And because the Geolocation API is the same for developers in both desktop and mobile browsers you can even use the same code on both platforms!

In Chrome and Android, with Gears built in, you can deliver a location enabled web site without requiring your users to install a plug-in, but in other browsers they will need to go through a simple plug-in install process. We also submitted a simplified version of the Geolocation API as a WC3 specification and the upcoming Firefox 3.1 plans to support the W3C version directly. The Gears Geolocation API is completely free to developers and users through the default Google location provider.

To protect user privacy, the Gears Geolocation API server does not record user location. However, third party sites may do so, and we recommend that users only allow web sites they trust to access their location. Gears will always tell a user when your site wants to access their location for the first time and the user can either allow or deny your site permission. We recommend users check the privacy policy of your web site if they are in doubt as to how your site may use location information.

Thursday, 16 October 2008
Facebook StumbleUpon Twitter Google+ Pin It

iGoogle launches canvas view

By Dan Holevoet, Developer Programs

We're happy to announce the launch of the canvas view feature to iGoogle users in the U.S., rolling out over the course of the day.  The canvas view feature allows gadget developers to build richer content, games, and UI for iGoogle's tens of millions of users by allowing them to build powerful full-page applications. In addition, canvas view provides developers with the opportunity to monetize their gadgets.

To get started, check out the documentation and examples on the iGoogle developer website. The site includes detailed information about iGoogle as well as information on upcoming OpenSocial functionality.

Try out the updated version of iGoogle and check out some of the great canvas view gadgets developers have already built.

Thursday, 9 October 2008
Facebook StumbleUpon Twitter Google+ Pin It

Gadgets and Google Code

Gadgets and Google Code have always had a special relationship, as many developers use Google Code to host their gadgets. We are, therefore, happy to announce that you can now add gadgets to any wiki page (including the project homepage) on Google Code using the <wiki:gadget> syntax shown below.

<wiki:gadget url="" border="0">

To show you how powerful this is, we created a page of gadgets we found useful. See MarkMail's announcement and Ohloh's announcement for more details about their gadgets.

While gadgets are a great way to bring content to Google Code, they are also a great way to take a little piece of Google Code with you. Take the google-web-toolkit issue tracker as an example:

They enable you to create your own personal dashboard. In fact, this is how I track my various projects. To enable this, new Google Code project hosting gadgets are now available for each project on Google Code. They can be discovered under the feeds link in the project homepage.

Let us know what you think! We'd love to hear your ideas on how to make the Gadgets integration on Google Code even better!

As always, we look forward to your feedback.

Zoho Mail goes offline with Gears

We have so much respect for the Zoho team here at Google. They produce great software, and they do it regularly! Their latest accomplishment has been getting their email product, Zoho Mail, working offline.

Brad Neuberg sat down with the guys to chat about this new release. He delves into the offline flow of the product, and then into the architecture behind it. How do they handle syncing? What features do they turn off when you are offline? How explicit to you have to be? Listen in to hear their thoughts!

Thursday, 2 October 2008
Facebook StumbleUpon Twitter Google+ Pin It

Project Updates on Google Code

We are happy to announce that we just launched project update streams (and feeds) for each open source project on Google Code. The new project updates page, which is linked to from each project homepage, shows the updates that are occurring in the project.

One of the benefits of open source software development is that you can watch how the software is built. Take a look at the updates of some popular open source projects:

These updates are also available as feeds. Here are the feeds for the urls above:

Wednesday, 1 October 2008
Facebook StumbleUpon Twitter Google+ Pin It

Measuring Speed The Slow Way

Let's say you figured out a wicked-cool way to speed up how quickly your website loads. You know with great certainty that the most popular web page will load much, much faster. Then, you remember that the page always loads much, much faster in your browser with the web server running on your development box. You need numbers that represent what your users will actually experience.

Depending on your development process, you may have several measuring opportunities such as after a live release, on a staging server, on a continuous build, or on your own development box.

Only a live release gives numbers that users experience--through different types of connections, different computers, different browsers. But, it comes with some challenges:
  • You must instrument your site (one example tool is jiffy-web).
  • You must isolate changes.
    • The most straight-forward way to do that is to release only one change at a time. That avoids having multiple changes altering performance numbers--for better or for worse--at the same time.
  • Consider releasing changes to a subset of users.
    • That helps safe-guard against real-world events like holidays, big news days, exploding hard drives, and, perhaps the worst possible fate of all: a slashdotting.
Measuring real traffic is important, but performance should also be measured earlier in the development process. Millions of users will not hit your development web server--they won't, right?! You need a way to measure your pages without that.

Today, Steve Souders has released Hammerhead, a Firefox plug-in that is just the ticket for measuring web page load times. It has a sweet feature that repeatedly loads pages both with and without the browser cache so you can understand different use cases. One thing Hammerhead will not do for you is slow down your web connection. The page load times that you measure on your development machine will likely be faster than your users' wildest dreams.

Measuring page load times with a real DSL or dial up connection would be ideal, but if you cannot do that, all hope is not lost. You can try the following tools that simulate slower connection speeds on a single box:Please share your own favorite tools in the comments. Each of these tools is super easy to install and setup options to simulate slower connections. However, they each have some caveats that you need to keep in mind.

Firefox Throttle hooks into the WinSock API to limit bandwidth and avoids using proxy settings. (If you use it, be sure to disable "burst-mode".) Right now, Firefox Throttle only limits bandwidth. That means it controls how much data arrives in a given time period after the first bits arrive. It does not limit latency. Latency controls how long it takes packets to travel to and from the server. See Wikipedia's Relationship between latency and throughput for more details. For certain webpages, latency can make up a large part of the overall load time. The next Firefox Throttle release is expected to include latency delays and other webmaster friendly features to simulate slower, less-reliable connections. With these enhancements, Firefox Throttle will be an easy recommendation.

Fiddler and Charles act as proxies, and, as a result they make browsers act rather differently. For instance, IE and Firefox drastically limit the maximum number of connections (IE8 from 60+ to 6 and FF3 from 30 to 8). If you happen to know that all your users go though a proxy anyway, then this will not matter to you. Otherwise, it can mean that web pages load substantially differently.

If you have more time and hardware with which to tinker, you may want to check out tools like dummynet (FreeBSD or Mac OS X), or netem (Linux). They have even more knobs and controls and can be put between the web browser hardware and the serving hardware.

Measurements at each stage of web development can guide performance improvements. Hammerhead combined with a connection simulator like Firefox Throttle can be a great addition to your web development tool chest.