GDPR vs. Blockchain: Technology vs. The Law
blog.trendmicro.com
blog.trendmicro.com
If someone puts "illegal information" directly in your blockchain, you either need a way to roll-back the change (which removes most/all of the benefits of an append-only structure like a blockchain), or you need to be okay with breaking the law.
That someone could be a blackhat that wanted to publish a bunch of personal info, a disgruntled employee, or just regular users if you allow arbitrary input.
I don't know of any kind of real solution, and at some point someone is going to push the limits and make it obvious that "illegal information" is on a blockchain, and we (as society) will have to come up with a way to deal with it.
Blockchains are not inherently immutable or even append-only. What they guarantee (assuming the consensus scheme is working) is that you'll be aware of all the data in the chain or the fact that some of it is missing; the idea that blockchains are inherently immutable is a big misconception that treats blockchains like they're magic.
In a database, if you are forced to delete data, you'll go ahead and delete that data. You's probably also record the fact that you deleted that data in some kind of auditing log to be able to audit compliance with those deletion requests, as well as detect illegitimate deletions.
In a blockchain, you can do the exact same thing, but with better controls: add a block to the blockchain that contains machine-readable instructions telling all nodes processing the blocks to delete the data if they have a copy.
Once every node has done that, even though the blockchain still commits to that data, the data itself is unavailable, thus complying with the requirement to delete it. Essentially we now have a dangling pointer: there will be a digest in the chain, but the data that was hashed to produce the digest is no longer available. The blockchain is of course no longer able to be validated in the same way as before, but what you can validate is the fact that the deletion process was followed properly. E.g. you might have rules that state 2-of-3 senior admins have to use their signing keys to sign off on a deletion request.
A similar example of this principle exists in Git: you can do a shallow checkout that doesn't contain all prior history. Recentish versions of Git handle this quite well: every operation will succeed if it doesn't happen to process the missing history. Similarly, if every git repo is in fact a shallow repo, with some history deleted, that data will gone.
At the low level, this works because practically all blockchains make use of merkle trees. Rather than the hash of a block b_n being calculated as Hash(b_n), you instead have a header that commits to a merkle tree of data items. Thus you can still validate that the headers are connected without actually having all the data (extra credit problem: is this always a good thing?).
1) By "commit", we mean that the blockchain headers contains a hash digest of some other data; the headers are committed to the data they hashed, because if that data was changed the hash digest would change, rendering the headers invalid.
If you are just going to rely on a central authority to say which blocks should be "ignored" (in other words, which hashes should just be trusted), then why use a blockchain at all? It's just a very slow, complicated, expensive append-only log file.
The only benefit a blockchain provides (for the sake of this discussion) is it's ability for someone to verify it without trust from the genesis block all the way to the most current. You take that away, it's not a blockchain anymore.
Even if I ultimately have to kotow to the central authority, I still want to be able to audit what they're doing. Similarly, there is no such thing in the real world as a trusted central authority: the central authorities themselves are groups of people who don't fully trust each other, and thus want to be able to do effective internal auditing.
You're line of argument could also be used to argue that we don't need to audit banks at all.
> It's just a very slow, complicated, expensive append-only log file.
The reason why Bitcoin is slow and expensive is because of the proof-of-work and decentralization, not because of the blockchain itself.
Distributed databases already make use of complicated log files to achieve consensus between nodes and for auditing; adding hashes to the entries in those log files is relatively easy, and as cryptographic hashing is quite fast, doing that doesn't incur much of a performance hit. Most importantly, in a centralized environment, you can fairly easily use standard sharding techniques to make all of this scale well - which is the same way very large databases scale anyway.
A simple list of "data", it's hash, and a counter would be better for what you want in just about every way. You'd still be able to see that data was modified or removed, and it would be faster, simpler, and easier to work with.
>The reason why Bitcoin is slow and expensive is because of the proof-of-work and decentralization, not because of the blockchain itself.
I never said anything about Bitcoin. I'm saying that using a blockchain while throwing out the "chain" part is more complicated, slower, and more expensive than using a simple append-only log file.
We're talking about GDPR here, which is most important in the context of centralized systems whose operators have to worry about compliance with European law; really, it's easier to argue that the fully trustless systems you're imagining - what Bitcoin attempts to be - are what are off topic here.
> A simple list of "data", it's hash, and a counter would be better for what you want in just about every way. You'd still be able to see that data was modified or removed, and it would be faster, simpler, and easier to work with.
If you implement this in a real system, you'll need to rehash all the data any time any of the data is changed. The obvious optimization there is to only hash new data plus a commitment (hash digest) of the old data, at which point you have a blockchain.
> I never said anything about Bitcoin. I'm saying that using a blockchain while throwing out the "chain" part is more complicated, slower, and more expensive than using a simple append-only log file.
How do you know the append-only log file was actually append-only? You'll want redundancy, which means multiple systems must have their own copies of that log file.
Next you'll want auditors to be able to challenge those systems, which is often easiest if you have those systems sign cryptographic statements about what should be in that log file. Real-world systems have log files whose state changes over time, thus you'll want to the chain of blocks optimization so you don't have to re-download and re-hash everything every time the state changes to verify the latest set of signatures for the log file.
And at that point, you have a blockchain whose consensus is defined by a centralized quorum of trusted but auditable entities.
That's the whole goal of blockchains though, don't rely on central systems, banks, authorities, audits, or any control. Like someone has to decide the request to be forgotten is legitimate at some point, and that alone defeats the upside of the blockchain.
> The reason why Bitcoin is slow and expensive is because of the proof-of-work and decentralization, not because of the blockchain itself.
Having the full blockchain history saved vs. only last state saved like regular databases, it's obvious blockchains are more resource intensive.
That's the point of cryptocurrencies; that doesn't mean centralized systems can't use the same technology to achieve their own goals.
> Having the full blockchain history saved vs. only last state saved like regular databases, it's obvious blockchains are more resource intensive.
Depends on how the database is used - lots of databases have usage patterns that are mostly append-only, in which case you're saving the full history anyway. As for the non-append-only parts, such as indexes and running balances, you can always use an architecture where their is either not committed at all in the block headers, or if it is, you just accept that auditors might need to do a bunch of re-computation to precisely check every interm state by replaying the transaction history logs.
Now don't get me wrong: this will incure some performance hit. But with good engineering we're talking about things that are maybe half or a quarter as fast, not fundamental scaling problems. That's the kind of performance hit where just buying more hardware isn't a big deal.
I’m actually surprised that at least publicly this is about as lewd as we got so far https://boobies.surge.sh.
I'm not going to verify this claim, since it'd involve possessing CP, and I'm not touching that.
They maybe can be repaired if you forbid deletion of recent information?
With a block chain you can pay 1 sat (ie less than 1/100 penny) to have your git hash stamped forever into the blockchain. You can then pay nearly nothing to have it safely stored until you need to prove it, at which point you have very, very good evidence to prove you had what you claimed, when you did.
You can also stamp the git hash into your twitter, (you can, as of this writing, delete but not edit tweets), but that assumes you are counting on Twitter to be around 30+ years.
see also: https://www.globalsign.com/en/blog/what-is-timestamping-how-... see also free services: https://stackoverflow.com/questions/25052925/does-anyone-kno...
This problem sometimes comes up in thought experiments, and sometimes involves convoluted solutions such as bouncing signals off of celestial bodies to produce a time delay.
I have never needed to do this. And either way the actual cost for society to do this with blockchains is huge, in energy. You're not paying it, but the cost is there.
Or you could just do it the traditional way: Put it on pastebin. Hell, put it on a couple of cloud services, who will likely have logs about upload times.
Maybe there are cases, where you want to guard yourself against someone reinventing your industry secret and claiming IP theft saying you copied them. It won't help against a patent lawsuit, I'm pretty sure, since you didn't publish. And publishing is the trade you make with society in order to get monopoly for 18-20 years via a patent.
But more importantly: This NEVER needs to be a blockchain. This is not a use for a blockchain. There is nothing chain about it. You just want your blob signed. You could build a service in a weekend that does nothing but sign "I saw the following hash on 2018-05-24: 82390182903120", and run it for no cost (not 0.5% of world electricity). Send your hash to 100 places and boom, done.
1) A blockchain is simply a chain of blocks. The key thing they do is allow auditing mechanisms to be sure they have the complete set of data contained in them. They're really a very simple and useful idea, which unfortunately has been hyped up by a bunch of scammers and semi-scammers. The consensus mechanisms used to secure blockchains are the interesting part, not the blockchains themselves. Although for many applications - Certificate Transparency being one of them - boring old trusted third parties seem to be good enough.
That said, if you have a stronger decentralized chain available too, you can always publish commitments to the state of your centralized chain in the decentralized chain, improving security at relatively little cost. I wrote up a particularly scalable version of that idea here: https://petertodd.org/2017/scalable-single-use-seal-asset-tr...
Only in the sense that "git" also is a blockchain. In other words: nothing relevant to cryptocurrencies, really.
The only thing that's missing from git that makes it not quite a blockchain is that the way we use git doesn't expect there to be a linear series of commits. But with relatively little effort you can add that to git, making a blockchain out of it.
What blockchains do in cryptocurrencies is not magic: they're just the basic auditing mechanism that allows everyone with a full node to verify that all the rules are being followed by parsing all the transactions. The simplest way to do that is with a linear chain of blocks that you validate, starting at block zero.
All the "magic" is in the consensus mechanisms that decide which chain of blocks is in fact the real chain, not the blockchains themselves.
When people talk about blockchains they're not talking about a DAG, even they're related. Playing a semantics game gets us nowhere.
I could try to be more specific and say distributed blockchain every time. But then you'll say oh but git does merging and network, so it's distributed. I'll use a new phrase, and you'll point out that RAM is usually not the same chip as the CPU, so it's distributed, etc… etc…
I'm certainly not saying anything is magic. If anyone says cryptocurrencies are magic or Holy, then it's their proponents.
I'm saying "but why…?" to the explanation, not "what sorcery is this?!".
You might as well say that "algorithms" are used in crimecurrencies, so "you're using the same technology to visit this web site".
In short: By no meaningful definition has blockchains come up with a use case.
A plain merkle-tree or merkle-list. Such technology has been around for a while before "blockchain" was such a hyped technology.
Git is a blockchain that has none of the usual problems of blockchains since the arbiter is a human and they can do as they please. Argreement between humans is a social procedure.
> GDPR does not prohibit blockchain, but it does put some procedural requirements around blockchain’s use in commercial enterprises. For individuals who opt into a blockchain, there is no authority to amend or correct a block once it is incorporated into the chain. For them, caveat emptor. For organizations, make sure you have a mechanism that will allow you to disassociate an individual with their blockchain contributions
> Personal data that has been de-identified, encrypted or pseudonymised but can be used to re-identify a person remains personal data and falls within the scope of the law.
Solution:
> Personal data that has been rendered anonymous in such a way that the individual is not or no longer identifiable is no longer considered personal data. For data to be truly anonymised, the anonymisation must be irreversible.
Source: https://ec.europa.eu/info/law/law-topic/data-protection/refo...
And even that is only the case if it's an enterprise holding the PII; if it's out there in the world in a P2P context then the law recognizes that nothing can be done about it.
I'd argue that you're still identifiable if this pointer can be converted to your PII. Even if you point to someone elses database, as long as it's not been scrubbed.
Again, IP address is PII even though I don't have address-to-human mappings. My understanding is that this is because their ISP does.
Maybe somewhere the word "identifiable" is defined in the legal context?
In any case we agree that whatever it means, it will not allow me to outsource PII-storage to China, and have mere random "handles" in their database, right? Because then the law is completely void through a loophole.
If there's another copy of the PII somewhere, then you haven't deleted it. If the PII was actually public on a P2P network, instead of held by a company, then they're saying the law doesn't apply.
That means that the transaction log has information about me, that is not anonymized. Thanks to this reference log you can see my purchase patterns.
And isn't "a database of people's purchase patterns" the exact thing GDPR is meant to control?
Does this now mean that github is in violation of the GDPR, since they cannot retroactively delete people's personal information?
But you can do it. You can disrupt people, but shrug. You do the same thing in git to remove copyrighted content from your repo. You can't tell The Law (copyright law and/or GDPR) that "sorry, can't do it because that'd be inconvenient to people".
The problem is that if you do it to bitcoin it breaks.
> Does this now mean that github is in violation of the GDPR, since they cannot retroactively delete people's personal information?
Sure they can.
First of all github may not be the legal "owner" (I forget the term), the user is. Second, if github were told by a court to remove the content, of course they can.
This is even scalable, to github:
"Hello N. N. Due to GDPR request XYZ your repo A is in shallow-clone mode until you remove Y piece of PII. Click here to automatically git-filter-branch."
To say they can't remove it is like saying you cannot remove PII because your business's domain name is TheresaMayIsABigFatTurd.com. That's not going to fly.
If "organizations" and "commercial enterprises" means entities like Goldman Sach's proposed blockchain, or Kodak's cryptocurrency, than the GDPR rules aren't really that radical nor create contradictions of compliance. As the blog says, just use a record id (a db "foreign key" id) instead of storing the raw data directly in the blockchain. The record pointer can either point to real data in a lookup table or point to null. The "erase" only works because the organization controls the "lookup table" that the record ids point to.
Instead of that commercial scenario, what people wonder about are the public blockchains such as Bitcoin and Ethereum. Has there been definitive writing on that subject that concludes GDPR doesn't apply to those? Since there's no central authority in charge of those blockchains, any private data can't be erased as easily.
Bitcoin isn't cash[1] (or money?), so presumably doesn't have financial retention requirements.
But it is data about my behaviour, purchase transactions, donations, interests, etc.
Which is PII.
Which means (to me) like I should be able to demand all transactions related to wallet xyz be purged, not just the "additional data" associated with the transactions.
As we've learned anonymizing data is hard. Even with IP addresses removed people have been identified[2]
[1] https://www.youtube.com/watch?v=p9HH_dFcoLc and other references and actual court decisions saying it's not money.
[2] I think it's this one I'm thinking of: https://arstechnica.com/tech-policy/2009/09/your-secrets-liv...
If GDPR applies to Bitcoin, _who_ would you demand the purge action from?
There are an estimated ~10000 pseudoanonymous Bitcoin full nodes[1] all updating a ~170 GB append-only database[2].
Where does the GDPR compliance demand get sent? To the bitcoin user forum where some (not all) the developers hang out? Or to the maintainer of the github repo for C++ bitcoin client? What would be the procedure? Make those 10,000 nodes update and download new client software that "forks" the blockchain for each GDPR erasure request? Why would Chinese miners care about compliance with EU laws like GDPR?
Any company that operates under jurisdiction of the GDPR and runs blockchain nodes?
If they are unable to comply then they shouldn't run nodes.
I don't see why they should be allowed to circumvent the law because they have "algorithms" or because untraceable parties or parties in other jurisdictions don't have to comply.
Every few months some clever programmer thinks they can loophole the legal system with "algorithms." It doesn't work that way.
It's not doable for sure. However, one can argue you can find all the node IPs, subpoena their ISPs, sue every companies and individuals to compliance, jail the ones who don't obey, and blacklist IPs from non cooperative jurisdictions. Fun times.
A good comparison is "the pirate bay" and copyright infringement.
You can't shut down all copyright infringement, but starting a company in 2018 to spread and share other people's copyright is not "a good idea", or at least you know what you'll be getting into.
GDPR, likewise, is meant to stop dealing in other people's PII without consent (and consent can be withdrawn).
When you see "PII", think copyrighted content. You can't say "because algorithms I'm not responsible!".
You're implying that everyone above board will avoid actually hosting the blockchain like the plague, and hand off the actual running to literally criminals (who are avoiding the law by hiding)?
Fair enough. Those "lawful" companies are probably going to have a hard time defending their close relationship with criminals, in courts.
> Where does the GDPR compliance demand get sent?
To anyone with the data. If they're not hosting it, but are able to present it, then get warrants to track down source of data.
> Make those 10,000 nodes update and download new client software that "forks" the blockchain for each GDPR erasure request?
Not the law's problem. Not my problem. Cryptocurrencies don't have a natural right to exist, and in my view they are pure evil.
> Why would Chinese miners care about compliance with EU laws like GDPR?
They wouldn't. CoinBase would be in trouble having to explain why they do PII-laundering for Chinese (by EU) criminal enterprises though.
... and if the EU decides to crackdown on Bitcoin for being GDPR-non-compliant, then legitimate users in the EU will stop using it, but the GDPR really places no restrictions on something that doesn't do business in the EU. Since most coin mining happens in Asia anyway, it's entirely possible the BTC community could respond by just saying "BTC is not certified for use in Europe due to the GDPR." That would weaken BTC's value, but there are a lot of markets out there that aren't under the EU umbrella.
But keep in mind that it also excludes all multinational companies from touching bitcoin.
And if you are touching bitcoin and don't have EU presence, then you can't get EU presence.
Otherwise companies could just go "yeah we have everyone's personal data, but that was done by a previous employee and we fired her, so we don't have to delete it".
- "Are you storing my data?" - "Uhm, technically… I mean it's on our hard drive" - "Delete all my data now. Please and thank you"
1) Sounds great! Hand over all bitcoin control to the Chinese jurisdiction. Problem solved, eh?
2) Hey CoinBase, Merchant X, etc… you are acting as a front to dealing in EU citizens PII, cease and desist with all that.
Given how anti-authoritarian the userbase for most cryptocurrencies is, I wouldn't be surprised if this result is---while not intentional---certainly not something EU regulators would worry too much about.
You can't defend doing bad in the world by saying it's not yet banned everywhere. It's kinda defeatist. We can't allow women to drive because then Saudis will have less incentives to come here to spend their money.
I expect people in the EU still want to make murder illegal even if it "moves it to China"; they don't want it in their backyard.
Did the people of the EU really not want cryptocurrency in their backyard? Maybe they didn't, and this is all working as intended. I'm not sure they intended this side-effect. "Right to be forgotten" may not be something one actually wants to apply to questions like "Where did the mafia get all this money?", even if we want to apply it to other spaces (which is why "follow the money" is so often a useful technique for piercing obfuscatory smokescreens in other data sets).
(Personal bias disclosure: I'm also kind of expecting they're going to find the costs of the GDPR outweigh the benefits in general in the next five to ten years, but I might discover I'm mistaken).
As for questions like "Where did the mafia get all this money from" this is an argument against all cryptocurrencies, and for the financial regulation that is in place.
Financial regulation exists because people want it, for the most part, and either cryptocurrencies should have to abide by them (which includes trackability and reversibility) or it does not (which means GDPR).
I'd argue that no, there is pretty much nobody who wants cryptocurrencies, when they think about how yeah almost all the time financial regulation do benefit the individual.
I'm not saying GDPR is perfect, or even necessarily a step in the right direction. But cryptocurrencies are definitely a step in the wrong direction, going what people want.
Putting medical records into a global public database seems like it would require a more anonymisation work than just redacting the name for it to be acceptable.
Caching is hard, so good luck guaranteeing that.
This seems harder to solve.
Source: https://ec.europa.eu/info/law/law-topic/data-protection/refo...
Source: paragraph 26 http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX...
In an append-only system the enforcement comes from the software running around the data, if you need to you can modify the data in the past, and tell the software to just pretend it wasn't changed. You can't do that with a blockchain without throwing the whole thing away, so it brings into question what happens when legally you MUST remove information.
But even with a blockchain, the solution is the same: build an "escape hatch" into the validation software that allows certain kinds of data modifications and/or deletions to be ignored. The only difference is with a blockchain you'll have stronger guarantees that auditors will be able to detect if that has in fact happened.
It is true that certain types of blockchain cryptographic structures can greatly limit the granularity of those options. But no-one actually uses those types of blockchains (namely chains without per-block merkle trees), so that point is moot.