Interesting stuff from around the web 2009-01-25

I'm going to be a daddy -- w00t!

Some nice publicity for the BBC music site

BBC’s Semantic Music Project [ReadWriteWeb]
“As more projects like this take advantage of the publicly available metadata available, the beginnings of a real semantic web can finally take root.” What a nice thing to say.

BBC Artists: Getting down with semantic Web [CNET UK]
BBC’s new music site gets a great write up on cnet. But why is it that there appears to be an inverse relationship between distance from the team and an understand of the project’s importance and benefit?

More good news…

Twitter can has OAuth? []
Twitter API lead Alex Payne announced today that Twitter is now accepting applications to its OAuth private beta, making good on the promises he made on the Twitter API mailing list and had repeated on the January 8 Citizen Garden podcast.

Obama’s agenda for technology []
“Protect the Openness of the Internet: Support the principle of network neutrality to preserve the benefits of open competition on the Internet.” I find the face that this is his first agenda point in “ensuring the full and free exchange if ideas through an open Internet and Diverse Media Outlets” surprising (for a politician) but truly wonderful.


Harder, better, faster, stronger [digital urban]
“David Hubert wanted to make a video of London but I didn’t have a camcorder, so he took pictures instead. In fact he took more then 3000 pictures and put them all together into a video lasting less then 2 minutes with excellent result”

Identity, relationships and why OAuth and OpenID matter

Twitter hasn’t had a good start to 2009, it was hacked via a phishing scam and then there were concerns that your passwords were up for sale and that’s not a good thing; except there may be a silver lining to Twitter’s cloud because it has also reopened the password anti-pattern debate and the use of OAuth as a solution to the problem. Indeed it does now looks like Twitter will be implementing OAuth as a result. W00t!

touch by Meredith Farmer (Flickr). Some rights reserved.
Day 68 :: touch by Meredith Farmer (Flickr). Some rights reserved.

However, while it is great news that Twitter will be implementing OAuth soon, they haven’t yet and there are plenty of other services that don’t use it, it’s therefore worth pausing for a moment to consider how we’ve got here and what the issues are, because while it will be great — right now — it’s a bit rubbish.

We shouldn’t assume that either Twitter or the developers responsible for the third-party apps (those requesting your credentials) are trying to do anything malicious — far from it — as Chris Messina explains:

The difference between run-of-the-mill phishing and password anti-pattern cases is intent. Most third parties implement the anti-pattern out of necessity, in order to provide an enhanced service. The vast majority don’t do it to be malicious or because they intend to abuse their customers — quite the contrary! However, by accepting and storing customer credentials, these third parties are putting themselves in a potentially untenable situation: servers get hacked, data leaks and sometimes companies — along with their assets — are sold off with untold consequences for the integrity — or safety — of the original customer data.

The folks at Twitter are very aware of the risks associated with their users giving out usernames and passwords. But they also have concerns about the fix:

The downside is that OAuth suffers from many of the frustrating user experience issues and phishing scenarios that OpenID does. The workflow of opening an application, being bounced to your browser, having to login to, approving the application, and then bouncing back is going to be lost on many novice users, or used as a means to phish them. Hopefully in time users will be educated, particularly as OAuth becomes the standard way to do API authentication.

Another downside is that OAuth is a hassle for developers. BasicAuth couldn’t be simpler (heck, it’s got “basic” in the name). OAuth requires a new set of tools. Those tools are currently semi-mature, but again, with time I’m confident they’ll improve. In the meantime, OAuth will greatly increase the barrier to entry for the Twitter API, something I’m not thrilled about.

Alex also points out that OAuth isn’t a magic bullet.

It also doesn’t change the fact that someone could sell OAuth tokens, although OAuth makes it easier to revoke credentials for a single application or site, rather than changing your password, which revokes credentials to all applications.

This doesn’t even begin to address the phishing threat that OAuth encourages – its own “anti-pattern”. Anyone confused about this would do well to read Lachlan Hardy’s blog post about this from earlier in 2008: -fools/.

All these are valid points — and Ben Ward has written an excellent post discussing the UX issues and options associated with OAuth — but it also misses something very important. You can’t store someone’s identity without having a relationship.

Digital identities exist to enable human experiences online and if you store someone’s Identity you have a relationship. So when you force third party apps into collecting usernames, passwords (and any other snippet of someone’s Identity) it forces those users into having a relationship with that company — whether the individual or the company wants it. If you store someones identity you have a relationship with them. 

With technology we tend not to enable trust in the way most people use the term. Trust is based on relationships. In close relationships we make frequent, accurate observations that lead to a better understanding and close relationships, this process however, requires investment and commitment. That said a useful, good relationship provides value for all parties. Jamie Lewis has suggested that there are three types of relationship (on the web):

  1. Custodial Identities — identities are directly maintained by an organisation and a person has a direct relationship with the organisation;
  2. Contextual Identities — third parties are allowed to use some parts of an identity for certain purposes;
  3. Transactional Identities — credentials are passed for a limited time for a specific purpose to a third party.

Of course there are also some parts to identity which are shared and not wholly owned by any one party.

This mirrors how real world identities work. Our banks, employers and governments maintain custodial identities; whereas a pub, validating your age before serving alcohol need only have the yes/no question answered — are you over 18?

Twitter acts as a custodian for part of my online identity and I don’t want third party applications that use the Twitter API to also act as custodians but the lack of OAuth support means that whether I or they like it they have to. They should only have my transactional identity. Forcing them to hold a custodial identity places both parties (me and the service using the Twitter API) at risk and places unnecessary costs on the third party service (whether they realise it or not!).

But, if I’m honest, I don’t really want Twitter to act as Custodian for my Identity either — I would rather they held my Contextual Identity and my OpenID provider provided the Custodial Identity. That way I can pick a provider I trust to provide a secure identity service and then authorise Twitter to use part of my identity for a specific purpose, in this case micro-blogging. Services using the Twitter API then either use a transactional identity or reuse the contextual identity. I can then control my online identity, those organisations that have invested in appropriate security can provide Custodial Identity services and an ecosystem of services can be built on top of that.


Just wanted to correct a couple of mistakes, as pointed out by Chris, below:

1. Twitter was hacked with a dictionary attack against an admin’s account. Not from phishing, and not from a third-party’s database with Twitter credentials.
2. The phishing scam worked because it tricked people into thinking that they received a real email from Twitter.

Neither OpenID nor OAuth would have prevented this (although that not to say Twitter shouldn’t implement OAuth). Sorry about that.

How to help the network effect

Following my recent post considering BBC public value in the online world I was asked to write a piece for the BBC’s internal staff paper ariel. Here it is:

Front cover of ariel
Front cover of ariel

IF YOU READ the BBC’s internet blog you will know that we are considering the use of OpenID, an interesting though widely misunderstood, technology that could benefit everyone using the web by extending the generative nature of the web.

Technologies such as OpenID and it’s sister technology OAuth and, techniques such as Linked Data provide benefits that the BBC should be helping the web at large to adopt.

It might seem a bit geeky and not something that most people get right now, but then almost nobody gets Transport Layer Security either but I’m pleased that hasn’t stopped my bank implementing it; most people don’t understand HTTP but we all use it. The BBC, could help foster the adoption of these technologies for the benefit of the web at large by adopting them, by promoting best practice and by actively engaging in their development.

Tim Berners-Lee, creator of the web, has proposed a set of simple rules ‘to do the web right’ to achieve a semantically interlinked web of resources, accessible to man and machine. These rules are know as Linked Data.

But how does following these principles help the BBC? And how does that help the web at large? How does it add public value? The short answer is it provides a platform that allows others to build upon and provides our audience with a more coherent user experience.

If data is unconnected (as most of is) it is likely that those websites and the journeys across them will be incoherent. The web’s power comes from being interconnected. The value of any piece of content online is greatly enhanced if it is interconnected. This is due to the network effect, the classic example being the telephone. The more people who own a telephone, the more valuable each telephone becomes. Adding a telephone to a network makes every other telephone more useful. Adding semantically meaningful links to the web adds context and allows others to discover more information.

For example, by building and in this fashion the new artist pages will become more useful by being joined to programmes – directly linking artist pages to those episodes that feature that artist. And the network effect goes both ways. Linking artists to programmes makes the programme pages more valuable – because there is more context, more discovery and more serendipity. The network effect really explodes once programmes and music are joined to the rest of the web.

The BBC has a role beyond its business needs because it can help create public value around useful technologies – and around its content for others to benefit.

BBC public value in the online world

The BBC is an interesting organisation – it isn’t motivated by profit and unlike other public service broadcasters, elsewhere in the world, it is very much part of the country’s mainstream broadcast entertainment ecosystem. Indeed Stephen Fry has suggested that this mix of out and out public service broadcasting, more mainstream programming and stuff somewhere in the middle is vital if public service broadcasting is to have meaning. Stephen argues that if you want people to find and value public service programmes, then it needs to be part of a broader entertainment offering.

In the broadcast world the BBC has a clear (albeit, in some quarters, controversial) public service role and a clear and well developed modus operandi. That’s not to say that it might not or indeed should not change, but rather to say that right now the consensus is it’s doing the right thing, in the right way. But in the online space I don’t think things are as clear, even though the public purposes for all platforms are the same, namely:

One reason the Web is different from broadcast media is because it’s so new and so fluid. The web is not yet 20 years old and it is still evolving at a phenomenal rate, both in terms of technologies and in terms of its application. This means that, with the web, one needs to deal with both the technology and the content. Treating the two separately or assuming that the platform is sorted – in the way one can do with traditional media – is impossible or at least a foolish mistake.

Clearly, from a content perspective there is much the BBC could and indeed is doing on the web – much as it does in the broadcast space. But because there is something very special about the Web the BBC could also be adding real value over and above its content offering. It seems to me that there are at least two additional, distinct areas where the BBC could add public value. Firstly, through its size, the power of its brand and its non-commercial status, it could help with the adoption of technologies that benefit the Web population at large; and secondly by helping to semantically link up parts of the web.

Last week Zac posted an article about the recent OpenID Foundation Content Provider Advisory Committee which the BBC hosted. Unfortunately OpenID is a widely misunderstood piece of technology, partially I suspect because people have got so use to the email+password per site paradigm, and partially because the name OpenID doesn’t really help people grok what it’s about. But that doesn’t mean that it doesn’t provide real benefit to people using the web.

As I’ve discussed previously emails are for contacting people not for identifying them. Using emails for identification means the affordance is the wrong way round – I can send you an email but I can’t see who you are, what you’ve said about yourself nor who’s in your social graph. In the real world this would be a bit like handing over a scrap of paper with your home address or telephone number on it as a means of identification. You wouldn’t do that, so why do it online?

As Zac points out, OpenID has yet to hit the mainstream – it’s still the preserve of Generation @. But if, as I do, you believe that technologies such as OpenID and OAuth provide genuine end user benefits then it is something that the BBC should be helping everyone else to adopt.

Sure it might seem a bit geeky and not something that most people get right now but then almost nobody gets transport layer security either but I’m pleased it hasn’t stop my bank implementing it; most people don’t understand HTTP but we all use it. The BBC, could help foster the adoption of these technologies for the benefit of the web at large by, for example, adopting these technologies itself, by promoting best practice and by actively engaging in their development.

Tim Berners-Lee has put forward four simple rules to do the web right:

  • Use URIs to identify things on the web as resources
  • Use HTTP so people can dereference them
  • Provide information about the resource when it is dereferenced
  • Include onward links so people can discover more things

If you follow these rules what you get is a highly interlinked web of resources – where each resource is linked to other resources that are contextually/semantically relevant. And if you also provide those resources in machine readable formats (as we have done with programmes and music) then you provide a platform that allows others to reuse your data.

Unfortunately it appears that there is a nasty habit developing on the web whereby websites aren’t doing this and instead are only linking to themselves.

Follow Jay’s link and you come to a story that indeed doesn’t have any outbound links, except to other Times stories. Now, I understand the value of linking to other articles on your own site — everyone does it — but to do so exclusively is a small tear in the fabric of the web, a small tear that will grow much larger if it remains unchecked.

That’s bad for users. But how does following the Linking Open Data principles help the BBC? And more importantly how does that help the web at large? How does it add public value?

If data is unconnected it is very likely that those websites and journeys across the web will be incoherent. The web’s power comes from interconnected data. Publishing a web page or any other piece of content online is useful but if its interconnected with other resources then its value is greatly enhanced. This is due to the Network Effect. The classic example of the Network Effect is the telephone. The more people that own a telephone, the more valuable each telephone is becomes.

One consequence of the network effect is that the addition of a node by one individual indirectly benefits others who are also part of the network, so in the telephone example, adding a telephone to a network makes every other telephones more useful. On the web adding semantically meaningful links adds context to the page you are reading and allows you to discover other resources and read more information about a given subject.

For example, by building and in this fashion our new artist pages will become much more useful by being joined to programmes – directly linking to those programmes that feature that artist. And of course the network effect goes both ways; it goes all ways. Linking artists to programmes also makes the programme pages more valuable – because there is now more context, more discovery and more serendipity. And that’s just within the BBC.

By joining BBC data, in this fashion, with the rest of the web the Network Effect is magnified yet further. That does benefit to the BBC, but it also benefits the web at large and that is important. The BBC has a role that transcends its business needs – it can help create public value around its content for others to benefit from (assuming, of course, there remains one, non-discriminatory, free and open internet).

The mobile computing cloud needs OAuth

As Paul Miller notes Cloud Computing is everywhere – we are pushing more and more data and services into the cloud. Particularly when accessed from mobile devices this creates an incredibly powerful and useful user experience. I love it. The way that I can access all sorts of services from my iPhone means that an already wonderful appliance becomes way more powerful. But not all is well in the land of mobile-cloud computing; a nasty anti-pattern is developing. Thankfully there is a solution and it’s OAuth.

"Mobile phone Zombies" by Edward B. Used under licence.
"Mobile phone Zombies" by Edward B. Used under licence.

So what’s the problem then? Since Apple opened up the iPhone to third party developers we have seen a heap of applications that connect you to your online services – there are apps that let you upload photos to Flickr, post to Twitter, see what’s going on in Facebook land all sorts of stuff. The problem is the way some of them are gaining access to these services by making you enter your credentials in the applications rather than seeking to authorise the application from the service.

Probably the best way to explain what I mean is to look at how it should work. The Pownce app is an example of doing it right as is Mobile Foto – these applications rely on OAuth. This is how it works: rather than entering your user-name and password in the application you are sent over to Safari to log into the website and from there you authorise (via OAuth) the application to do its thing.

This might not sound so great – you could argue that the user experience would be better if you were kept within the application. But that would mean that your login credentials would need to be stored on your ‘phone, and that means that you need to disclose those credentials to a third party (the folks that wrote the app).

By using OAuth you log into Flickr, Pownce etc. and from there authorise the application to user the site – your credentials are kept safe and if your iPhone gets stolen you can visit the site and disable access. Everything is where it should be and that means your login details are safe.

To be fair to the iPhone app developers this type of delegated authorisation isn’t always possible. Twitter, for example, still hasn’t implement OAuth and as a result if you want to use one of the growing number of iPhone Twitter app you need to give up your user-name and password. I find this incredible frustrating – especially from a service like Twitter where (according to Biz Stone, Twitter’s co-founder) “the API… has easily 10 times more traffic than the website“.

URLs aren’t just for web pages

We’re all use to using URLs to point at web pages but we too often forget that they can be use for other things too. They can address any resource and that includes: people, documents, images, services (e.g., “today’s weather report for London”), TV or Radio Programmes in fact any abstract concept or entity that can be identified, named and addressed.

Also, because these resources can have representations which can be processed by machines (through the use of RDF, Microformats, RDFa, etc.), you can do interesting things with that information. Some of the most interesting things you can do happen when URLs identify people.

Currently people are normally identified within web apps by their email address. I guess this sort of makes sense because email addresses are unique, just about everyone has one and it means the website can contact you. But URLs are better. URLs are better because they offer the right affordance.

If you have someone’s URL then you can go to that URL and find out stuff about that person – you can assess their provenience (by reading what they’ve said about themselves, by seeing who’s in their social network via tools such as XFN, FOAF and Google’s Social Graph API), you can also discover how to contact them (or ask permission to do so).

With e-mails the affordance is all the wrong way round – if I have your email address I can send you stuff, but I can’t check to see who you are, or even if it is really you. Email addresses are for contacting people they aren’t identifiers; by conflating the two we’ve gots ourselves into trouble because email addresses aren’t very good at identifying people nor can they be shared publicly without exposing folk to spam and the like.

This is in essence the key advantage offered by OpenID which uses URLs to provide digital identifiers for people. If we then add OAuth into the mix we can do all sorts of clear things.

The OAuth protocol can be used to authenticate any request for information (for example sending the person a message), the owner of the URL/OpenID decides whether or not to grant you that privilege. This means that it doesn’t matter if someone gets hold of an URL identifier – unless the owner grants permission (on a per instance basis) they are useless – this is in contrast to what happens with Email identifiers – once I have it I can use it to contact you whether you like it or not.

Also because I can give any service a list of my friend’s URLs without worrying that their contact details will get stolen I can tip up at any web service and find which of my friends are using it without having to share their contact details. In other words by using URLs to identify people I can share my online relationships without sharing or porting my or my friend’s contact data.

You retain control over your data, but we share the relationships (the edges) within our social graph. And that’s the way it should be, after all that all it needs to be. If I have your URL I can find whatever information (email, home phone number, current location, bank details) you decide you want to make public and I can ask you nicely for more if I need it – using OAuth you can give me permission and revoke it if you want.

Photo: Point!, by a2gemma. Used under licence.