A ‘GDPR Compliant', In-Built Solution Woven in to the Fabric
With the release of Hyperledger Fabric V1.2, they introduce the concept of private data. Of all the things to solve in the world of technology, the issues surrounding confidentiality and privacy are the most important words coming out of the space.
While professed to be ‘GDPR Compliant', the user is at their discretion as to whether it is in fact compliant.
Private Data and SideDBs on Blockchain? Sounds Counterintuitive
One of the earlier ways that you could ensure some level of confidentiality is through different channels. But while this does offer some scope of privacy, creating a large volume of private channels is generally discouraged on a large network.
Why is that? It's because while it does assure some security, more channels brings more complications such as managing policies, chaincode versioning, and Membership Service Providers. And all of that data would need to be either public and private and transactions between the two would be time-consuming.
This is where private transactions come into the equation, with private data comes the ability to create collections of data but also use policies in order to interdict who has access to this data and who doesn't.
This access can simply be managed by adding policies to the collections. This allows for some data to be public and some to be private for some parties.
Sounds good so far right? Well, this is where the difficulty stems.
Imagine you're shuffling a deck of cards made up of the cards of multiple people, how would you go about remember whos cards are who's?
All of those cards can be free to observe to the public, but for privacy reasons, who owns what can't be made public for privacy reasons. But, for example, if you want to buy one of these cards, you'll need access to this otherwise private data because you intend to buy one, in which case, you'll need to know who the real owner of specific cards are.
In this case, a card auditing system will be a partner in this to check validity. If you’re not using channels, in 1.1, everything you do will be recorded to state of the ledger. This is not GDPR compliant.
Looking at the top example, the ‘Channel Read-Write sets' are what the system looks like currently, with every transaction being recorded in state and history.
What it shows is a private state between two individuals, while the second set (second one down) shows a private state between two peers, divided by their organizations. This state is replicated across these peers according to policies.
By the third state, the power of these transactions become more apparent, with collections being subject to omission by certain members, meaning that seperate private collections for every seller-auditor relation can be made. These collections allow for some data to be added, while the main data is still stored in the main state and ledger.
Only authorized peers can see the hash of data on on the main ledger, with the true data on the private system. Anyone unauthorized will not be able to see it, by comparison, and will only see the hash on the ledger. As a result, they'll never be able to see the information due to hash's being irreversible. Hows does that work? It's resolved through this system:
Where Does GDPR Come Into This?
This Hyperledger Fabric helps to address some of the key problems within the system the prevents it from being fully GDPR compliant.
Any information added to the ledger can't be deleted, this is where GDPR comes in; any personal information added can't be deleted either. One method is to store this data off-chain, but this is an overly-complex solution because you have to look up the validity of the data manually, as well as the links to the data on the blockchain.
Private Data as a Solution?
Private data can be the solution, as it, in a sense, can solve inconsistencies with GDPR. How? It comes back to the phrase ‘you shouldn't have access to data you're not using.
Data and Use Limitation
Private data solves this issue by not controlling access using policies similar to endorsement. By using this logic, we can use operators to define which parties have access.
As for collections of data, you can specify a blockToLive in the policy. This provides you with the data you need for a specified amount of time. This system means that any blocks going unused are purged to save space.
These systems are only GDPR compliant when:
- Parties aren't malicious: This is where the rules in your consortium come in. You need to have clear rules with clear consequences defined to make sure nodes do not get malicious.
- When incorrectly implemented: As previously mentioned in the article, so long as it's implemented properly, then it will be GDPR compliant.