Blockchain vs. GDPR

Bad news: there are fundamental conflicts between blockchain, at least in its original form, and data privacy regulations like GDPR. Good news: these conflicts provide a good opportunity to learn about what is actually contained in both.

The core property of blockchain that is novel and has been important for non-scam applications is immutability. If you have a network that is working properly, a bit of information you put on the blockchain will stay there unchanged. You will not be able to take it back, and no one else will be able to tamper with it either. This was important for the prototypical blockchain application, cryptocurrency, as it was necessary to hold people’s feet to the fire regarding their transactions - if I can change or retract what I put on the blockchain, I can undo my spending after I have run off with the goods and then double-spend my coins.

A few newer brands of blockchain (EOS comes to mind) have methods for retracting transactions, but these are controversial. For human and technical reasons, take-backsies on blockchain transactions may always range from slow and difficult to impossible.

On the GDPR side, a key privacy provision is the right to be forgotten - you can write to Google or Facebook and tell them to delete all the information they have about you. This clause has proven influential and has been incorporated into newer laws like California’s CCPA, and it will likely be imitated again in the future. From a concrete information technology standpoint, forgetting someone means going into your database to delete all the records related to them and their relationship with your business. A blockchain is really just an immutable database, so if you are using a blockchain in your technology stack right to be forgotten vs. immutability is a real headache. Immutability is explicitly a “real pain-in-the-ass to delete things” property, and this is a problem if you are legally required to delete things on request.

There are some things that can be done to mitigate these problems but at the end of the day it is actually the essential, novel property of blockchains that is the problem.

Data privacy regulations past and future: GDPR, CCPA, and beyond

What will data privacy regulations look like a few years down the line? There is much insight in examining the history of data privacy regulations so far and the role that geopolitical boundaries have played in that history. The big questions revolve around how data is shared over the internet and this sharing easily crosses national boundaries, and any data privacy regulation inevitably affects companies outside normal jurisdiction of the country passing the law. Economies of scale in information technology in turn make it inexpensive to obey a law uniformly, even in interactions with customers not covered by the law. This has created strong incentives to model their regulations on the more strict of those regulations already out there - an emerging and strong continuity trend. On the other hand, there are many regulators who are just getting started - legislators in several US states, for example, and the potential for regulatory complexity and headache to pile up is there even if each law closely (but not totally) resembles those which have come before.

GDPR and CCPA are the prototypical example. The United States has trailed behind Europe in interest in data privacy and GDPR was the first exposure of many American companies to vigorous data privacy regulation. A company with a web store, for example, previously might have customers from all over the world with little need to discriminate, but post-GDPR the data of the European nationals is regulated differently and requires new care. Invariably, the IT systems required for this care can be applied to all customers without much additional marginal cost, and this is one reason that CCPA was constructed in the model of GDPR. Businesses often see incentives to apply the sternest standard uniformly, so a natural legislative model that serves both businesses and consumers is to closely mimic the most demanding laws out there so far.

CCPA is also an example in the other direction, in that it introduces new wrinkles that will be a headache for some businesses. It specifically protects data on households, for example, rather GDPR’s explicit emphasis on individual data. It targets only firms based in California, yet given the influence of California firms on information technology it is still likely to have cross-border impact in ways that are yet to be seen.

A look backward at the road to GDPR in Europe can provide some insight into how data privacy might play out in the U.S. as more states contemplate data privacy regulations. Germany, for example, has a much longer history of data privacy regulation going back to 1990, and the development of GDPR embodies the same continuity vs. conflict narrative. Each new piece of legislation keeps much of what before, yet also introduces new conflicts while reconciling old ones. This dynamic continues to this day as firms and national governments continue to work out the contradictions in national v. international laws and regulatory powers.

The United States has no national data privacy law, in effect or in the works, but many states are considering such laws. A national law, presuming one comes, will be in response to and in continuation of actions taken by the states. Hawaii is considering a law with no legal definition of a “business” from a data standpoint, another in Massachusetts is heavily focused on biometric information, while several others aspire to tweak the relatively well-known and popular “right to be forgotten” provision. All borrow heavily from CCPA.

The U.S. national data privacy law will be defined again by continuity vs. conflict, perhaps coming early to correct a burdensome mess of disagreement among state laws or coming late to formalize a de facto international law created by continuity between German federal data privacy, GDPR, CCPA, and then a panoply of states.