In my recent post on Trusting Functionality I alluded to a socially-based framework for trust that would allow software to be generative and safe at the same time.
When trying to figure out a solution to this problem, I realized that there are already communities on the internet that have built-in social mechanisms for trust. Python, for example, is a language notorious for its lack of protection against untrusted code. Yet we don’t see much concern that a Python script may contain malicious code, even though it has the ability to do whatever it wants to our computer. Why is this?
One obvious answer has to do with the users of Python code: because there’s relatively few of them and they tend to be quite technically skilled, there’s a high risk involved in creating malicious Python code, and little economic gain to be made from it.
But another answer, I think, has something to do with community. A open-source community is a lot like a corporation with a few key differences: its processes are largely transparent, and the software itself is almost guaranteed to be developed by its users. The former allows for peer review and accountability, while the latter helps ensure that the software’s features are always in the best interests of the users. These are pre-existing social mechanisms that help create trust between an open-source community and its stakeholders.
So ultimately, a project’s community can be at least as reliable as a corporate entity: the economic incentive structure of the latter is replaced by a social incentive structure in the former. I trust that the Python SVN repository won’t contain malicious code because I trust the community to only grant commit privileges to those it trusts, and I trust the community’s server administrators to ensure that the python.org domain won’t be hacked.
Another advantage of the transparency of open communities is the fact that—since well before the advent of Facebook and MySpace—they have meaningful social networks embedded in them. One merely has to take a look at the Subversion commit logs for the Python code repository to see who its most highly-respected members are, for instance, and public newsgroups and forums can be mined to discover other relationships. What this means is that it’s possible for us to infer—or be told explicitly—what individuals a community trusts.
So, individuals trust certain open communities and vice versa. This information can be leveraged to create a relatively low-cost web of trust which can be used in a variety of ways.
For instance, let’s assume for a moment that Mozilla’s source control system at hg.mozilla.org supported OpenID and had a simple web API that allowed a remote service to query whether or not a particular user has commit privileges. This would allow Ubiquity’s source control system—which is hosted here on Toolness—to instantly inherit the permission system from Mozilla: anyone trusted enough to have commit privileges to Mozilla’s code repository would instantly be able to commit to Ubiquity. (This is, by the way, the reason that Ubiquity isn’t currently hosted on hg.mozilla.org: it forces us to think of ways to decentralize the Mozilla community.)
There’s at least one existing web of trust that we can draw from, too: the open-source social networking site Ohloh uses a ranking system called Kudos, which could be used as a rough measure of trust, to make inferences about whether an arbitrary piece of code from a known programmer can be trusted.
Such webs of trust would be useful for things other than code, too; it could be used as an alternative to spam-filtering to determine whether content can be trusted. Imagine a workflow in which blog software draws from publicly-available social history to see if a comment posted by an OpenID-logged-in user is spam. This means, for instance, that my Wikipedia history and my Yelp standing could be used to infer that a comment I leave on a blog isn’t spam, obviating the need for frustrating and error-prone captchas.
Inter-community trust doesn’t have to be the only form of trust we use to make our decisions, either; it can easily be used in conjunction with the hierarchical trust system that the web currently uses, for instance; or individual webs of trust can be leveraged from existing social network sites like LinkedIn, as long as the final solution doesn’t inconvenience the end-user.
This is just one potential social solution to the problem of participating in a digital ecosystem with bad actors who have economic incentives to hurt others. If you have any ideas for other solutions to the trust problem, or know of any existing ones, I’d love to hear them.