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.
This made quite a shock. If you recall, your email inbox was filled at the time with services who notified you on updated to their privacy policy. Everyone paid lawyers to create text to generate fake consent and legitimate purposes. Well... not everyone, but you do get the sense. Instead of working to comply with the spirit of the law, meaning: storing as little information as required, getting consent and providing clear and transparent information, and using the data only for the purpose it was given; companies started to juggle legal texts and created different variations.
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?
Well, the GDPR requires transparency. Let's see article 13: "Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information: ... (e) the recipients or categories of recipients of the personal data, if any;". Meaning, that when you ask for personal data from someone, you're required to let him know how its data is shared and with who,. Now, let's see how Uber deals with it in its privacy policy:
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.
Let's assume, now, that Uber uses Twilio, a company that provides text messages and voice authentication. Twilio has a great DPA because it has a reference to a page that shows a list of their subprocessors. Now, this means that (theoretically, not specifically) when you give Uber (or any other service that uses Twilio) your phone number, it sends to to Twilio. How does Twilio use this? Well, it uses another service, called Voicebase. Voicebase has its own privacy policy. It doesn't reference a list of third parties. It just says " VoiceBase works with third party service providers in the U.S. and other jurisdictions to provide website development, hosting, maintenance, transcription, and support as well as other business services for us. To the extent it is necessary for these service providers to complete their work, these third parties may have access to or process Personal Data about you. These disclosures are generally made under terms comparable to this policy, and the recipients are limited to using the information the purpose for which it was provided". Meaning, that even if Twilio was perfect in complying, one of its subprocessors did not, and we have a loose end.
If you want to see someone who performed a great job, you can see SalesForce. Their DPA refers to a full list of subprocessors per service here. But again, recursion is the problem.
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.