“How can I make sure that data about me stored in blockchains is only accessed by entities I approve of — even though a premise of blockchains is that all participants have access to the blockchain?”
The European Union’s General Data Protection Regulation (GDPR) came into effect on May 25, 2018. It is already clear that the new law, which is in many respects ground-breaking, is struggling to keep up with the pace of technological change. If this issue is not addressed, the GDPR will undermine citizens’ ability to use blockchain.
The core of the problem is that, in addition to the explicit declaration of the rights of the data subject (access to data, data portability, right to erasure, right to correction etc.), the GDPR also mandates that data controllers and processors abide by the principle of “data protection by design and default”. This means designing services and software with privacy as a foundational consideration rather than as an afterthought or add-on. The implied design requirements and goals seem to be at odds with the fundamental ideas behind blockchain and other emerging distributed ledger technologies — in particular transparency, immutability and egalitarian access to the data.
The GDPR applies to the processing of personal data (Art. 2 para. 1 GDPR), that is, any information relating to an identified or — by the use of additional information — identifiable person (Art. 4 para. 1 GDPR). Although the cryptographic identities used by most participants of public permissionless distributed ledger systems are not directly linked to identified natural persons, it is — under certain circumstances — possible to identify participants through additional information (e.g. correlation of the person’s activities with third party data). Therefore, data stored and processed in most public, permissionless blockchain systems should be considered personal data. Little doubt also remains that territorial applicability can also be established for most distributed ledger systems, as they are either (partially) operated from within the EU or are actively used to process data from data subjects located in the EU.
Public, permissionless distributed ledger systems enable their participants to maintain a public database without the need for a trusted central authority or mutual trust. Any participant may enter or leave the system at any time and, therefore, access the data of the ledger at any time. Each participant can freely decide on the if and how of their participation in such systems. The protocol (i.e. the rules the system follows) is defined through the individual participant’s decisions and their decentralized consensus on the global state of the distributed ledger. However, all data processing still takes place in the systems of each participant. The requirements for new data to be included in the distributed ledger are also subject to decentralized consensus. There is an incentive to participate in consensus with the other participants as the other participants would reject transactions of non-compliant participants. Therefore, data processing procedures in such a system are — to a certain degree — specified through decentralized consensus and not governed by any central authority. From a data protection perspective, it is important to understand that the decentralized consensus mechanism requires the participants to be able to mutually validate data stored in the ledger — implying that at least some data needs to be stored unencrypted. Particularly in the Bitcoin or Ethereum system, most transactions between cryptographic identities are immutably stored unencrypted in the blockchain.
This lack of a central governing body (e.g. an identifiable, static set of controllers), as well as the properties of such systems (see above) raise various questions under data protection law and it is unclear how the laws will be enforced in distributed ledger systems. While the European Parliament and Council have begun to adapt to today’s realities of decentralized systems (e.g. The 5th AML directive directly addresses cryptocurrencies), the GDPR does not yet explicitly provide guidelines for decentralized-governed systems. Due to this lack of clear guidance, both from a design and operative perspective, it is unclear how and to what extent participants of such systems have to ensure GDPR compliance — without having to conclude that the only way to comply is to not use these systems at all — resulting in an innovation-hampering de facto ban.
Legislative action seems warranted as only clear design guidelines for the developers of new decentralized ledger systems or developers of applications based on existing ledger systems give them a chance to develop their software in a compliant and privacy-friendly manner (i.e. “Privacy by design” rules for developers). Furthermore, the GDPR neglects the fact that the relationship between participants is not predetermined and can frequently change in most systems. Also, the majority of participants do not know each other and the assignment of responsibilities and relationship, e.g. towards the supervisory authorities is not clearly put forward. Consequently, it is not unlikely that some unexpected participants — private and commercial — could be held liable for violations happening in the underlying ledger system under Art. 83 para. 4 lit. a GDPR. The fines to be paid for such violations are horrendously high: up to 2% of the global annual turnover or 10 million Euro — whichever is greater. Also, from a citizen’s perspective, several blockchain premises and principles of data privacy seem to conflict. These conflicts must be addressed, e.g.:
The outlined lack of legal certainty raises concerns for both data subjects and businesses relying on public distributed ledger systems. This might incentivize businesses to leave EU territory and to relocate to jurisdictions where EU privacy law is virtually unenforceable and therefore potentially harmful to EU citizens in the long term. This is especially disadvantageous as these intermediaries — designing and building distributed ledger ecosystem systems — are the only group potentially capable of implementing an effective regulatory approach and implementing technical solutions to ensure the rights of data subjects.
For these reasons, the GPDR, which was ahead of its time when it was drafted, will now need to be carefully updated and clarified.
Blog by Christian Sillaber, Senior Researcher on IT-Security