One of the use cases Dave cites (not his, I hasten to add) is the use of mutable blockchains to implement the so-called “right to be forgotten” (RTBF) – or “droit à l’oubli”, as I should perhaps call it while I am still allowed to. That prompted two thoughts which I felt deserved a blog post.

First, a quick swipe at RTBF, a label which has caused more trouble than it deserves, given the merits of the underlying principle. The Google v Spain ruling interpreted RTBF as a requirement for search engines to “de-list” search results that linked Mr Consteja Gonzales, by name, to data about one aspect of his past. The ruling also does not affect search results outside the EU.

That’s a very qualified constraint on people’s ability to find out about what happened. If you search for “Spanish guy bankrupt Google”, you should get the details faster than you can say Streisand Effect. So, as a “right to be forgotten”, this seems somewhat flimsy. And yet, it is the basis of a robust legal judgment – so what did the judges and lawmakers really intend?

One thing the Google v Spain ruling definitely doesn’t try and do is stamp out all the original instances of the data in question: one of the characteristics of the Internet is the ease and speed with which new copies of data can be published and disseminated globally. In that sense, the Internet has made such publication and dissemination almost entirely frictionless. However, readers still need to get to the information in order to read it — and, of course, it follows from the above that there is an ever-increasing mass of information out there to search through.

Seen from that perspective, the Spanish court’s qualified constraints on access to data are best explained as a re-introduction of just some of the friction which the Internet as a whole, and search engines in particular, have removed. RTBF is really “the right to have some information made slightly more inconvenient to retrieve”. Which is so catchy, I can’t really understand why “the right to be forgotten” ever caught on in the first place.

All that said, what I think this shows is that the technical “fix” (redacting the results of some online searches) is a rather clumsy and only partially effective way to achieve the desired social result, which is that the individual’s reputation should not be inappropriately sullied by inaccurate or irrelevant data which happens to be easy to retrieve.

Clumsy or not, I can’t see any sensible way of applying blockchain technology to this problem that makes it any better. In fact, the idea that your Internet search results are based on a cumulatively-signed consensus among, say, the major search engines and the libel courts is mind-boggling, to put it mildly.

Now, on to my second thought.

When I’ve talked about identity and privacy over the past decade or so, I have noted that they are a function of social interaction. Almost exactly three years ago, Vint Cerf observed that he thought privacy was probably an anomaly. I disagreed, and set out some of the reasons why in a blog post which, I think, remains relevant. I don’t think an expectation of privacy is an anomaly, because I don’t think social interaction is an anomaly.

However, to recap briefly from that post: social interaction has some characteristics which it is proving hard to replicate in our technically-mediated online lives. If you live and work in a small village, you might have less expectation of privacy, but since people have to get along with each other in the long term, past indiscretions might be forgiven and forgotten, especially if the individual concerned demonstrates remorse and better behaviour.

Over time, in other words, people develop a reputation, based on one’s past experience of them, the narratives constructed by others, information in the public domain, and so on. And this, I think, is where we come to the point of intersection with the example that Dave Birch cited (and rightly dismissed), about using a mutable blockchain to implement the “right to be forgotten”.

First, I absolutely agree with Dave’s argument that, in the ledger use-case, the way to deal with an incorrect ledger entry is to leave it exactly as it is, and append a corresponding correcting entry when the error is discovered. That way, you balance the books.

But what does “balancing the books” mean, if the blockchain is being used, not for an ledger of accounts, but to record information that contributes (positively or negatively) to an individual’s reputation? What is the right way to correct an entry that is recognised as being wrong? Let’s make it a bit less abstract.

Suppose that the blockchain in question is a record of someone’s ratings as a Seller on an auction site. Most of them are 100% positive, but then there’s one which is dreadful:

“Terrible service; goods arrived late, I was wrongly charged, and the product fell apart. I will never buy from this seller again, and neither should you. 0/5”

Then it turns out that this review was actually meant for another seller.

What’s the right way to make a correction? Is it to go back and delete the entry, or to leave it in place but ensure that it can only be viewed in conjunction with a full retraction and an explanation that it was a review of someone else?

Either way, what do you do about the Seller’s cumulative reputation score? In the ledger example, a correcting entry balances the books – but in this case, a simple correcting entry of 5/5 can’t restore the Seller’s perfect record of 100% satisfaction scores, and 10/5 isn’t a realistic option.

So, the accounting ledger isn’t a useful design template in this case. We’re not looking for a technical solution that balances the books, we’re trying to manage the effect on someone’s reputation of the data that is recorded about them.

Like trust, reputation is something which it’s hard to accrue and easy to forfeit. There’s an asymmetry there, which explains why the “balancing” entry to a reputation-damaging assertion cannot simply be a statement of the opposite.

Is the answer, then, to delete the original entry? Well, that might work in the hypothetical I’ve constructed (where the original entry was simply mistaken); but suppose the original entry was true, and the seller not only rectified the error, but did it so graciously that the customer was delighted. Deleting the truthful original entry, in that case, seems wrong – but neither do we want to leave the possibility that it might be seen and taken as definitive. Is the correct action to ensure that the original review can only be viewed in tandem with updates that explain the subsequent outcome? Here, a “balancing” entry might be part of the answer, but doesn’t seem to be enough on its own.

In other words, just as in the RTBF case, we are trying to replicate several nuanced features of social interaction (reputation, forgiveness, restitution…) using clumsy technical tools which simply don’t fit.

Blockchain might be the best possible technology for implementing crypto-currencies, but be a lousy way to try and build a reputation management system. Blockchain may be a perfectly good hammer, but I wish its fanatics would stop trying to re-cast every online trust problem as a nail.

Post navigation

Search for:

Please note:

This blog contains a mixture of "personal" and "work-related" posts, if you choose to make that distinction. None of the opinions expressed should be taken to represent either the views or policies of my employer.