The series finale. (previously: intro, part 1 and part 2)
Part 3: Future of Trust: Ponderings on the future of the social web
In parts 1 and 2 we’ve created a pretty sweet hypothetical article recommendation engine based on networks of trust relations.
That was merely an example; almost everything you do on the web involves trust. Consider the following current internet practices that really need some sort of trust web to solve a bunch of defects:
- eBay needs more trust. Not just the general “Can I trust this guy to actually deliver what he’s selling?”, but even simpler, what if you could reduce a buyer/seller’s feedback score to only the feedback given by your trust network?
- Receiving e-mail: What if your spam filter could take into account the trust relation between you and the email sender? A respectable company would be able to get their form emails easily past your spam filter, and any companies that do engage in spam will see real repercussion and cost: Massive loss of trust, undermining any future endeavours. If the trust vectors are interconnected, this loss of trust hurts them on the entire web, not just on email.
- Blog commenting: Almost analogous to receiving email —no more need for akismet. Knowing the trustability of a server operator also helps directly in cutting down on linkjacking and shill blogging (Trust #3 in the reddit/digg/delicious analysis: Can I trust the host of the linked article to be honest is satisfied with such a system!)
You can come up with similarly elegant fixes to just about everything you do on the web.
Trust is universal
The one problem with setting all web services up to work with webs of trust is that it’s annoying to upload your list of friends to all these webservers. Optimally you really want a single site/space/page where you can drop your list of people you trust, and let all other services —your email provider, digg, reddit, del.icio.us, eBay, your blog software, your web browser, your flickr account, etc.— simply read out your trust web from there.
There are 2 separate movements underway to help out in this regard.
Facebook and Open web APIs
A number of disjointed web platforms already are aware of (some of) your web of trust. For example, your average ‘social network’ server (facebook, MySpace, Hyves, etc) knows about your friends, your friends’ friends, etcetera. In theory at least you trust your friends at least somewhat. Facebook has made the bold first move of making it relatively easy to ‘surf’ this network of trust, which should make it possible for other sites to simply glean your trust network from there instead of re-inventing the wheel.
Hopefully other services which have a part of the network of trust relations will open up their services as well. For example, mutual email conversations —you both sending and receiving— is a pretty good indicator of trust. Some crafty database queries on the gmail server could produce a very useful web of trust graph. The blogs you have in your RSS feed are also a (usually) positive reflection on the amount of trust you have for a given user in this case the author/operator of the sites behind those feeds.
Interesting startup idea here - or probably more likely a lucrative opportunity for an existing social network service, like facebook: You leave your username and password details of a number of web services, to get a heuristic attempt at recreating your complete trust web. Because the indicators I named above sometimes might be wrong, this site should also offer a simple way to give someone an explicit positive or negative review.
The biggest challenge here is simply realizing that two accounts on two different web services belong to the same person. Not all web services use email, and most people have more than one e-mail address.
OpenID
The OpenID movement is taking a more distributed approach to the problem. We at Four Starters have written lots about OpenID, but the basic gist is simply the ability to store all the information you usually need to fill in to register at sites (username, password, email, home address, website, thumbnail foto, etcetera) on one server, so that you can then allow other websites to simply ask that server for the information. The ‘OpenID’ server, upon getting a request for any sort of information —including just authenticating that you are you— then asks you to identify yourself. The upshot is that only your OpenID provider even needs to know a password. For all other sites you simply enter your OpenID —which is a URL. Mine is http://reinier.zwitserloot.com/ for example.
The amount of data you can put on the OpenID server is extensible; it doesn’t have to be limited to just the usual name, email, address information. You could stuff your trusted contacts in your OpenID database as well —a list of OpenIDs combined with a trust percentage. This system solves the problem of linking identities that the aggregate existing services plan listed above suffers from.
This is really the solution Dick Hardt seems to be talking about in his world famous Identity 2.0 presentation. I had the good fortune to see an extended and updated version of it live at The Next Web 2007 where he presented.
I’d love to delve deep into what needs to happen to the web to make this solution work, but I couldn’t possibly do as good a job at it as Dick’s presentation, so I will simply suggest you watch it, if you haven’t already.
Maintaining the trust web
As Cristiano wrote yesterday, and as Deborah Schultz talks about in her presentation, there are gradations of friends. There’s a parallel here to trust: There’s also a gradation of trust. Some people I trust almost completely, others I only trust a little bit. Just like friends, these levels are also dynamic —sometimes trust (and friendship) waters down over time, sometimes you make new friends, or learn to trust new people and sometimes someone does something to lose your trust.
Because it’s important to keep your web of trust updated, the idea of letting each site run its own little web of trust doesn’t scale very well. Centralizing your web of trust into a single repository is crucial to making this vision of the web a reality. It also means that this trust relation thing really needs to be a read/write proposal: It must be possible for me, optimally speaking, to very very quickly downgrade or upgrade an individual’s trust percentage in reaction to for example getting screwed on/satisfactorily completing a transaction with someone on eBay. There’s no good reason why OpenID (or the facebook API) can’t be extended in such a way as to make this possible.
While it can be argued that trust is dependent on the type of action. For example I trust my baker to make me a nice pie much more than e.g. some of my friends who can’t cook for beans. I doubt this is needed. After all, I DO trust my friends not to try and saddle me up with a nasty tasting pie I don’t actually want.
Security: Hurdles ahead
Unfortunately it is now time to delve into the issues that will have to be solved before this is going to work.
Primarily, there is identity theft. It’s already a big problem now, but with trust webs, getting your identity jacked is even more of an issue. Lots of spam is already sent from compromised computers. It’s a small leap to go from there to also jacking that user’s OpenID login, so that the spam software can add itself as a trusted resource, or, alternatively, to just identify itself as you. Either way, everyone who trusts the user with a compromised computer now also trusts the spammer. It doesn’t even have to involve keylogging. The world doesn’t change in day, in practice we’ll be stuck with old services using user/pass based login for decades. Random users are very likely to use the same password there as they do for their OpenID provider. In effect we create a single point of failure by centralizing identity in this way.
One solution is to not use a password to identify for OpenID. Instead, use a ‘shape password’ (the act of drawing a little image), or a ‘visual password’ (the act of picking an image or a series of images out of a large set of them). By aggregating all the user/pass stuff into a single page, it is possible to be a little more thorough and intelligent about the way this site verifies your identity. Another option is to use hardware, like a USB key, to serve as authentication device.
Still, none of these solutions are completely impervious to security leaks of some sort. As Bruce Schneier explains, in general security products tend to suck. Designing for failure is going to be necessary.
I don’t really have the answer here, unfortunately. Brighter minds will have to crack this nut.
Going the distance
A couple of web-based services would be made possible with such a centralized web of trust that currently aren’t really feasible. Just to really dig deep into the possibilities, imagine a political system based on this web of trust. Instead of electing a representative based solely on ideas, you elect on trust - basically on the idea that a given individual will be honest and integral about representing you. If a system exists to anonymously inform your representative about your preferences, the representative will then have to filter and interpret the spirit of his constituents’ opinions. Attempts to pander to company lobbyists, or to go too far against the opinions of those who voted such an individual into power should lead to a loss of trust, which will prevent re-election, or, preferably, at some point just means he is ‘fired’ from his job as representative the moment his trust level drops too far.
When I arrived at the venue (Alexandra Palace) I decided to hang out with the regulars like Dan W., Thomas Scott, and Guy West. After defeating Tom in a game of Halo2 on the big screen we were in for a surprise as we heard a bang the size of a bomb. The roof vents opened soon after this and everyone was surprised. What happened? We got struck by lightning!
Unfortunately, the roof vents had opened and couldn’t be closed for a while as no-one seemed to know how. And with thunder comes rain, so we all had to leave the hall before being washed away by rain. We spent a couple of hours in a smaller area of the building before we could move back, but the rest of the day was filled with jokes about the lightning strike. Later on I found out that Alexandra Palace wasn’t hit by lightning since 1920, and last weekend we were hit twice!