How do you know that when you pass on your personal data to someone it will be kept secure and only used for the purpose you provided it to? Well, that's a tough question. For that, we have the European Union's privacy legislation, the GDPR. It requires something that is called purpose limitation; meaning, that if you provided personal data to someone, it may only be used for the purpose you allowed and is required. However, that someone might pass on the data to someone else as a part of his service. In that case, he is required to ensure that your data is secure and used only for that purpose. This is made by a Data Processing Agreement, an agreement that is meant to ensure that your rights are enforced by the third party (the one that got the data from the person that got the data from you).
This sound quite simple: If I use a payment service on my website, then that service gets data about my clients. The service signs a DPA ensuring that those persons rights are kept, and all is fine. The problem is, of course, that it is not that simple. The payment service, for example, uses fourth parties; a fraud verification service and an external email service. It signs a DPA with them, and, theoretically, all is fine.
The problem, again, is that those fourth parties might use fifth parties. The email service might use an external hosting solution and analytics services to manage its operation and improve the services.
How are people meant to ensure that their rights are kept? theoretically, they should read the privacy policies. De facto? even if they read the policy, they had to downstream the entire web to understand what happens. This is what I wish to review in this short post.
0 What is the GDPR
For people who have just landed on planet Earth today, you should be aware that around May 2018, Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) came into effect. We'll call it, for the purpose of this post, the GDPR. The GDPR was a new type of legislation. It was meant to ensure that every European national has its data rights, no matter where its data travels to.
The main rights are transparency, consent, legitimacy, review, amendment and deletion. It means that first and foremost, every person should be made aware of how its data is used, and has the right to ensure that the use is solely for his agreed and legitimate purpose. It also means that it can withdraw consent at any time or review and amend data, and in some cases delete the data.
This was a small revolution. As before, consent was not a must. The GDPR changed quite a lot, meaning that if before someone posted some piece of information (let's say, a phone number) on the web, it was free game: anyone could use it. Now? The fact that I posted my number online does not mean that I allow you to use it. It also means that if you do use it, you need to notify me and that you need to use it only for the purpose I provided consent to.
The problem, then, began with the DPA: an agreement meant to govern onward transfer.
1 The DPA, Why Do People Sign It?
The Data Processing Addendum or Data Processing Agreement is an agreement meant to ensure that a third party processes the data in a lawful and legitimate manner. Now, I'll repeat that in English.
A Data Processing Agreement is a somewhat standard agreement meant to ensure that some service that receives your personal data from someone which is not you, uses this data only for the purpose it received it, and doesn't transfer it it others freely.
There are a few good examples of a Data Processing Agreement that you can find online if you need, but they usually say something like: the data processor (the person that receives the data) will only use it for the purposes that it received it.
Then, begins the full saga. In some cases, the Data Processor needs to use Subprocessor. A Subprocessor is someone that gets data from that "third party". For example, If I have an online shop, and I have a payment service to process payment, and that payment service hosts its data on Amazon. In that case, Amazon is a fourth party, and a data processor by itself.
Now, let's assume that you're only buying something online. How many third parties are there? Well, almost infinity. But I'll explain: you pay with a credit card, that uses a fraud prevention service and a host service. Then, when the package is shipped, a shipping company receives your personal data. They use a custom agent and a local courier. Each of these has a separate CRM for managing their business relations, and has external contractors for providing a part of the service, and this goes on and on.
So, theoretically, people just sign these DPAs blindly without going into recursion. They assume that merely executing a data processing agreement will be sufficient to show that they complied with the GDPR. The problem? of course, is that no one planned to abide or comply, they just created long texts to make lawyers richer.
2 No One Actually Plans To Abide
Here's the problem: no one really changed their data architecture or structure following the GDPR. It's not like that some email service or hosting solution went and re-programmed all their systems to comply with the new laws. What they did is create paperwork.
Instead of going on and limiting the use of personal data, companies said: "well, we'll ask our lawyers to create long texts that no one will read, and they will agree that we can keep on doing what we did". So basically the GDPR created more work for lawyers, and not for programmers; privacy was not increased, and the DPA became a farce. Why?
So, Uber took the "categories" literally, and instead of listing the full identity, just listed the types of entities that will receive personal data. It is quite common, but it is not the spirit of transparency by the GDPR. Why? because a part of the GDPR allows people to lodge complaints or review their data independently, and to be aware of who is specifically processing their data. But Uber is, of course, just an example.
Uber, now, has onward recipients. These recipients should execute a DPA with Uber and should restrict data use. How do they restrict? well, without knowing the specific recipients it is hard to so, but let's see how other companies do this.
3 The DPA has Subprocessors Too.
So, let's assume for this case that Uber uses MailChimp, a known email service, to send emails to its clients. What will happen in this case? Uber and Mailchimp will execute this DPA which says that: "Accordingly, data exporter provides a general consent to data importer, pursuant to Clause 11 of these Clauses, to engage onward subprocessors. Such consent is conditional on data importer’s compliance with the requirements set out in Section 3 (Sub-processing) of the DPA". Meaning, Uber allows MailChimp to process information by other, unidentified, parties.
Is this the case for transparency? Not really. I am quite certain that neither Uber nor MailChimp will know or agree to a blanket list of subprocessers if it were their own personal and confidential data. This is why other parties have better and extensive lists. But the fact is, that even reading lists made by good processors are problematic.
But that's not all.
4 DPAs Are a Part Of The Problem, Not The Solution.
I believe that Data Processing Agreements are part of the problem, not the solution. Why? Well, the GDPR acknowledges the existence of DPAs as the basis for ownard transfer (Article 46 to the GDPR ). But it means that you can have a recursive consent method or that no one actually checks whether you need to transfer this data. No one has a full, recursive, list of all data processors and no theoretical entity may create this list without reviewing the source code for a company.
Executing a DPA is only the last step in a commercial negotiation with a service. Only after you checked that you actually need to use it, that you checked that you transfer as little data as possible, that you checked that you cannot perform this locally, then you start by verifying. You also need to ensure that your subprocessor only transfers onward as little information as needed, and does it in a transparent list. Theoretically, you should have a full tree with last mile locations, mapping where personal data travels to, under what conditions and which types of data. The problem is, of course, that this takes time from engineers and not lawyers.