Written lovingly by gj on March 19th, 2008.
As Jake has already mentioned, the latest update we rolled out for Tactile CRM included functionality that allows you to import contacts from your Google Address Book. This has been made possible in a secure manner thanks to the release of the new Google Contacts API. The new API allows you to tell Google that you trust us enough to access your data without having to give us your password.
The release of such an API should mean that cases such as that reported by Coding Horror (an application developer was havesting users GMail username and passwords) recently won’t happen again. However, unless users know that giving 3rd parties their passwords isn’t the only option there isn’t going to be a change anytime soon. Facebook still ask for your password rather than using Google’s preferred “AuthSub” method and if such a popular application is working in this way, then there isn’t going to be pressure on anyone else to change how they do things.
This was picked up back on disambiguity in November:
But do we really realise what we’re handing over when we give this log in information away? Do we realise how much we are trusting Facebook, for example, to play nicely with that information? Think of all the email and IM conversations you’ve had that are accessible using these login credentials… now think about the level of security at somewhere like, say, HM Revenue & Customs (where they recently ‘lost’ the personal information of millions of UK taxpayers), and now think whether somewhere like Facebook would have better or worse security… both now, and potentially in the future.
So how long before Facebook joins in and starts, as the author puts it, “Encouraging Responsible Behaviour”? Regardless of how secure Facebook itself might be, by getting people used to handing over such details, they’re not being very responsible. Should Google be more proactive in telling its users that giving away their passwords to anyone, no matter how much they trust them at that moment in time, is a really bad idea when there are alternatives? Will users pay attention if they do?
As web-application developers then, how do we go about making this work?
In Google’s words:
Web applications that need to access Google services protected by a user’s Google account can do so using the Authentication Proxy service. To maintain a high level of security, the proxy interface, called AuthSub, enables the web application to get access without ever handling their users’ account login information.
and a pretty picture:
Thankfully, there are Client Libraries in a number of languages that make this negotiation pretty straightforward. The PHP Client Library is actually the Gdata package from the Zend Framework. We use various components of that elsewhere and we’re pretty familiar with it and so it dropped right in.
Unfortunately, given how recently the Contacts service was announced, there isn’t (yet) a Zend_Gdata_Contacts service but after taking a look at how the code was structured for the other APIs, adding the necessary components for reading the Contacts Feed wasn’t too difficult – credit to whoever developed it for coming up with such a flexible architecture.
The various Google feeds make use of the ATOM protocol but with a number of extensions for the representation of the many properties that make up an ‘entry’ that aren’t part of ATOM itself – things like email addresses and phone-numbers for Contacts; recurrence rules and time zones for Calendar events; and the many free-form attributes that Google Base items can be given.
Within the ZF code each API has a ’service’ class that knows the URL of the feed and which XML namespaces are used inside it and determines what type of Feed is going to be returned. The Feed acts as a collection of Entry objects that are the result of a Query against the service. Each Entry knows about the types of properties that it can contain - a number of “Extensions” that have a number of attributes. It all follows the hierarchy of the XML quite nicely, with each level knowing what to do itself and what to pass up or down the chain.
From a technical point of view, it’s easy enough to make it work but from the user’s point of view it is a little confusing, the context-switch going from the Tactile branding to that of Google is quite jarring and while such transitions are becoming more common, it’s still not mainstream. It’s helping that Banks and credit-card companies have started using 3DAuth that works in a similar way, and OpenID is slowly becoming more popular and so hopefully people will start to appreciate that the extra couple of clicks are worth it for the increased security.
Getting back to the original point, systems such as Google’s AuthSub mean that our customers can give us access to their data without giving us their passwords - they still have to trust us, but they don’t have to trust us quite so much. It’s a shame that the only options they are presented with are ‘Grant’ and ‘Deny’, and that ‘Grant’ gives access to delete and add contacts, as well as just grab the list. It would be nice if there was a little more granularity in what you could grant access to. We’d be content with a ‘Grant Read Only’ option (or ‘Grant’ to a read-only feed), as we have no plans to do anything other than retrieve the list of contacts and put them in the Tactile database.
In an attempt at a conclusion then, AuthSub is a really nice idea but for it to really succeed end-users need to know it exists. Application developers need to be more responsible, and not ask users to hand over login details. The Zend Framework is really quite good and the components really do just drop in to existing setups, give it a try.
