▲ 161 points
back
69 comments
I found one of the toughest things about GDPR is determining what is or isn't personal data, when dealing with less common types of data.
R6DB for example, a video game stats website, decided to shut down [1] due to unknown territory over whether or not player account IDs and statistics they were scraping from official APIs, are "personal data". (They have now reversed their decision to shut down I believe)
As soon as you leave the classic Website tracking/Product usage categories, the definitions get murkier. If I shoot a GDPR data request to eg. Blizzard, do they have to give me any game/stats history they have on me?
[1] https://medium.com/@r6db/r6db-is-shutting-down-db1b59b031ac
> As soon as you leave the classic Website tracking/Product usage categories, the definitions get murkier. If I shoot a GDPR data request to eg. Blizzard, do they have to give me any game/stats history they have on me?
If they are able to corelate that data back to your account, and you account contains information that allows them to link it back to individual you, then absolutely.
If they keep that information completely anonimized and have properly siloed that data, then they would not.
A good rule of thumb is that if they would be technically able to comply with the request, then they have to comply.
Disclaimer: IANAL but CTO of analytics startup in EU.
What if you don't have the original account's information?
Let's say there's an api on https://example.com/api/v1/users which is world-readable and contains two values: user id and user rank. You scrape all this and put it in your database. I come to you and say "I'm user id 1234 and I want you to delete me from your db". Is this a legitimate request?
This is the situation R6DB is in. Furthermore, in such situations there's a case to be made that this information cannot be deleted if the whole point of the site is to provide global rankings.
It doesn't matter if you can correlate user id and account holder, what matters is that somebody can. That's the same reason why IPs are considered personal information.
>Furthermore, in such situations there's a case to be made that this information cannot be deleted if the whole point of the site is to provide global rankings.
You don't have to delete it, anonymizing is enough. For global rankings you don't need to know that user 1456 has rank 56, you just need to know that somebody holds that rank. So whenever a user requests to be deleted, replace his id with -1 (or choose a random number outside the normal range) and you have satisfied the request (only the PII needs to be deleted, not everything about the user).
Funny thing is that even if you do such request, company refuse and then you make a complaint which for example is thrown out, you still won't know what is the best practice, because there is no such thing as precedent there. Each case is judged individually. Actual compliance depends on particular civil servant's interpretation who is handling a complaint about your company.
The question is, who is the owner of this data? Is it Blizzard or is it R6DB? I would say, the burden is upon Blizzard, so they would be the designated Controller of the data. R6DB would then need to sign a Processor agreement with Blizzard, of which one requirement is to delete certain data upon Blizzard’s request.
R6DB could also position themselves as the controller of this data, but that would put quite a bit of the burden on them.
But this is my interpretation of the situation. Would probably need a more in-depth discussion with both parties to figure out what the intentions are.
what if data is
customer_ID -> address
I can zero in that its someone that lives in that house but not who it is.
What about
customerID -> IpAdress
I can look up ipaddress at a later point to and identify a subset of ppl with that IP.
Whould that be considered personal data.
As soon as you could reasonably pinpoint it to a certain person, it becomes PII. A classic example includes a combination of zipcode, gender and age. While individually they would not be a problem, it’s the combination of these different parameters that allow you to narrow the pool so much it can reasonably assumed to be PII.
>If they are able to corelate that data back to your account, and you account contains information that allows them to link it back to individual you, then absolutely.
It's amazing that people actually think this type of request is reasonable and that a regulation enabling this type of request will not kill Europe's competitiveness wrt internet companies.
I have no idea why you consider it unreasonable that I should be able to request data a company holds on me.
I'm surprised no one has brought this up (yet). GDPR is super expensive to remain compliant, simply because of the broadness of the terms used, leading to undefined scope of liability.
As one other HNer previously mentioned, the cheapest way to stay compliant with GDPR is to completely block access to EU customers. In fact, this is what I did with my business. I redirect to a generic text file (not even a HTML that could trigger a GDPR clause by itself) explaining my stance.
Don't worry about false equivalence that many will raise "So, you don't care about our data HUH?". The intentions behind GDPR may be good. But, the roadmap seems completely stupid. Many think blocking EU customers is an arrogant move. No, it's not. Not everyone has the finance and time to comply with GDPR. A typical re-implementation of our web application will cost us weeks if not months, for example. That could be time spent building features customers want, not fighting some vague elitist law (comply with us or else you're doomed!). If enough business owners block access to EU customers, then, EU will lose a lot of business and that will trigger them to hopefully do something about the vagueness of GDPR. I don't even live in EU, for instance, yet this re-implementation will cost me tens of thousands of dollars (translating my time) that the EU isn't going to pay me for their vagueness.
I've had enough of GDPR. I know many EU HNers will not agree, but please consider putting yourself in a solo founder's shoes.
If you are a solo founder without any business presence in the EU, or clients in the EU, you have nothing to worry about. Blocking EU site visitors is unnecessary, and GDPR covers this in clear language.
What about reimplementing will cost you tens of thousands? That implies you either have a heavy use of personal data without a legitimate interest or have significantly misunderstood the requirements laid out in GDPR.
Let's say I operate a website where you can sign up with an email address, and I'll send you recipes. The recipes call out specific brands of ingredients. The vendors who sell those brands pay me for this service. I and my server are in the USA. Additionally:
1. My food vendors operate (a) all only in the EU; or (b) mostly worldwide, but one operates only in the EU; or (c) all worldwide; or (d) all only in the USA, but an independent third party imports many of their products into the EU.
2. My recipes are for (a) only French food; or (b) all kinds of food.
3. My email includes descriptions of the restaurants that originated the recipes. These restaurants are (a) all in France; or (b) about half in France, half in New Orleans; or (c) all in New Orleans. (New Orleans is an American city with strong French influence on its culture, and a francophone minority.)
4. The recipes are distributed in (a) French only; or (b) English and French; or (c) English only.
5. I advertise my site (a) with a run-of-network ad that shows mostly in the USA, but also on a French newspaper; (b) on a small blog whose American operator doesn't track its audience, but that I've heard is popular in France; (c) not at all, relying on word of mouth.
So I've set out 4×2×3×3×3 = 216 cases. In which of them am I subject to the GDPR? What factors or combinations of factors are determining? If I asked this question of two lawyers, how closely would you expect their answers to agree? What confidence would they express that their answers would agree with the regulator?
I think the people who think GDPR compliance is easy are saying to themselves, "If I behave in accordance with these general principles as I understand them, then the regulator will see me for the good person that I am and I'll be okay". That may be true, but it's not law.
Do you note this somewhere on your sites so that non-EU customers are also aware you're doing this?
While I know you believe that blocking EU customers over GDPR doesn't mean that you don't care about personal data, many of us do feel that way, and I know that I at least would like a way to avoid interacting with such companies in a more convenient way than running everything through an EU-based VPN.
I think Europeans really overestimate how much revenue is derived from European customers. European CPMs are a fraction of American CPMs. Europeans purchase a fraction of the products that Americans do.
This is nonsense. GDPR is cheap to comply with: following best practice, you should easily be able to comply with it.
Here's the question: are you willing to bet 20 million euros on your best practices?
That's the maximum penalty as I understand it: https://gdpr.report/news/2017/06/16/gdpr-guidelines-conseque... - and that doesn't count the cost of litigation before being fined.
This has already been posted in here, but I count GDPR compliance as being able to respond to this: https://www.linkedin.com/pulse/nightmare-letter-subject-acce...
Even if I think I'm completely compliant, I think I'd make the decision to limit it to North America until I had enough revenue to hire a separate data protection officer.
Yup +++
In keeping with game metrics being harder to come by, back in April, Steam changed it's terms for it's API
https://esportsobserver.com/valve-increases-steam-privacy/
https://steamcommunity.com/dev/apiterms
Note the
"You will only retrieve Steam Data about a Steam end user as requested by the end user"
clause. Basically kills any site that had been collecting data for statistics.*
Now this might have been simply due to the Cambridge Analytica backlash, I'd doubt they'd say one way or another. It does seem that datasets like BYU
https://steam.internet.byu.edu/
will be harder to collect in future. Although the GDPR does carve out exceptions for research, if I were a company, I'd be extremely hesitant to work with anyone coming by and saying "Hey, can I have that dataset which you locked down due to GDPR concerns for my 'research'?".
It's sad really, one of the benefits of the Internet was supposed to be it's openness and transparency. Ah well, it was a nice dream for a while.
* I've been trying to confirm that that is the new clause that has been causing problems, but unfortunately, I can't find a historical revision of the Steam API Terms of Use. :( I can only point to articles that say that services are shutting down due to API changes. If anyone can expand on this (or contradict it), I'd be happy :).
What's the general consensus on the last question you raised? Would Blizzard be expected to provide that info? What about "hidden" values like your MMR?
I don't know actually. And lawyers I asked give inconsistent answers. I was planning to make one to Blizzard come 25th just to figure out what their process is.
The toughest part is, the regulation talks about the definition of personal data here: https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A...
‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;
The keyword people like to use is "in context", where data is personally-identifiable if it can be used to identify you in a certain context. This... covers almost everything with a unique=TRUE in a database, and any ranking-type systems such as the excellent example of MMR you gave earlier.
Thanks for posting. This does not look all that different from PCI compliance, though the scope of data involved is larger and as others have observed there's some ambiguity about coverage that will need to be worked out in practice.
Editorially speaking I'm glad to see this emerge even though it means more work for me personally. If anything some of the fines seem too low. (I'm looking at you, Equifax.)
PCI compliance is a lot more annoying than it appears at first.
A business that accepts credit cards can easily end up storing credit card numbers in places they do not intend to. That can happen even if they do all their intentional credit card handling through an outside service that their check out pages post to or AJAX to so in theory no credit card number ever even reaches the business' servers.
For example, customers will email you to tell them that the credit card they pay their subscription with is about to expire, and give their new credit card number and security code in the email (and for good measure often give the old credit card number and security code).
Same for your help desk system, regardless of whether it is based on email or web forms. Customers are going to stick credit card numbers in tickets.
I don't think I've personally seen a customer stick a credit card number in a forum post or in a blog comment, but I wouldn't it past them.
Basically, if customers can put text in it [1], you really have to assume some customer is going to put a credit card into it. I'm not kidding. I've seen credit card numbers show up in name and address fields.
Oh, and when they stick unrequested credit card numbers in emails, support chats, etc., they will often format them in weird ways. If you want to find these you have to make your scripts that search for them quiet lenient in what they accept, but then you get a lot of false positives.
[1] ...or speak into it.
Funny thing is that everything in the Equifax breach (addresses, social security numbers, income) is public information in Sweden and everybody can access it.
Speaking of which, how would the Equifax breach have been affected by GDPR ? My understanding is that they had legitimate reason to request and store that data, and GDPR is not some magic tool that prevents breaches.
I'm just a beginner on the GDPR but here's a few things I got out just of the Everlaw link.
1.) Protect the data with methods corresponding the risk level (Articles 32 and 35)
2.) Enable users to erase, correct, or transfer data at will (Article 15)
3.) Enable users to consent to use of their data in the first place (Article 15)
So yes, it seems it would have been quite applicable.
Also:
4.) Notify the supervisory authority of any data breach within 72 hours (Article 33)
5.) Notify the subject of any data breach without undue delay (Article 34)
And the broader issue of remedies and penalties in Chapter 8.
They handled the disclosure awfully. The GDPR has time-frames for notifying data protection authorities and the people affected about breaches. Presumably, they would have failed on that count.
Then the question is did they have the appropriate safe-guards in place, w.r.t. the importance of the data. I don't think we quite know what their systems look like. But the answer is probably not, given the scope, amount of very personal data, and the fact data from US, Canadian, and UK individuals was leaked, and the time it took to notice the breach.
Factoring both these things in and maybe the fact that an executive was charged with insider trading, they could be fined accordingly.
Beyond just the breach, I think Equifax's business would be difficult under GDPR?
One of the major problems with the breach is that, if you are worried about Equifax's security, you can't just choose to not let them store your data: they will store it, and provide it to third parties, regardless of your consent.
They would at least have been required to disclose the leak in a timely manner.
As others have said, their disclosure left a lot to be desired.
Depending on cause, potentially also not having sufficient security procedures in place to avoid such a leak of PII occurring.
Equifax is an American company targeting US residents, they are not concerned by GDPR.
Equifax is a global company headquartered in America that operates in 24 countries, including 3 where people are covered by GDPR: UK, Spain and Portugal[1].
They should be. Aside from operation in Europe eventually US legislative bodies will wake up and start passing laws to protect data. GPDR will be an obvious practical example to study, much as Obamacare was at least partly modeled experience in Massachusetts. I have no doubt that many tech companies have already put preventing this at the top of their DC lobbying agenda.
TL;DR: It's a spreadsheet to help you list out what personal data you keep in your organization, who has access to it, how it's secured, how long you plan on keeping it and what you intend to do with it.
MORE: I'm not trying to be dismissive, it's great! And whether or not you're going full-on trying to get GDPR compliant or not, it's _really_ hard to think of a scenario where taking the time to think and document your data handling and security isn't a net positive for the security posture of your application.
When you dig into the GDPR [1] you find that a lot of it is like this: common sense stuff that you'd hope everyone was doing already, but apparently aren't.
- Tell People what you're going to do with their data
- Don't do other stuff with it than what you told them
- Keep it secure
- Don't give it to other companies that might do things with it you didn't tell people about
- If you lose control of it in a data breach: tell them
- If they ask you for their data, give it to them
- If they ask you to delete their data, delete it
1 - https://blog.varonis.com/gdpr-requirements-list-in-plain-eng...
It’s the implementation that is difficult. For example, if someone wants their data deleted I need to go delete all of the email correspondence, I need to delete them from applications like Google Analytics. If I follow them on Twitter or interacted with the on Twitter I need to delete those posts. Oh and then there are backup archives that I now need to scrub. The point being is a lot of data is not well assembled and cleaned for deletion which is why data analytics on your existing data is so hard in the first place!
And the difficulty can rise exponentially if you have a giant stack that wasn't designed with GDPR in mind (though it may be totally benign in its risk towards data subjects) and which cannot be easily disentangled to comply with some of these requirements.
Opinion on the matter:
"The GDPR however does make a small concession to companies in this case: the steps they need to take in this direction are limited to the available technology and the cost of its implementation. Organizations must take reasonable measures to ensure processors are aware of the request, but will not be at fault if the data is not completely erased by third parties."
https://www.endpointprotector.com/blog/gdpr-essentials-the-r...
This more evidence that a hard consent is legal (from a conversation we had a few weeks ago on HN): https://twitter.com/maxschrems/status/998681336427827201?s=2...
It's unlikely you will need to scrub backup archives:
http://www.gdprarticles.com/gdpr-articles/data-subject-right...
> We are sharing this with anyone who wants to use it! Why?
[Their answer amounts to "because".]
Because they've gotten all the internal value out of it, and now with the deadline here, they can get maximum value out of it by "open-sourcing". Sorry to be so cynical, I'm so sick of this style of embedded advertisement.
That said, I do rather like the simple format of their template. Although their handling of "security" is too thin to be useful in any way, I will otherwise integrate their templates into our current documentary processes, which are awful by comparison.
Let's say you're a small bootstrapped Indi Hacker style SaaS.
You have a few hundred customers and maybe 10 of those are in Europe.
Would that company need to worry about complying? How much should they worry?
You're highly unlikely to ever be fined or come under official scrutiny. That being said, you may still want to try and comply with the GDPR:
1. It's becoming a checkbox buying issue for EU customers. Depending on what data you have, what you're doing with it, the fact that you aren't GDPR compliant may mean that your EU customers aren't GDPR compliant b/c they use you.
2. At some level you should care about the security and privacy of your users and while far from perfect the GDPR is a good general framework.
3. Unlikely is not the same as none. Given the tremendous technical leverage that exists now, it's not crazy to think that even a small SAAS with a couple hundred customers might have tens or hundreds of thousands of personal records. (consider an email newsletter service with 200 customers each of whom have 5,000 subscribers -> 1 million personal records).
If you have a million records on hand and a data breach happens, it's quite likely someone is going to complain and you might suddenly be on someone's radar. Don't take that to mean "omg, if I have a databreach I could get fined for $$$$". Because it's much more like: if you have a databreach and you haven't done a good job securing the data or letting people delete it or have some clear data handling rules and you failed to report the breach you might be in trouble.
Regardless of the size of organization, GDPR applies. In particular, note the section "Right of Access":
* https://en.wikipedia.org/wiki/General_Data_Protection_Regula...
Which requires the organization to supply information about use of personal information. This will have an operational overhead regardless of scope of Personal Information used.
For a worse-case (hopefully impossible) variant of what this request looks like: https://www.linkedin.com/pulse/nightmare-letter-subject-acce...
Oh please somebody correct me if I'm wrong. Otherwise that's a silly amount of operational overhead for bootstrapping. Even for systems designed from the start to not use personal data: The org would still need to handle a rather detailed and costly administrative request.
Wow that article is scary. Even worse would be "remove all my data from all your backups".
>You have a few hundred customers and maybe 10 of those are in Europe.
You need to worry and you should probably just refund them and block them from your service.
You should obviously comply, otherwise you might face fines and EU business customers basically can't use your SAAS. But as long as you're small that compiance isn't that hard. It's mostly basic stuff like having backups, encrypting them, not mailing your customer's info around in excel sheets, not giving everyone access to your servers, updating your servers, having a privacy policy that lists who gets customer info, etc.
The scary stuff is what happens if you have thousands of customers and they start requesting deletion or information. But if you only have a hand full of EU customers you can wait till that happens, you only have to comply within a month.
EU regulators are generally very reasonable. If you show that you made reasonable effort but had a genuine mistake they will generally give you a warning or at worst a low fine.
Very happy to see this made public, the focus on data life-cycle management is a good one and it is actionable which makes it even better.
Before "Who owns and controls the personal data we collect?", there has to be "What personal data do we keep, in actual reality?"
That is, personal data discovery.
Emails, archives, cloud storages… it can be hard to be sure when relying on just human introspection or wishful thinking. Especially for larger organizations.
Automated discovery tools help -- we built pii-tools.com, an AI–assisted tool to locate personal information across corporate assets. If you're having trouble filling in spreadsheets like this with actual data, get in touch (contact in profile).