Computer scientist and blockchain researcher Christian Wirth teamed up with legal scholar Michael Kolain to co-found Privacy by Blockchain Design. Christian Wirth has been researching in the blockchain field since 2013, previously working as Senior Blockchain Architect for IBM. Michael Kolain is a Legal Scholar, Author, and Public Speaker focusing on the regulation of new technologies.
Together, they published the paper "Privacy by Blockchain Design" to bring law and computer science closer together to find a common language between both industries with regards to data protection, particularly the European Union General Data Protection Regulation.
The European Union General Data Protection Regulation presents one of the, if not the most advanced, changes in data privacy regulation for the last two decades. Its primary purpose is to define equal data protection laws for all member countries across the European Union and recommends to "translate" those regulations into standardization and certification seals.
We sat down with Christian Wirth to discuss his findings on the intersection of blockchain technology and the European Union General Data Protection Regulation.
There are cultural differences in the perception of protecting personal data.
Firstly, we have at least a global problem, in which different cultures and different regions have a different perception of what personal data is and also a different attitude towards it. As far as I understand, the American and maybe even British opinion on the topic is that any kind of data, including personal, is like a resource that is out there to be harvested, like a tree. So, if you own the land the tree grows upon, you have the right to chop it down and use its resources to your benefit.
The European attitude, however, which we see reflected in the GDPR, is strongly influenced by the German and Austrian views on data protection and privacy protection. Most likely, due to recent history in the last century, the latter has built a high awareness of what can go wrong if you have too much public data out there and when everything is common knowledge. Europeans have seen the potential for abuse of power that comes with collecting copious amounts of sensitive information.
At the moment in Europe, the political and legal trends think along the lines of data ownership in the digital world. Every individual, whenever they generate personal data by living and transporting those facts into the digital world, or at least by reflecting those things that happen in reality into the digital world, are therefore creating data in value. The million-dollar question is: "Who has the right to harness this value of the data? Who has control over it?"
There presents the current international disagreement.
The European perspective towards this conundrum revolves around the data subject. If something concerns my personal data, it's not that I can entirely dictate what should happen with it (there is also the Public Interest which has to be considered); but at least, if my personal rights or my dignity are at risk, or maybe even some value is generated out of this data, then it should be of my concern. Because it's my life that people are actually dealing with, and I should have some type of ownership on this value creation or, at least, say, on how this data is used to create value.
Blockchain, by its nature, can actually give back the power over personal data to us.
The core issue is that the EU GDPR wasn't written with decentralized technologies in mind.
With a focus on increasing privacy and extend data rights for EU residents, the team is trying to understand the legal implications, when processing personal data using modern IT technologies like blockchain, zero-knowledge-proofs, and AI. The problem here is that there are specific difficulties that the GDPR hasn't foreseen, and software developers are unaware of. The GDPR underwriters, though thorough, didn't have technologies like blockchain in mind when they formulated the text.
It seems as if the regulators expected every technology used in modern society would be a centralized or server-client based architecture. In centralized archetypes, you always pinpoint where data-processing is happening.
When dealing with centralized architecture, it is possible to say "there is the controller," "there is the server," and "there that stuff is happening." But when we look at technology with decentralized architecture, actions take place in many different instances. In contrast to a centralized system, everyone is still performing the same actions but is doing so in good faith that the rest of the network is honest. Due to this difference, things get more complicated on a legal as well as a technical level.
Unfortunately, GDPR doesn't pertain to a decentralized framework. Hence, when decentralized applications attempt to preserve privacy and comply with data protection regulations, many issues arise because the legal text states or expects things to be done in an old-fashioned, centralized way, without explicitly stating technologies.
It's difficult to make decentralized applications precisely in the way the GDPR describes how things are to be done. So, when you want to use blockchain and still honor the principles of the GDPR, you have to subsume a legally sophisticated interpretation of the GDPR. Then, assume that it didn't have blockchain technology in mind and see that blockchain technology has potential that we can harness for the better of data protection. And I think this is really the core issue, where our research starts and where we then start to become more concrete in the workings.
Base similarities exist between legal and IT industries. The divide comes from language.
Many problems arise from the divide between the IT language and the legal language. The misunderstanding between leads to distrust and uncertainty when it comes to blockchain and compliance with data protection regulations. This has been a subject of contention for the last two decades. Traditionally, the IT community pushes forward with new advancements, and the law catches up. This setup has a significant impact on society, on how people interact with each other, live together, and the value that people create. This technological and social development in the "deep tech"-scene happens more and more in its own bubble, almost unnoticeable for the legislature, in my personal opinion.
There is a palpable discrepancy, where many lawyers probably still think that there is this "outside world" that they have to regulate and to conceal for the better, in order to protect the people from this environment, where fast-moving corporations with a much higher efficiency ratio, regarding time-to-act at least (maybe not as a whole if you consider the societal value), set the pace. And vice versa, the tech community regularly feels confined by legal regulation, because the latter holds tight to antiquated views of tech when they write new directives. So, it creates an air of uncertainty as to whether courts will approve when you want to do things differently.
Now is the time to grow together as a whole, as the digitalization law industry is inevitable.
We have the technology to build digital contracts. We can apply the same regulations to those digital contracts like the ones we have for paper contracts because they both follow basically the very same ways of thinking.
In both IT and legal thinking, you start with a specific rule set to provide a foundation.
This would be the hardware in IT and the constitution in the legal sphere.
Then, you try to make up rules and build a stack of several components that you build upon each other,
This is represented by software or laws.
Next, you have a certain pattern with which you check if those rules hold up to whatever use case or whatever particular case you throw at the system.
If you run the program by entering data and looking at the result versus meeting in front of a judge, both parties make their cases present the evidence and wait for the ruling.
Base similarities exist between both industries. The biggest hurdle is the willingness and also the realization, by lawyers and computer scientists alike, that they are actually trying to solve very similar problems. They might have a different angle, distinct tools, and alternative approaches, but this is not how it always has to be.
Massive potential lies in the collaboration of both worlds, taking knowledge from both sectors, fusing them together, and developing products and software ideas that generate a lot less friction in the first place. What the world needs are tools that have been thoroughly thought out from both angles, baked into one idea, and manifested in the real world.
Examples of the discrepancies between the IT language and the legal GDPR compliance language
Let's take two examples, the right to erasure, and the definition of a controller. Both terms can mean something very different in the legal sense and in a technical sense.
Right to Erasure:
This is a big issue with blockchains due to their immutability property. When you look at the right to erasure from an IT perspective, the first reaction is to think of how you can adequately erase all data. If you want to do this on a blockchain and the blockchain is immutable, you are going to have a big problem.
From a technical perspective, erasure can be understood differently. It can be simply marking something as "deleted" in the file system but not actually deleting the sectors on the disc where the data is written. In this case, with a special tool, you could restore the data that has been marked as "deleted" because the information is still there. Hence, in order to properly erase and forget data, you need to override all this data with either only zeros or random ones and zeros. Only then do you have the proper deletion. Of course, you could also physically destroy the disc.
But what the law actually implies with regards to the right to erasure is that data should not be publicly available anymore. For example, let's say a homeowner defaulted on their mortgage. If a significant amount of time later (say 10 or 15 years), this person's court judgment appeared as one of the highest-ranking hits on the Google search engine for their name, the court would argue that the public interest to hold this knowledge public does not justify the fact that this information is out there.
The fact that this individual needs protection, and also has the right for things to be forgotten prevail. In such situations, courts ruled that this type of search result be taken out of the Google search index. They would not necessarily require the website which originally hosted this information to delete it. They would just require Google to take the data out of the index so that the public availability isn't the same as it was before. As we see here, the right to erasure has nothing to do with actually deleting the data itself on a disc. This is where erasure in the legal sense and erasure in a technical sense can mean something very different.
Lawyers look to the real-life impact of an action. They are looking at the consequences for people. Lawyers examine whether this is something we would want according to the law, whereas techies look at the deep stack. They see whether something has been technically erased or not. And if not, then they see a problem that they need to solve. But this is where I say that it is not that simple. You need to find a common language! When a lawyer talks about the "right to erasure," one cannot assume that he or she is talking about the very same "erasure" that a computer scientist learned at university, and vice versa.
Controller
Another excellent example of the difference between IT language and legal language is the definition of a controller. For a computer scientist, a controller is usually a part of the stack from a model-view-controller setup. For a lawyer, a controller is a person who is in control and is determining the means of the processing of personal data by using an automated data processing system. In this case, it can happen that they both mean the same thing. But, the meaning can also end up being very different. The first step to understand is for lawyers and computer scientists to become aware of, identify, and reconcile potential misunderstandings.
Cooperation between IT and legal is crucial.
We need more people to show interest in the cooperation of blockchain technology and law. The idea is not entirely revolutionary. We've seen behaviors like this again and again throughout history, and whenever people start collaborating instead of fighting against each other, then things turn out for the better.
It is imperative that when talking with someone from another profession, not to assume their mental rigidity and inflexibility. Both parties would benefit from making each other understand that this is not an argument. We are simply using words differently. The legal community and the tech community have first to work out what we're talking about before we can come to reasonable solutions.
The desire to find a common language for law and computer science inspired our paper "Privacy by Blockchain Design."
The idea of our paper emerged from this very same desire to find a common language and to bring law and computer science closer together, especially with regards to data protection. Legal researcher Michael Kolain and I were looking for a fitting use case where we could begin to develop a methodology on how to better design software and tackle some of those challenges that occur in the whole tension field of LegalTech.
We looked at the consent required when you process personal data and also the formulated requirements regarding that consent according to the law. Then, we took the law itself as the non-functional requirement for the software that we want to develop, instead of a business case or company use case that would have revolved around the intention to be profitable.
We focused on the law's intention to lay the foundation for a peaceful and cooperative society and to set the right incentives as to how people should interact with each other and wanted to start designing software and programs that would reflect this intention. This led us to create design patterns, but we derived those directly from legal specifications that are written down in the law.
Want to learn more?