News for hackers. Stuff that matters.
Re:Open-Sourcing our GDPR Compliance Preparation For Article... by scrollaway on Saturday May 19, 2018 @10:33AM (#17108026)
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

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by stingraycharles on Saturday May 19, 2018 @10:58AM (#17108124)
> 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.

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by scrollaway on Saturday May 19, 2018 @11:04AM (#17108145)
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.

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by wongarsu on Saturday May 19, 2018 @12:06PM (#17108439)
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).

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by emilfihlman on Saturday May 19, 2018 @05:25PM (#17109811)
>It doesn't matter if you can correlate user id and account holder, what matters is that somebody can

This is absurd and 100% bullshit. It means anything and everything is now personal data, even randomly generated data.

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by wongarsu on Saturday May 19, 2018 @06:26PM (#17110053)
A lot of user ids are literally randomly generated data (for example any UUID used as user id). That doesn't make it less useful.

But that doesn't mean that everything is personally identifying information. "I am 53 and like Harry Potter" isn't enough to identify me, so it isn't PII and isn't covered by GDPR. My Blizzard username is enough for Blizzard to identify me, so it is PII.

The important concept here is that in Europe, data protection laws are not only protection against corperations, they are also protection against nation states. We had a few bad experiences with the effects of government surveilance, and we had a few bad dictators in the last century.

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by Guest9812398 on Saturday May 19, 2018 @03:16PM (#17109274)
> 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.

Isn't the purpose of global rankings to know how any given user is ranked globally? It's not much of a ranking system if all you can say is, "Yes, we have one million users, and they are ranked 1 to 1,000,000. We are not able to identify who is what rank."

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by wongarsu on Saturday May 19, 2018 @06:13PM (#17110002)
What's wrong with "we have one million users. You are ranked 45698th. The one below you is proplaya92, the one above you chose to have his name redacted" (but we can tell you his playtime on all characters, his k/d ratio, etc).
Re:Open-Sourcing our GDPR Compliance Preparation For Article... by merinowool on Saturday May 19, 2018 @11:18AM (#17108212)
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.
Re:Open-Sourcing our GDPR Compliance Preparation For Article... by stingraycharles on Saturday May 19, 2018 @11:15AM (#17108197)
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.

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by antoncohen on Saturday May 19, 2018 @12:16PM (#17108479)
Is that really how you think GDPR will be interpreted? As a European, are you OK with that?

If a football team plays, and a stats website (call it ERDB) uses Eredivisie's API to get player stats and then publishes them, should ERDB have to be processor? Then there would have to be a processor agreement every time Eredivisie issues an API key. And they can't have a public API. And if ERDB wants to switch from AWS to GCP that will have to get written approval from Eredivisie for a new sub-processor?

Is that really the world people want to live in?

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by theptip on Saturday May 19, 2018 @02:21PM (#17109039)
It's an interesting question. There are some exceptions for lawful processing under GDPR[1]:

> Processing shall be lawful only if and to the extent that at least one of the following applies:

> processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;

> processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;

So in this case, it's probably the case that any athlete will have to sign a contract saying they are OK sharing their stats publicly in order to play. If an athlete sued Eredivisie to try to be forgotten from the league tables, how would that case be decided?

It's also worth noting that in the original "right to be forgotten" case that Google lost, the original newspaper articles reporting the criminal cases were not required to be expunged, so there is still a "public interest" defense for keeping information about people in public. It's certainly unclear exactly where the boundary is on that though.

I wonder also if there is an argument that a professional player's stats are not Personal Data; those stats are a record of events that occurred in public, while engaging in a performance. IANAL so interested in opinions of more knowledgable folks on this one.

[1]: https://gdpr-info.eu/art-6-gdpr/

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by gonzo on Saturday May 19, 2018 @01:59PM (#17108950)
> Is that really the world people want to live in?

That’s the world as legislated.

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by wasyl on Saturday May 19, 2018 @12:06PM (#17108441)
Could Blizzard deny signing the Processor agreement, thus effectively limiting the access to their, otherwise public, API?
Re:Open-Sourcing our GDPR Compliance Preparation For Article... by theptip on Saturday May 19, 2018 @01:56PM (#17108926)
Under GDPR, the Controller is the entity that the Data Subject gives their Personal Data to, and the preponderance of responsibility for managing that data lies with the Controller.

If the API data under discussion here includes "personal data", then Blizzard shouldn't (under GDPR) be sharing it publicly; Blizzard is the Controller, and it's their responsibility to ensure that only known and compliant Processors get access to the PI. (E.g. there is a requirement that all Processing activity is done under a binding contract (https://gdpr-info.eu/art-28-gdpr/ SS 3))

When an individual wants to be forgotten, they can contact Blizzard (as the Controller) and tell Blizzard to delete all their PI. It's Blizzard's responsibility to ensure that all Processors delete the PD that Blizzard gave to them.

So in this case, my conclusion would be that it's Blizzard's responsibility to either anonymize the data so that it contains no PD (this might be the case already), or stop sharing the PD publicly and require a DPA (Data Processing Addendum) signed by all API consumers. Obviously the second case is not very palatable.

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by dominotw on Saturday May 19, 2018 @04:03PM (#17109481)
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.

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by stingraycharles on Saturday May 19, 2018 @04:10PM (#17109523)
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.
Re:Open-Sourcing our GDPR Compliance Preparation For Article... by dominotw on Saturday May 19, 2018 @04:49PM (#17109655)
> . 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.

There are zipcodes in USA with only 1 person. So storing just zipcode would be ID information. Its an extereme example but how can machine check whats 'reasonable' in this case, go off of some census data for zipcode?

I wonder if there are any real world ( as opposed to things like ingame points) information that can be considered not PII .

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by punnerud on Saturday May 19, 2018 @06:57PM (#17110176)
There is also the interpretation of when is it PD or AD. In Norway the ‘The Norwegian Data Protection Authority‘ states 4 or less is personal, no way to link to less than 5 is anonymous.
Re:Open-Sourcing our GDPR Compliance Preparation For Article... by lajhsdfkl on Saturday May 19, 2018 @03:18PM (#17109284)
>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.

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by matthewmacleod on Saturday May 19, 2018 @03:48PM (#17109414)
I have no idea why you consider it unreasonable that I should be able to request data a company holds on me.
Re:Open-Sourcing our GDPR Compliance Preparation For Article... by throwaway13456 on Saturday May 19, 2018 @02:26PM (#17109056)
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.

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by fcarraldo on Saturday May 19, 2018 @02:42PM (#17109108)
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.

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by tripletao on Sunday May 20, 2018 @02:51AM (#17111580)
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.

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by scrollaway on Sunday May 20, 2018 @04:51AM (#17111883)
You have EU customer emails. You're subject to gdpr in all of them. None of the factors you suggested matter. Store your emails properly, have unsubscribe links, answer data requests.

You just gave one of the most straightforward cases...

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by tripletao on Sunday May 20, 2018 @11:52AM (#17113272)
The post above said:

> 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.

Do you think this statement is correct or incorrect? If you think it's incorrect, then why are you interpreting the "clear language" of the GDPR differently from its poster? (I personally think the statement is either incorrect or too vague to assess.)

If you think the statement is correct--I presume, because you think that as soon as an EU visitor signs up, you have a "client" or "business presence" in the EU--then what meaning does that poster's statement convey? Does it mean anything more than "blocking EU visitors is unnecessary, as long as you have zero EU visitors", a true and entirely meaningless statement?

Or are you saying that the email address makes this different from just a visitor? Even if my server is a typical default configuration that logs time and IP for each visit? Even if my ad network logs tracking cookies? Even if a data broker exists somewhere who could map that information to a real name? Even if I buy that data?

And, for clarity: What about the case where the website (1) calls out only products with authorized distributors only in the USA, (2) has recipes for all kinds of food, (3) describes restaurants only in the USA, (4) is in English only, and (5) isn't advertised makes it subject to the GDPR? The EU says in an example that:

> Your company is service provider based outside the EU. It provides services to customers outside the EU. Its clients can use its services when they travel to other countries, including within the EU. Provided your company doesn't specifically target its services at individuals in the EU, it is not subject to the rules of the GDPR.

https://ec.europa.eu/info/law/law-topic/data-protection/refo...

Do you agree with this guidance? If yes, what factor constitutes the specific targeting? Or does the "travel" language mean we exclude only non-EU residents who temporarily visit the EU? Also EU residents who sign up while in the USA, but then return home? But not EU residents who sign up while in the EU?

How sure are you that your answer is correct? I get that you're sure that it's morally right, and complying is always the conservative choice; but what probability would you assign that an EU court would reach your same conclusion, that all 216 cases are subject to the GPDR?

And since any suggestion that the GDPR is less than perfect attracts angry reactions: I am not asking whether it's a good idea to comply with the general spirit of the GDPR for all visitors worldwide, and I think the answer to that question is yes. I'm asking what the law says. I think the rule of law is important, and I'd venture that most people who have lived in countries with and without it would agree.

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by scrollaway on Sunday May 20, 2018 @04:01PM (#17114490)
It is correct and it is clear. If you have customers in the EU, gdpr matters. If you don't, it doesn't. And either way, you should strive to follow it, because GDPR's rules really are a set of common sense things you should have been doing all along:

- Store your stuff properly (encrypt sensitive data)

- Allow users to download their data

- Allow users to delete their data

- Have a clear privacy policy

- Offer ways to opt out of marketing

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by tripletao on Sunday May 20, 2018 @04:43PM (#17114634)
I said explicitly that I'm not trying to debate what's morally right, or good for business (since I agree that good privacy practices are both of those). I'm asking what is the law.

> If you have customers in the EU, gdpr matters. If you don't, it doesn't.

Either this is false, or you've adopted an unusual definition of the word "customer". The email recipients don't give me money, but even I agree that e.g. if I promote my site with advertisements only on EU sites, and know or should know that most of my recipients are EU residents in the EU, then it's relatively clear that I'm subject to the GDPR.

Lawyers care about precision of language, because people's lives are at stake. It's not useful to discuss legal matters without that precision.

I guess you're certain enough that all my previous examples are subject to the GDPR that you don't think it's worth discussing why, since you didn't answer any of my questions. How about:

I. I run the website that (1) calls out only products with authorized distributors only in the USA, (2) has recipes for all kinds of food, (3) describes restaurants only in the USA, (4) is in English only, and (5) is advertised on American newspaper websites; but I take no specific measures to exclude EU visitors? I think you think I'm subject to the GDPR.

II. Same as II., but I block EU IP addresses?

III. Same as II., but I ask the remaining people if they're subject to the GDPR, and block them if they say yes?

IV. Same as III., but I require a credit card with an American billing address?

V. Same as IV., but I require evidence of legal American residence (e.g., a scan of a US passport of visa)?

Are you able to answer these questions? Or does it just not bother you that you can't, because compliance with the GDPR serves a purpose you agree with?

What do you understand by the phrase "rule of law"? Do you think it's important? Hungary is an EU country. Its prime minister has described George Soros, the founder of the Open Society Foundation, as an "enemy of the state". If you ran an organization publicly associated with the OSF in Hungary, then how would a notice of a GDPR investigation from your government make you feel? Wouldn't you feel better if the rules gave the regulator less room to maneuver?

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by icedchai on Monday May 21, 2018 @04:37PM (#17121628)
Here's what I would do: Nothing. You're in the USA. Your site is in the USA. Don't worry about it. If you receive any undesired correspondence about the GDPR, treat it like you would any other junk mail.
Re:Open-Sourcing our GDPR Compliance Preparation For Article... by cge on Saturday May 19, 2018 @04:34PM (#17109609)
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.

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by lajhsdfkl on Saturday May 19, 2018 @03:24PM (#17109308)
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.
Re:Open-Sourcing our GDPR Compliance Preparation For Article... by matthewmacleod on Saturday May 19, 2018 @03:50PM (#17109423)
This is nonsense. GDPR is cheap to comply with: following best practice, you should easily be able to comply with it.
Re:Open-Sourcing our GDPR Compliance Preparation For Article... by ebiester on Sunday May 20, 2018 @01:38PM (#17113871)
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.

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by matthewmacleod on Monday May 21, 2018 @03:36AM (#17116778)
Yes. I’m 100% willing to risk it, because I have a basic knowledge of how regulatory processes in the EU generally work.

The LinkedIn example is excellent, because it lots all the things that you should have already known about and been able to do with personal data.

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by tomkinson on Saturday May 19, 2018 @08:13PM (#17110462)
Yup +++
Re:Open-Sourcing our GDPR Compliance Preparation For Article... by archgoon on Saturday May 19, 2018 @08:12PM (#17110460)
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 :).

Re:Open-Sourcing our GDPR Compliance Preparation For Article... by TheAceOfHearts on Saturday May 19, 2018 @10:37AM (#17108043)
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?
Re:Open-Sourcing our GDPR Compliance Preparation For Article... by scrollaway on Saturday May 19, 2018 @10:48AM (#17108087)
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.