You’re an entrepreneur, and you’re designing a business which will use publicly accessible blockchain data to market services in Europe. The new EU data protection regulation is already in place. You know broadly what GDPR is, and you’re aware there’s a lot of wordy articles around about it. You don’t want to read both sides of the story, or how it might look in twenty years. You need to know a little more on what you should do right now.
If this is you, read on.
One of the biggest challenges for new blockchain businesses is adapting to laws constructed in response to a different technological and organizational infrastructure. GDPR came about in a pre-blockchain, siloed world with well-drawn lines between data-controlling organizations and individual people. It doesn’t fit very well with permissionless, public blockchains.
The not so great news is that regulations are going to trail real activity. Blockchain in itself is not considered compliant or non-compliant; the EU will judge applications of the technology on a case-by-case basis. Pioneering blockchain organizations will have to protect themselves as much as possible while operating within these existing legal frameworks before the law catches up with them (in a positive way).
Caveat: I’m not a lawyer, so get yourself one if you’re doing anything that could fall under GDPR.
What is GDPR?
The legislation was put in place to safeguard personal data from misuse. It doesn’t just apply to obviously personal data, either. Any combinations of data that could lead to the identification of real people fall under its jurisdiction. It makes the distinction between three types of data:
Personal — unhashed, human readable, easily linkable to a real human being
Pseudonymous — linkable by educated guesswork, particularly in conjunction with other data)
Anonymous — not linkable to any person, no matter what. More bad news: GDPR might not regard hashed data as anonymous.
The biggest blockchain-relevant thing in GDPR is the definition of roles. It creates a number of them, the most important being that of Data Controller. Now ‘traditionally’ (the GDPR only came into full force on 25th May 2018) this is the organization who owns the siloed database via which the organization creates value. But if this data exists in a permissionless, global blockchain, it’s not at all clear who this is.
In reality, blockchain projects store a small part of their data on blockchain (because of the cost), so these ‘traditional’ GDPR rules will still likely apply to a blockchain startup, and you’ll still need to operate within this system. More importantly, there is also a substantial possibility that the EU will regard you as a data controller for the data your organization places (or facilitates placing) on the blockchain, too.
EU Data Protection Issues
Amongst their various obligations, the blockchain data controller will face difficulty on:
- Immutability — GDPR provides as a right deletion and correction — a blockchain right to be forgotten — but on a public, permissionless blockchain, this is not possible. Indeed, that’s the point.
- Open access — it will be challenging to guarantee anonymity against detective work on large datasets with multiple data points.
- International transfer — GDPR prevents the unnecessary transmission of data outside of the EU, but on most blockchains, there is no ‘international.’
- Information on data processing — under GDPR, individuals can ask who is processing their data, including merely accessing it. On a public blockchain, this is difficult, if not impossible.
So, what can an entrepreneur do to mitigate the risks?
Hashing is your friend. You should not put any unhashed data on a blockchain, full stop. What may seem anonymous in isolation could easily be combined with other data points to build a coherent picture of the underlying identity of a person.
Put as little data as possible on the blockchain to secure your decentralized value proposition. Low blockchain footprint dovetails with keeping costs down, but more importantly, the complexity of managing your off-chain data under GDPR is more manageable.
For practical purposes, there is no such thing as anonymous data, anywhere. It’s likely that GDPR will not consider hashed content to be fully anonymized if even a single means of decryption exists (e.g., a private key). It may be better to hash application state instead of merely individual data points.
Identify throughout the design process where data sits and how you will manage your obligations therein. GDPR stipulates a ‘by design, by default’ approach: protections should not be tacked on as an extra-feature after the bulk of the development.
Do your startup outside of the EU. Find a loosely regulated country somewhere and create the whole thing there. You might find yourself cut off from the EU market at some point in the future, however…