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.

A Tale of Two Breaches

by Alexander Mueller

Much of our public conversation around cybersecurity and data loss in particular imagines one organization, usually a business, trying to defend its castle full of goodies from the barbarian hackers outside. The reality is that data gets passed around quite a bit, and in 2019 it is lost more often because of mistakes and bad practices around how it was circulated. The public has limited visibility into this circulation, and differences in regulation create drastic differences in who hears about what breach, what firms can be held liable for, and then inevitably in their information security practices and level of care.

On one end of the spectrum, industries without any regulation of their data are almost certainly breached more often than is public and more often than they know themselves. The damage of a breach is typically to consumers and not directly to the company breached, so there is a perverse incentive to avoid discovering breaches if you believe no one else will discover either. This dynamic is particular egregious around data collaboration with business partners - in principle, if I give my data to you and you lose it doing something stupid then I am liable as well, but in practice why does anyone want to maintain a bunch of records about who has what just so they can be a liability in court.

This may sound a bit jaded and conspiratorial, but the reality is that for many breaches no one can even say where the data came from originally. These breaches are also lightly publicized because there isn’t much constructive to say about them. There is this illicitly traded database of information on 200 million Americans with no clear provenance - many believe Experian lost this data originally, but this is disputed and to the knowledge of the author Experian has not been proven liable or held accountable in any way. Databases with huge amounts of personal information are often found derelict in the cloud (often with no password!) by security researchers, and invariably it is impossible to find owners for them. This database of medical information found unprotected is one of many examples.

At the other end of the spectrum, firms holding regulated data are in a really painful position because of the data they must share for unavoidable business needs and the difficulty of ensuring that 100% of their data partners are responsible. Good regulations often require firms to maintain records on to whom data is given (HIPAA requires this for example). It is becoming increasingly burdensome for many firms to find enough responsible partners - the nature of your business requires you to share data with partners and if someone else loses it, you are still liable. Cybersecurity in one organization is hard enough!

A great example from just the past few weeks was the data breach at Quest Diagnostics, or perhaps we should say the breach at AMCA. The first breach of the affair to be announced was at the laboratory testing company Quest, but unmentioned or buried but deep in many articles was that the breach had actually occurred at AMCA, a collections agency Quest employed. Days later, with considerably less publicity, a larger story emerged about the many firms caught up in the breach that centered on AMCA. Yet it will still be true going forward that Quest will get a big share of attention related to the incident as they are the largest firm involved, the most visible, and the one who originally collected the data from consumers.

At one end of the market, more regulation is sorely needed. At the other end, we must confront the unique and subtle challenges of securing data not just in a firm but across an ecosystem of many firms that must share data as an essential part of their operations. At Capnion we believe that emerging technologies like homomorphic encryption and zero-knowledge are a hand-in-glove solution to helping this latter group of firms collaborate - don’t share more than you need, don’t share anything in the clear, set up a system with just enough information in it for your business process and nothing else.