Last updated: 
6 days 3 hours ago
Blog Manager
One of Jisc’s activities is to monitor and, where possible, influence regulatory developments that affect us and our customer universities, colleges and schools as operators of large computer networks. Since Janet and its customer networks are classified by Ofcom as private networks, postings here are likely to concentrate on the regulation of those networks. Postings here are, to the best of our knowledge, accurate on the date they are made, but may well become out of date or unreliable at unpredictable times thereafter. Before taking action that may have legal consequences, you should talk to your own lawyers. NEW: To help navigate the many posts on the General Data Protection Regulation, I've classified them as most relevant to developing a GDPR compliance process, GDPR's effect on specific topics, or how the GDPR is being developed. Or you can just use my free GDPR project plan.

Group administrators:

Portability right: a data protection challenge

Wednesday, April 19, 2017 - 09:42

[Update: Jisc has responded to the Working Party's invitation to comment on these guidelines]

The General Data Protection Regulation contains one new right for individuals – data portability (Article 20). Some commentators have suggested that this is just a digital form of the existing subject access right, but the Article 29 Working Party's new guidance describes something much more radical. Indeed, rather than data protection, the main purpose of the right is described as to "facilitate switching from one service to another, thus enhancing competition between services" (p.4) and "prevent[ing] lock-in" (p.5). This competition law issue is likely to concern only a small minority of vary large data controllers, but the Working Party appear to give it priority over a number of traditional data protection principles: data minimisation, control of personal data, and even security.

The new right entitles data subjects to request that digital personal data they have provided by consent or contract (note, not all the data that would be available under a subject access request) be provided to them or transferred to another data controller of their choice. Any receiving controller must apparently accept all the data, even if it has no use for it (p.10): reversing the usual minimisation rule that controllers should only process data they need. While data protection authorities have, in the past, required data controllers to spend hours redacting information about others before responding to subject access requests, now they "must not take an overly restrictive interpretation of the sentence 'personal data concerning the data subject'" (p.7) and should include information about other individuals involved in transactions or relationships while (somehow) "implement[ing] consent mechanisms for the other data subjects involved" (p.10). Finally, the question "how can portable data be secured?" is only raised on the very last page of the document (p.15).

The Working Party encourage all data controllers to provide "download tools and Application Programming Interfaces" (APIs) to their computer systems, through which individuals can download or transfer their data online. While a very small number of data controllers (for example banks) may already allow users to view their account and transaction details on demand, for most organisations this information will be held on internal databases, securely firewalled off from the internet. Providing internet access into these databases will require a new and significantly more complex security model for these organisations. Each data subject will need their own account on this API; since the vast majority are unlikely to ever use it this will create a large number of idle accounts, likely to have simple or default passwords. Good security practice for many years has been to remove such accounts, not create thousands of new ones. Securely distributing passwords or stronger authentication credentials to all those remote users is another area known in security circles to be hard and error-prone for both organisations and individuals.

Many organisations – from Ashley Madison to TalkTalk – have recently and publicly demonstrated how difficult it is to set up and maintain access to user accounts. And those are large organisations whose core business is providing secure on-line services. Even if a data controller can manage that, there is a global criminal business sector dedicated to persuading users to give up their passwords. At present that is largely funded by stealing credit card and bank account numbers: how much more valuable (and damaging to the individual) would complete transaction histories be?

The competition problem identified by the Working Party seems to concern a very small number of data controllers. Evidence on the exercise of existing data subject rights suggests this one will be used by only a small proportion of data subjects. Data Protection Regulators should think very carefully before encouraging or requiring all the other organisations and individuals to expose themselves to those threats.

Comments

This guidance does not appear to be a very thought out piece of work.  My immediate thought was if our data is held in the cloud by a third party supplier they may a) not willing to pass on the API or b) charge to hand oer the api.  Lets hope that this will only apply to a small group of data controllers and we aren't one of them!!

There's nothing in the current guidance that suggests this would apply only to a subset of data controllers. At present it's anyone who holds personal data on a computer. Reducing that to (at most) those who have an existing business reason (not just a regulatory one) to provide appropriately secured on-line customer access is going to be one of my main recommendations in my consultation response.

Good point about cloud platforms - working out who is responsible for authentication and security of those (the platform provider may well have no way to identify data subjects...) would be a nightmare, creating even more opportunity for things to go wrong :( My Masters thesis on the risks of unauthorised subject access requests is looking very prescient...

Well said, although i do like the intention to guard users and organisations against vendor lock-in and to assist users in a cloud-service exit strategy.

By the way: i do wonder how service providers are managing their obligation to report users on what data they keep on them, any rights to be forgotten/have records deleted on request etc. Based on what i have seen, i expect most organisations still missing a actual working process in making sure any newly created database (including Excel spreadsheets etc ;-)), changing database, changing script that manages how long data is kept etc adheres to the (interpretation of) data privacy (and other) regulations which are evolving at a speed which make it very hard to keep up. For companies having to cope with regulations of many countries and many sectors it is even harder... While i assume the intentions for the regulations are all good, i wonder whether they also are an ever growing barrier for startups and basically are helping the 'big companies' (as they have the scale and resources to best comply).

Thanks. I agree that lock-in may be a problem, but it's a competition law problem. I'd prefer it to be competition regulators who try to fix those. In particular, they only impose additional duties on firms that present a risk to competition, whereas this applies to every Data Controller, from Facebook to your local family-run shop. For the vast majority of DCs this looks to me like a huge data protection/privacy risk, with little or no competition law benefit to justify it.

On the wider GDPR issue, I agree that most organisations are going to have to get to know their personal data a lot better over the next 18 months. There's a blog post suggesting "information lifecycle registers" as a way of doing that: https://community.jisc.ac.uk/blogs/regulatory-developments/article/gdpr-...