GDPR vs. Blockchain: The Saga Continues

The popular French privacy watchdog, the CNIL, is on fire these days. After being the first EU authority to issue warnings for the GDPR violations to Teemo and Fidzup, it discovers new playgrounds – this time it’s all about matching blockchain technology and the GDPR. With the recently issued official English translation of the recommendation, let’s dive right in.

Data Actors, or Who’s Who in Blockchain
In general, the GDPR talks about the following data actors:

• data subjects – the ones whose data is processed,
• data controllers, who determine how and why this data is processed,
• data processors, who may act on behalf of a data controller in further processing.

In a simplest example, when a user signs up in an app, they submit their data, and thus, they are data subjects. A company that owns this app processes said data, thus, it’s the data controller. And if this data controller at any point outsources the software development to another company giving it an access to personal data, the latter company becomes the data processor.

It doesn’t sound like anything complicated, right? Yet, there are more questions to answer than it might seem.

Data Controllers
First things first, the CNIL, the French independent regulator ensuring data privacy compliance, tries to figure out the status of data controllers in the context of blockchain. Opposing the classical definitive model of governance, blockchain, as a technology, is decentralized in its core. This ultimately creates complications. Who decides the purposes and means of processing in the context of the GDPR, art. 4(7), and thus becomes a data controller? Can there be any data controllers at all since most blockchains do not have any commanding authority in charge? Well, the CNIL is quite sure the answers are not as problematic as they seem at first glance.

In the regulator’s opinion,“participants, who have the right to write on the chain and who decide to send data for validation by the miners, can be considered data controllers.” More specifically, it outlines 2 categories of data controllers:

• a natural person that processes the data in a professional or commercial activity, and
• a legal person that registers personal data in a blockchain.

Of course, it’s not just a theory. For instance, Blocknotary allows a notary public to record a deed in a blockchain, which is a perfect example of a “professional activity” performed by a natural person. The KYC (know-your-customer) platform developed by Crédit Mutuel Arkéa bank and IBM where the bank acts as a data controller for its customers’ personal data, would respectively represent the second category.

So, this categorization for real-life scenarios is relatively easy, or so it seems. An entity that created a private blockchain, just like in the examples above, can be easily defined as data controller. But on the other hand, what about public blockchains? As there is no definite authority or entity, it can be argued that “the user who enters the personal data [in a block] is the Data Controller.” However, it also entails several difficulties, as it is not always possible to clearly define such a user and thus apply regulations accordingly.

Data Processors
The CNIL is also confident about the position of data processors in blockchain. For instance, insurance company AXA has launched Fizzy, an Ethereum smart contract that provides for automatic indemnification for a delayed flight. According to the CNIL, the developer of the software in this case will be considered the data processor, while AXA is the data controller.

The CNIL also addresses the possibility of miners acting as data processors. Generally, miners cannot be recognized as such since they do not have any direct access to the personal data. Usually, it’s the code performing the evaluating functions without any active intervention of miners. To illustrate this situation, the CNIL uses the following example. A couple of insurance companies join a blockchain project allowing them to perform KYC compliance by accessing the customer data of other insurance companies. Here, the CNIL claims one of the companies can be designated as the data controller while others will act as data processors where a necessary contract should be established pursuant to the GDPR, art. 28(3). These other companies will be considered miners due to their validating functions.

At the same time, it is not completely true. In fact, any of these insurance companies can be considered a data controller, processor, and miner at the same time. An insurance company would become a data controller with regard to the personal data of their own customers, whereas being a data processor to the personal data of other insurance companies. And, since each of them would validate transactions, they would also essentially be miners at the same time.

When providing this example the CNIL didn’t take into account that these roles will be mixed in such a relationship. In order to fully understand the position of the data processor, another, more isolated example, should be drawn.

Let’s take an example of AXA insurance and make it a little more diverse. Say, there is a software development company which creates blockchain solutions for others on the basis on their private blockchain. Then, there is AXA that wants a smart contract to be developed for their customer based on this private blockchain. As in the situation before, AXA would be the data controller, and the development company would become the data processor, since it provides a particular solution. So, who can be regarded as miners in this light? Those miners will be other companies and their customers using the same private blockchain solution, who would simply validate transactions of this smart contract without any actual access to personal data.

What about the others?
Furthermore, the CNIL believes miners are neither data controllers, nor data processors. As for the the average cryptocurrency users, like the ones who buy Bitcoin, they would fall under the exemption of “a natural person in the course of a purely personal or household activity,” GDPR, art. 2(2)(c).

In case there is a certain group of participants, the CNIL recommends either to create a legal entity or to appoint one of them as the data controller. Otherwise, the regulator states they could be deemed as joint controllers under the GDPR, art. 26, which would also entail further definition of their respective roles. The clear definition of the data controller in this case would create an anchor for both data subjects and data protection authorities to contact with if necessary.

All in all, the CNIL considers two types of data controllers in a blockchain: a natural person when it is committed to any professional or business activity, and a legal entity. When it comes to data processors, the regulator uses an example of a development company to explain the their stance in data processing. As for the miners, as long as they don’t have access to personal data, they should not be considered data processors.

Think in Advance, or Do You Even Need Blockchain?
Allegedly, blockchain allows for secure data processing due to its suggested immutability. Yet, there are some inconsistencies that can possibly make blockchain and the GDPR incompatible due to the nature of the former.

The CNIL critically reflects on whether data controllers need to implement blockchain tech in the first place considering the privacy-by-design rule, the GDPR, art. 25(1). Basically, it addresses the inherent reliability of a certain technology used to process the personal data. Blockchain may seem to be a reliable tech in this sense, yet the CNIL is not really confident about it:

“Indeed, a blockchain is not necessarily the most suitable technology for all data processing; it can be a source of difficulties for data controllers in terms of compliance with the obligations set out by the GDPR.”

The regulator highlights the inability of data controllers to use appropriate safeguards in public blockchains when it comes to the personal data transfers outside the EU under the GDPR, art. 44. The European Commission is sure to define specific non-EU countries with adequate level of data protection, or other “appropriate safeguards for a transfer outside the EU [that] may be used in a permissioned blockchain, such as standard contractual clauses, binding corporate rules, codes of conduct or even certification mechanisms.” However, the CNIL points out, data controllers are not fully in control of the miner’s location, where the data to be validated may include personal information.

Since it is difficult to ensure proper privacy-by-design compliance in blockchain, a number of questions may arise, in particular regarding the data minimization and retention period.

In short, the data minimization principle says that personal data of processing must be adequate, relevant, and limited to what is necessary; whereas under storage limitation principle the data cannot be stored longer than it’s needed (“retention period”).

The CNIL believes the public keys owned by system participants cannot be minimized further. The retention period in this case is that of the blockchain itself. The question here is, can those be considered as private data at all since they are publicly available and hardly traceable to an individual? Since the GDPR mentions “the means reasonably likely to be used”, it is highly unlikely that a public key can be traced to its owner, thus making it not relevant to the GDPR.

Another issue of data minimization is the payload, or additional data attached to a block that may contain personal information. In order to suit the GDPR, the CNIL recommends to store such data in a form of “commitment”, that is only a proof of the data with the link to the actual data outside of the blockchain. Also, hashing or encryption can be used to provide an adequate level of data protection. Otherwise, the regulator underlines that it is possible to store the data as it is if proper precautions were taken (such as data impact assessment).

All in all, the CNIL suggests that even though blockchain is considered secure in terms of data protection, one should always carefully consider using it. Firstly, following the privacy-by-design rules it is not always possible to have full control over the data outflow, especially in a public blockchain. Secondly, the retention time and data minimization principle should be taken into account. One should always consider the extent of the data they are willing to put into a blockchain, even if the actual data is stored outside this blockchain or encryption is employed.

Effective Exercise of Rights
Probably the most interesting part of the recommendation considers the alignment of blockchain with data subjects rights pursuant to the GDPR §3. CNIL recognizes that blockchain tech “significantly strengthens individuals’ rights” and “facilitate[s] the exercise of individual rights.” However, the regulator also draws a possible map of problematique regarding:

• the right to erasure (dubbed “the right to be forgotten”) — check our earlier feature on the topic,
• the right to rectification (dubbed “the right to correction”), and
• the right to restriction of processing.

Regarding those, the right to correction (GDPR, art. 16) deserves a special attention. It has to face the same challenges as the right to erasure – once the information has been written on a blockchain, it can never be removed. Such impossibility, in the CNIL’s opinion, can be solved by “overwriting” the existing information with the updated one in a new block. Although the original transaction with technically still appear in the blockchain, it will be cancelled with the subsequent one.

To make this possible, an entire chain can be forked, either through a 51% attack, where the majority of miners agree to build a new valid chain, or via a hard fork carried out by the developers. At the same time, such branching will not completely change or delete the data, as it still will be there in the abandoned blocks. Additionally, this creates the threat to the integrity of the entire ledger.

One possible way out to consider is the tokenization of data. CNIL actually proposes this option in a form of commitment when addressing the additional data (payload) regarding the data minimization principle. Essentially, the data itself is not stored on a blockchain. Instead, there are only tokens serving as links to the actual data stored somewhere else. This way, the original source of the personal data can be amended anytime, and the link to it will be permanently stored on the blockchain.

Private chains are a different case. Here, it is assumed that any block can be easily changed if a blockchain is controlled by a private entity. This obviously raises the concern of “defeat[ing] the point of using the blockchain in the first place.” If it so easy to change the private chain, then the immutability of such is very questionable.

Eventually, solving the issue of the right to correction has the same implications as with the right to erasure. The possible solutions to make the implementation of this right possible in a public blockchain is to either fork the chain, or to tokenize the data and store it outside. None of these solutions is perfect enough, as they imply other issues which then still need to be solved.

Conclusions
With the GDPR is still a relatively new regulation, it is difficult to have particular standards on how to apply it in practice. Having blockchain in the background inevitably means that one will have to ensure its compatibility with the GDPR or just forget about the whole decentralized thing.

As we can see, it is still quite troublesome to define who’s who on a blockchain. How to exercise one’s right to be forgotten or to correction is another issue yet to be addressed. Even the actual necessity of using blockchain in certain areas may be questionable.