Mashoop North!

Paul and I have just presented our ‘lightning talk’ on the use of WordPress MU and Scriblio to create a platform for publishing multiple OPAC catalogues and then exposing the aggregate data as RDF using Triplify. I blogged about this idea a while back and this is the first presentation we’ve given. Not sure what people made of it. Too ambitious? Threatening? Confusing? All I know is that from where I’m standing, it would require a relatively small amount of funding to show it working in principle with a handful of library catalogues. The difficult part would be scaling it to work for 100+ catalogues (though bear in mind, wordpress.com hosts 6 million sites) and satisfying the politics of each institution. Still, that shouldn’t stop us from trying.

Think you know how to use Google Search?

Following yesterday’s post about Google’s 15 second search tips, I thought it would be pretty easy to pull together and develop an on-going series of short tutorials on how to use Google’s search engine. I was also motivated to do this because, co-incidentally, at the Teaching and Learning Symposium yesterday, I attended an elective where the question was asked by a secondary school teacher, “tell me what I can do to help develop my students’ IT skills for when they attend your university.” One of the answers he got was “teach them how to use Google search.”

A lot of time can be spent by both new students and staff, on achieving a basic level of digital literacy. Google’s search engine is a powerful tool disguised by a very simple interface which many of us don’t use to full effect. New features are being added rapidly, too, so I thought a blog which brought together tutorials made by Google and, in time, made by me, might be a useful resource for both staff and students. It’ll also give me the opportunity to learn more about Google’s search engine, which I’m sure I don’t always use to full effect either.

Think you know how to use Google Search? Google Search Tutorials

Facebook’s transparent use of OpenID

There was a bit of excitement last month when Facebook became an OpenID relaying party. Many of the big names such as Yahoo!, Google, MySpace, etc. have long been providers of OpenIDs to their users, but Facebook is now accepting third-party OpenIDs as a way to login to their site. What’s even more unusual and why I’m writing this post is that it wasn’t until a couple of days ago that I noticed how they’d implemented OpenID:

Existing and new users can now link their Facebook accounts with their Gmail accounts or with accounts from those OpenID providers that support automatic login. Once a user links his or her account with a Gmail address or an OpenID URL, logs in to that account, then goes to Facebook, that user will already be logged in to Facebook.

I don’t think this brief explanation on the Facebook developer blog does justice to how this works in practice. What it means is that if you link your Facebook account to your OpenID, you will automatically be logged in to Facebook if you are logged into your OpenID provider and visit http://facebook.com On any other OpenID enabled site, you click a button or type your OpenID into a login box and are then logged in to the site you’re visiting.

With Facebook, they’ve done away with the need to enter your OpenID credentials altogether. If you’re logged in to your OpenID provider, pause for three seconds on http://facebook.com and you’ll be automatically logged in. If you log out of Facebook and then visit http://facebook.com, you’ll be automatically logged in again. It doesn’t seem to work if you visit any other Facebook URL.

So, for example, if you link your Google account to your Facebook account and, like many of us, are logged in to Google throughout the day using GMail, Google Reader, Google Docs, Google Calendar, or whatever, you never have to think about logging in to Facebook. It’s the closest to a transparent single-sign-on across consumer/social sites that I can think of.

I exchanged a few comments about this with Paul Walk on Twitter, who is less impressed by this than I am. What if you want to log out of Facebook? Really log out? You’d need to log out of your OpenID provider. What if you want to stay logged in to your OpenID provider but log out of Facebook? Why would you want to do that? For most users, I can’t think of a reason. Occasionally I want to log out of a site and ensure I’m completely logged out because I’m testing something. When that happens, I open a different browser, clear cookies and/or use the private browsing mode in Safari or Chrome. The benefits to Facebook’s approach seem to outweigh the occasions when I’d want to do this.

Other than habit, can you think of a reason why you’d want to log out of Facebook but remain logged into your OpenID provider?

Surely what’s important here is whether you are logged in to the world-wide-web or logged out of the world-wide-web. It would be more secure, surely, to know if you were logged in or logged out rather than whether you were logged in to some sites and logged out of others. If I lock my front door, I know that every room in my house has been secured. I don’t need to lock every room in the house, too. When I unlock my front door, I have the freedom to move around my house. And so do guests. This is where single-sign-on becomes potentially dangerous, because it opens up multiple services that have been otherwise protected by multiple authentication credentials. If someone else uses your browser, they have access to all your accounts. That could be useful when you and your partner share accounts on some websites, but dangerous if you leave your PC unattended or have your laptop stolen from a public library.

However, I imagine that most people on the web are using one or two weak passwords across the web services they use because they can’t remember multiple login details. Surely one good password to protect multiple accounts which is used to log in and out of multiple services is better than one or two weak passwords that are used everywhere? If I have one ‘key’ that works everywhere, I’m more likely to get into the habit of using it than I am if I have to remember to log out of multiple sites.

I know of three important blog posts about Facebook’s use of OpenID, two from Luke Shepard, the principle developer of OpenID on Facebook and another from Simon Willison. A month before Facebook implemented their ‘linked accounts’ feature, Luke Shepard was discussing some ideas about OpenID login on his blog. Now that OpenID login to Facebook has been implemented, he’s been discussing the logout process. Following on from these two posts, Simon Willison provides a key overview to the current implementation in light of the new Facebook username feature:

At any rate, their consumer implementation is fascinating. It’s live right now, even though there’s no OpenID login box anywhere to be seen on the site. Instead, Facebook take advantage of the little known checkid_immediate mode. Once you’ve associated your OpenID with your Facebook account (using the “Linked Accounts” section of the settings pane) Facebook sets a cookie remembering your OpenID provider, which persists even after you log out of Facebook. When you later visit the Facebook homepage, a checkid_immediate request is silently sent to your provider, logging you in automatically if you are already authenticated there.

It’s brilliant (well, I think so), to see how a seemingly minor part of the OpenID specification, can be turned into a significant improvement (well, I think so), to the user experience and signals the way for a transparent single-sign-on experience across the web, using an OpenID provider of your choice. I look forward to the day when I login to my OpenID provider (actually, my browser does that automatically when I start it up), and from then on, I’m transparently logged in to the sites I use across the web, until I log out of my OpenID provider. One day, I’ll log in to my browser and be logged in to all the web services I use. One day, I’ll log out of my browser and be logged out of all the web services I use.