Mistaken Identity

Over the past week, numerous excited stories have covered a talk given by James Pavur, an Oxford University researcher and Rhodes Scholar, at the Blackhat Convention in Las Vegas. With his girlfriend’s consent, Pavur made 150 subject access requests in her name. In what the BBC called a ‘privacy hack’ until they were shamed into changing the headline, some of those that replied failed to carry out some kind of ID check. Pavur’s pitch is that GDPR is inherently flawed, allowing easy access for identity thieves. This idea has already got the IT vendors circling, and outraged GDPR-denier Roslyn Layton used the story to describe GDPR as a “cybersecurity/identity theft nightmare“. Pavur’s slides are available on the Blackhat website, but so is a more detailed whitepaper written by himself and his girlfriend Casey Knerr, and anyone who has pontificated about the pair’s revelations should really take a look at it.

Much has been made of Pavur’s credentials as an Oxford man, but that doesn’t stop the 10 page document containing errors and misconceptions. The authors claim that Marriott and British Airways have already been fined (they haven’t), and that there are only two reasons to refuse a subject access request (ignoring the existence of exemptions in the Data Protection Act 2018). They use ‘information commissioners’ as a term to describe regulators across Europe, and believe that the likely outcome of a controller rejecting a SAR from a suspiciously acting applicant would be ‘prosecution’. In the UK and most if not all EU countries, this is legally impossible. At the end, their standard SAR letter cites the Data Protection Act 1998, despite the fact that in context, any DPA is irrelevant and that particular one was repealed more than a year ago.

Such a list of clangers would be bad (though not necessarily unexpected) in a Register article, but despite presenting their case with a sheen of academic seriousness, Pavur and Knerr have some serious misconceptions about how GDPR works. It supposedly offers “unprecedented control” to the applicant, despite their experiment utilising a right that has existed in the UK since 1984. They claim GDPR represents a “sea change” in the way EU residents can control, restrict and understand the use of their personal information, even though most rights are limited in some way and are rooted firmly in what went before. They claim that “little attention has been paid to the possibility of request abuse”. I’ve been working on Data Protection since the authors were schoolchildren, and I can say for certain that this claim is completely false. SARs being made by third parties, especially with malicious intent, has been a routine concern in the public and private sector for decades. Checking ID is instinctive and routine in many organisations, to the point of being restrictive in some places.

Other assertions suggest a lack of experience of how SARs actually work. Because of the perceived danger of twitchy regulators fining organisations for not immediately answering SARs “it is therefore fairly risky to fail to provide data in response to a SAR, even for a valid purpose”. This year, the ICO has had to enforce on high profile organisations for failing to answer SARs (it didn’t fine any of them), and is itself is happy to refuse SARs it receives from elderly troublemakers. SARs are routinely ignored and refused, but the authors imagine that nobody ever wants to say no for fear of entirely imaginary consequences.

Pavur and Knerr think that panicking controllers will make a mess of the ID check: “we hypothesized that organisations may be tempted to take shortcuts or be distracted by the scope and complexity of the request”. This ignores three factors. First, for many organisations, a SAR is nothing new, and the people dealing with it will have seen hundreds of SARs before. Second, the power advantage is with the controller, often a large organisation ranged against a single applicant (and in the UK, facing a regulator unlikely to act on the basis of one SAR complaint). Third, and most important, they don’t factor in the reality that the ID check takes place *outside* the month. ICO says that until the ID check is made, the request is not valid and the clock is not ticking. A sense of panic when the request arrives – necessary for the authors’ scenario to work – will only be present in those with little experience, and if you’re telling me that people who don’t understand Data Protection tend to cock it up, I have breaking news about where bears shit.

Another unrealistic idea is that by asking whether data has been inadvertently exposed in a breach (a notion written into the template request), the authors make the organisation afraid that the applicant has knowledge of some actual breach. “We hypothesised that such a belief might cause organisations to overlook identity verification abnormalities”. I can’t speak for every organisation, but in my experience, a breach heightens awareness of DP issues. Making the organisation think that the applicant has inside knowledge of a breach will make most people dot every ‘I’ and cross every ‘T’. Equally, by suggesting that ID be checked through the unlikely option of a secure online portal, the authors hope to make the organisation feel they’re running out of options, especially because they think the portal would have to be sourced within a month. Once again, this is the wrong way around. An applicant who wants to have their ID checked via such a method would either get a flat no, or the controller could sort it out first and then have the month to process the request.

A crucial part of the white paper is this statement: “No particularly rigorous methodology was employed to select organisations for this study”. Pavur and Knerr say that the 150 businesses operate mainly in the UK and US, the two countries they’re most familiar with. I’m going to stick my neck out and bet that the majority of the businesses who handed over the data without checking are US-based. Only two of the examples in the paper are definitely UK – a rail operator and a “major UK hotel chain”. Many of the examples are plainly US businesses (they cite them as Fortune 100 companies), and one of the most specific examples of sensitive data that they obtain is a Social Security Number, which must be a US institution of some kind.

If you tell me that a significant number of UK businesses, who have been dealing with SARs since 1984, don’t do proper ID checks, that’s a real concern. If you tell me that it’s mainly US companies, so what? Many US companies reject the application of GDPR out of hand, and I have some sympathy for their position, but it’s ridiculous to expect them to be applying unwelcome foreign legislation effectively. This is the risk that you take when you give your data to a US company that isn’t represented in the UK or EU. Pavur and Knerr haven’t released the names of the organisations that failed to check ID, and until they do, there’s not much in the paper to show that this is a problem in the UK, and a lot to suggest that it’s not.

The potential solutions they come up with are flawed. They say regulators should reassure organisations that they will not be prosecuted if they reject requests without ID, despite no evidence that any regulator says anything different (or indeed, has enforced in such circumstances). Their main recommendation for legislators is recommending that government ID verification schemes should be used by all controllers to check the ID of SAR applicants. It’s true that there is no standardised ID check and controllers will act on a case by case basis, but that’s infinitely preferable to Dominic Cummings’ government knowing every time you exercise your data protection rights.

I have never run a training course that mentions SARs that doesn’t mention checking ID. At least in the UK, a request isn’t seen to be valid unless some form of ID has been presented. In the last month, two different data controllers (the Conservative Party and Trilateral Research) have insisted on seeing a driving license or equivalent before processing my SAR, despite me applying from the email address they have on file. A few US controllers handling SARs in a sloppy manner isn’t a cause for great concern. It certainly doesn’t suggest significant flaws in the way GDPR is drafted.

For all my criticisms of the pair’s approach, they do admit that the white paper was “a cursory assessment”.  I don’t doubt their expertise in security, their good intentions or the truth of their ultimate message: checking ID is essential when dealing with SARs. The problem with the experiment is that it reads like what two clever people reckon subject access is like, rather than how it works in the real world. I’d strongly suggest that if they follow up on this first attempt with a more robust piece of research (which is hinted at in the white paper), they approach the subject with a more realistic and detailed understanding of how Data Protection actually works, and maybe get some advice from people with real SAR experience.

Comments

  1. Excellent, incisive analysis as always, Tim. Well done.

    It’s clear from Pavur and Knerr’s write-up that their experience is in security testing and not data protection. Another giveaway was the repeated references to PII in the slides; PII is the term used in the United States and has a much narrower meaning than the definition of “personal data” under GDPR.

  2. Hi Tim! Great stuff here. You’re spot on about us being security researchers taking a dip into privacy rather than privacy researchers taking a dip into security. Hopefully, the attention this simple case study received will encourage a closer look from real experts, such as yourself, as to why so many organizations will (still?) just give personal data to anyone who asks nicely. I think the media has read the study to argue more aggressively against GDPR than it was intended. Something about the status quo has to change and that probably involves both regulators and companies doing some work.

    Just by way of clarification, I went over our records and slightly more than 1/3rd of the companies which gave out data were UK-headquartered organizations, including one which is in the FTSE-100. Overall, 45% of the organizations which fell for the attack were not US-based. Of the EU-headquartered companies which actually had the subject’s data, 75% of them provided it without adequate verification (and 0% ignored the request). I wouldn’t read too much into those numbers though, since the sample size was pretty small. Still, it wasn’t immediately obvious that European organizations are better in real-world practice at verifying identity so proving that point would likely require a broader and explicitly comparative analysis.

    Since we focused on tech giants and data brokers, there was a pretty heavy US bias. Still, I think the fact that US companies are bad at subject access requests isn’t an unimportant thing to point out – even if it’s obvious to experts like yourself. Many EU residents use US-based products after-all. Anecdotally, many US executives I’ve discussed this research with expressed surprise that this was a possible route for fraud!

    I’ll definitely be adding your blog to the list of things I read though. Really great analysis!

Trackbacks

  1. […] issues with which controllers have wrestled for years, as Tim Turner points out in his excellent blogpost on the subject) might have the effect of controllers becoming even more keen to demand excessive […]

Comment here. Your data will be used solely for the purposes of loading your comment onto the blog, and you can use fake data if you like.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: