Part 1 — A Clash of Titans: GDPR and Blockchain
This post is a first in a series that outlines the steps we’re taking at Flyingcarpet to ensure that we’re compliant with the EU’s GDPR.
Over the last two years, regulatory attention in the blockchain space has overwhelmingly focused on cryptocurrencies. Comparatively little attention has been paid to the relationship between blockchain and data privacy, despite two significant data-related events this year.
The first was the Cambridge Analytica scandal, which gave governments around the world a taste of what can happen should they fail to properly protect their citizens’ data. The second was the passing into effect of the EU’s General Data Protection Regulation (GDPR).
Enter the GDPR
The aim of the GDPR — extending to the individual greater sovereignty over his or her personal data — is noble, but the regulations were very much formulated with centralised, cloud-based networks in mind. As a result, blockchain-based networks are likely to run into the following obstacles when applying the provisions of the GDPR.
- Determining what constitutes personal data on the network.
- Complying with the Article 17 “right to be forgotten”.
- Determining whether network participants are data collectors or data processors or both.
Data processors may face crippling fines of up to €20m or 4% of worldwide turnover for non-compliance. Fears of non-compliance with the GDPR has already led to the Parity ICO Passporting Service shutting down and investors pulling out of several other promising projects.
What is personal data?
Personal data is defined by the GDPR as information pertaining to a “living natural person” (as opposed to a company) that may identify them or lead to their identification. The EU has said that even public keys on a blockchain network constitute personal data because repeated use of a public key can build up a pattern from which the identity of an individual can be ascertained.
The GDPR also clearly states that anonymous data — data that cannot lead to the identification of a data subject — is not personal. As blockchains use anonymising hashing and encryption technologies, it would at first seem that hashed or encrypted on-chain data would be classified as anonymous data for the purposes of the GDPR. Unfortunately, that is not the case.
Since encrypted personally identifiable data can still be viewed by a party that also holds the key or by an expert that devotes enough time and energy towards decrypting it, the EU classifies it as personal data. The EU’s Article 29 Working Party also issued guidance that described hashing as a “pseudonymising” — not “anonymising” — because hashes enable data records to be linked.
Due to this “linkability”, hashes of personally identifiable data constitute personal data, whereas hashed non-personal data, of course, will be considered anonymous. The distinction is ultimately to do with whether the data itself is personal data or not, and not to do with hashing as a technique.
The right to be forgotten
One of the core aspects of GDPR is the data subject’s Article 17 “right to be forgotten”, which enables individuals to request that data collectors “erase” their personal data in particular circumstances. Notably, the GDPR does not actually include a precise definition of what constitutes “erasure” but statements made by the Article 29 Working Party suggest that the threshold is likely to be very high.
However, data on a blockchain is immutable and cannot be deleted in the same way as data on a hard drive or cloud-based network. The closest thing to actual deletion of data on a blockchain network is “burning” an asset by either “forgetting” the associated public key or by assigning the data asset to an address that nobody has the private key to.
This renders the asset non-transferable, since it is essentially impossible for another party to guess the private key of this new unowned public key. In this way, the data subject can have some certainty that new transactions cannot be created with this particular asset, though the record of the past transaction and associated data would still be on the blockchain.
Crucially, the EU has neither confirmed whether “burning” data assets in this way is GDPR-compliant, nor has it even defined “erasure”. Since “burned” data is still stored on-chain, it is highly likely that “burning” assets is not GDPR-compliant and further workarounds are needed.
Categorising network participants
The GDPR distinguishes between data processors — the entities that use personal data for various purposes — and data controllers — who determine what those purposes are and how data shall be processed to achieve them. Both data processors and data controllers must comply with obligations that are set out in the GDPR.
On a blockchain-based network, however, there is often no single authority acting as a centralised data processor that oversees how data is used across the network; in other words, there is not a sole data processor to appoint a sole data controller.
Instead, participants on a network might be best described as being data processors for other participants’ data and ultimately data controllers for their own. This is particularly true of public blockchains, where anyone can access on-chain data or become a node on the network. In a private blockchain, controls can be put in place so that there is control over what permissions participants receive and, therefore, what personal data they can access.
Provided that the private blockchain project clearly delineates the various categories of network participants, each category can be required to agree to a governance agreement that sets out their respective obligations as either data controllers, data processors, or both under the GDPR.
Solutions
The easiest way for blockchain networks to comply with the GDPR is for the EU to write an exception into the legislation, which provides that personal data stored on a blockchain is exempted from parts of the GDPR.
As this is presumably not going to materialise any time soon, developers need to build workarounds. A common workaround is to keep “linkable” personally identifiable data off-chain, and only have the individual’s public key, a hash of their personal data, and a reference to the data on the blockchain. The account would also contain permissions that have been granted to network participants regarding the use of the data, so that only authorised parties can access it.
In this way, all personal data is stored off-chain, which means that it can be deleted in accordance with the GDPR. If this off-chain information is deleted, the hashes and link stored on-chain would be meaningless and would become anonymous data as they would not facilitate the identification of the data subject to whom the off-chain information related to. Furthermore, it would no longer be able to build up a pattern of transactions around the relevant on-chain public key, thereby rendering it anonymous.
However, this workaround also raises further questions. For example, who will operate the off-chain database? How does an off-chain database impact the decentralisation of the project? Who will decide what the governance layer separating on-chain participants and the off-chain database will look like? Will the resulting system be more or less secure than if personal information was simply stored on-chain?
Stay tuned
The next post in this series will detail the processes and controls that we are putting in place at Flyingcarpet to ensure that we are GDPR-compliant and adhere to EU’s concept of “privacy by design”.
