Are Steam account IDs (and telemetry data associated with Steam IDs) deemed personal data? A few friends and were having an argument on the following situation: People can sign up for Steam accounts for free, letting them purchase games and play games over their network. Users are able to create public profiles for their accounts, a nickname, real name, location, etc - but this is not essential (sometimes people put fake information, but a considerable number of people put legitimate information). Via OpenID, users are able to authenticate and identify themselves to various other websites. Some games, for example Dota 2 (published by Valve, who also run the Steam network) use publicly visible Steam IDs of players as unique identifiers within their games - in order to track information about their users, including reports, statistics, etc. Provided that a user consents, part of their data from matches they play in is exposed via an API. This includes stuff like what character you played, your performance in game, etc. This allows 3rd party websites to show you interesting statistics about the games you play. There is another API (also run by Valve) which allows users to download "replays" of the matches, so users can rewatch what happened. Within these replays are, regardless of what a user's consent status may be, users' uniquely identifiable Steam IDs. This allows 3rd parties to track users even if they've not opted into 3rd party sharing. My questions are: Is a Steam ID "personal data"? Is the sharing of data to a 3rd party by Valve without consent against the GDPR? If #2, How would I make a formal complaint about this. Answer mostly important for an EU user, but would be interested if there were US comparisons.
Since the Steam ID contains or may contain enough information for it to be possible to link your account to you as a physical person, it would definitely be considered "personal data" according to Article 4 of the GDPR. However, by agreeing to the DOTA2 terms of service, you have given consent for them to show your information to other players (or at least that is included in most terms of service I have read for other games. I have not read the one for DOTA2 specifically). Replays are an interesting corner case. If download of replays are only possible for other players or if the wording of the ToS says that you consent to displaying your user ID to anybody, that would mean that they would have covered their bases. As long as they comply with other parts of GDPR, like "the right to erasure" (Article 17) that is. If the API is accessible to anyone and not covered by the ToS you might have a case. If you only want to remove the traceability between you and the replays, you can always evoke Article 17 and delete your account.
Obtaining consent for cookies is not required by the GDPR at all. Instead it is covered by the e-privacy directive, which as a directive rather than a regulation, must be implements by specific legislation in each individual country. The exact requirements vary with the law of each country. An e-privacy regulation has been proposed, which would have scope similar to the GDPR, would replace the Directive, and would not require national implementing legislation. However it has not yet been adopted. Proposed versions have significantly different requirements than the current Directive. Nor does the GDPR require consent for advertising that does not involve the processing of personal information, unlike some other privacy laws such as the California CCPA. However, if the Google package sets cookies without consent that are not strictly necessary for operation of the web site, it might well fail compliance with some of those national laws implementing e-privacy. Also, even necessary cookies must be disclosed to the user, as I understand it, possibly only in general terms. Several national Data Protection agencies have said that cookie compliance is not a major priority, at least not until an e-privacy regulation is in place. But that does not mean that lack of compliance is legal. Unfortunately I see no way for a developer using the Google package to correct this issue within the package. One would either have to implement a different solution, or trust that Google will fix this before enforcement becomes a serious issue. However, the app developer could add a separate general cookie consent banner, and turn off all adds if consent is not given, I believe.
Yes, their waiver has no legal basis and is invalid under the GDPR. They should have hired a better lawyer. GDPR rights cannot be waived (mrllp.com). The last bit should have been: Therefore, in consideration of my participation in any project, I understand that retaining my name and email address, as described above, does not require my consent and that the right of erasure, as spelled out in the GDRP Article 17 (1) b does not apply. The legal basis for our lawful processing of this personal data is Article 6 (1) f ("processing is necessary for the purposes of the legitimate interests pursued by the controller"). I.e. there is nothing in the GDPR that compels GitLab to erase this information, but their waiver is bogus. Keeping track of individual contributions in a software projects is necessary for a number of reasons, including security (if somebody contributes code that jeopardizes security, you want to audit everything that person has contributed).
The data controller is obliged to use “all reasonable measures to verify the identity” of the person exercising their data subject rights (GDPR, Recital 64). That sentence has caused a lot of confusion: “all reasonable”: does this mean all measures the controller can be reasonably burdened with, or all measures that are necessary for identifying the data subject with reasonable certainty? “identity”: does that mean the identity of a natural person, or just a check that the person exercising their data subjects rights is identical with the data subject? So depending on how the company interprets this, there is a lot of leeway regarding which info may be requested from you. In general, being able to log in to the service should be all that is necessary (compare also Recital 57). Note that the company doesn't just have to satisfy your data subject rights, they also have to protect your data against unauthorized access. Giving an attacker access just because they control a particular email address might not be secure enough (but is in practice because the attacker could use a password-reset functionality to get the full credentials anyway). You do not lose your data subject rights if you used pseudonymous/fake data: the service may still contain other personal data regarding you, for example usage profiles. You are still a data subject. Pseudonyms can also be identifying data, e.g. Art 4(1) calls online handles out as a kind of personal data. However, this does lead to complications with companies that interpret identity verification as ensuring that the person making a request is a particular natural person. If the controller isn't sure about your identity, they can request additional information (Art 12(6)). If the data subject cannot be identified, the data subject rights do not apply (Art 11(2)). However, that describes a subtly different scenario: that the data held by the controller lacks identifying data. You do have a right to access and a right to rectification (correcting the data they hold about you). However, they require the exact same identity verification as the right to erasure. That you were underage at the time of account creation is likely irrelevant now, if the data in the account doesn't indicate your true age. Unless the subject matter of the online service makes an age restriction necessary, the relevant age limits are 13-16 years (Art 8 GDPR, subject to EU member state laws) or 13 years (COPPA, U.S.). If you believe you have provided all data that is reasonably necessary to verify your identity and your data subject rights are denied to you, you can issue a complaint with your local data protection authority. In Germany, each Bundesland has their own Datenschutzbeauftragte agency. Below, relevant GDPR excerpts used in this answer. “Erasure” is Art 17 but Art 12 covers modalities for exercise of data subject rights. Recitals are explanatory but not normative. Art 12(6): Without prejudice to Article 11, where the controller has reasonable doubts concerning the identity of the natural person making the request referred to in Articles 15 to 21, the controller may request the provision of additional information necessary to confirm the identity of the data subject. Art 11(2): Where […] the controller is able to demonstrate that it is not in a position to identify the data subject, […] Articles 15 to 20 shall not apply except where the data subject, for the purpose of exercising his or her rights under those articles, provides additional information enabling his or her identification. Recital 57: Identification should include the digital identification of a data subject, for example through authentication mechanism such as the same credentials, used by the data subject to log-in to the on-line service offered by the data controller. Recital 64: The controller should use all reasonable measures to verify the identity of a data subject who requests access, in particular in the context of online services and online identifiers.
According to my knowledge I am not allowed to share other people's full name nor phone number nor email address without their permission. That is not correct. According to GDPR Article 2: This Regulation applies to the processing of personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system. This Regulation does not apply to the processing of personal data ... ... (c) by a natural person in the course of a purely personal or household activity; GDPR Recital 18 states in relevant part: (2) Personal or household activities could include correspondence and the holding of addresses, or social networking and online activity undertaken within the context of such activities. Personal data that is not processed by &quot;automated means&quot;, for example data which is transmitted verbally, by hand writing, or by manually sent email, is not covered by the GDPR. Data which is used by a natural person for &quot;personal activities&quot; is also not covered. Consulting one's personal lawyer might well be a personal activity unless it is a business matter. Even if such a transfer of data were in scope for the GDPR, consent of the data subject (DS) is not the only available lawful basis. GDPR article 6 permits any of several possible lawful bases to be used, particularly paragraph 1 point (f) which reads: (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Also possibly relevant is point (c) which reads: processing is necessary for compliance with a legal obligation to which the controller is subject; In short, providing one's personal lawyer with the names and addresses of relevant people in connection with a legal issue is not at all likely to be prohibited by the GDPR, nor to require the consent of the people whose names and contact info are provided. However, a comment by user PMF reads: The Data Protection laws are mostly for companies, not for individuals. This is an overstatement. The laws do apply to natural persons as DCs, although enforcement is largely targeted at businesses, particularly large, for-profit businesses.
The site would combine the data in novel ways, which is processing the data. Processing personal data which is publicly available is still processing personal data. You would have to take GDPR into account. That does not mean the processing is forbidden, but you need a legal basis for doing it. In many ways, having the informed consent is the easiest legal basis, but there are others. The data subject would have the right to demand information about the data you hold, and to demand the correction of wrong data. There is not necessarily a right to demand deletion, but if consent is withdrawn and you have no other basis for data processing, you have to delete. Note also that the consent basis would mean you have to actively contact the people whose consent you seek before the processing starts, and document how you do it. That makes pay-per-request models difficult. But consider that the news media can process some data about some people without the consent of the subjects of their activities. They just need to balance privacy and other legitimate interests all the time.
IP addresses are personal data. That means you need a legal basis to process them, but not necessarily consent from the user. That IP addresses should be treated as personal data in most contexts is clear, regardless of whether you can associate the IP address with a user ID. That you make such an association affirms that both the IP address and user ID are personal data in your context though. As the answers in the questions you linked indicate, there are alternative legal bases to consent. The GDPR offers a choice of six legal bases (Art 6(1) lit a–f). In most cases, you would instead rely on a “legitimate interest” for logging. But it's not enough to claim that you have a legitimate interest. You must have a clear purpose for which such logs would be necessary, and you would then have to weigh this legitimate interest against the interests, rights, and freedoms of the affected data subjects. If such logs are necessary for security and anti-abuse purposes, your legitimate interest test is likely to prevail. However, you must limit retention of the logged data and the included information to what is actually necessary. For example, keeping user IDs in there might not be necessary. If the association of IP addresses and user IDs is not necessary for a legitimate interest, then you would indeed need consent. Discussion on why IP addresses are personal data. You see many answers and opinions that IP addresses might not be personal data. Some of these are technically correct, but most are misinformed or outdated. I know only a single well-informed person that still disagrees. For everyone else such as the EU Commission, IP addresses are clearly personal data. Under the GDPR, personal data is any information that relates to an (indirectly) identifiable natural person. In the context of log files we can assume that the entries usually “relate” to a person, namely the person making the request. The exception would be requests triggered by automated systems. The more interesting question is whether the person to which the log entry relates is identifiable. While the GDPR does provide further guidance on the concept of identification in Recital 26, it does not provide clear unambiguous criteria. Thus, there is lots of debate about what that precisely means. One approach is to sidestep that debate and and notice that the GDPR's definition of personal data explicitly notes that a person might be identified “in particular by reference to an identifier such as a name, an identification number, location data, an online identifier” (Art 4(1)). Another but otherwise unrelated part of the GDPR mentions “internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags” as examples of online identifiers (Recital 30). We can also look more deeply into Recital 26 and see that “singling out” already counts as identification. We can use the IP address to single out one person's log entries from the set of log entries, so this could be interpreted as meaning that any stable user ID renders the data personal data – and an IP address is sufficiently stable in this context. Another part of Recital 26 says that we must consider “all the means reasonably likely to be used” for identification, even if this involves additional information from third parties. This phrasing is virtually identical to the GDPR's predecessor, the EU Data Protection Directive. On the basis of that DPD, the EU's top court (ECJ/CJEU) was asked to rule on the question whether dynamic IP addresses are personal data (the Breyer case, C‑582/14, judgement from 2016-10-19). It said yes. “It did not say yes”, some people will object. And they are technically correct. When someone rents an internet connection from an ISP, the ISP will have logs that connect the user's real-world identity to the IP address they were assigned at a time. You don't have access to the ISP's logs. But, if that user violated your rights (e.g. a cyberattack or copyright infringement), then you could (depending on civil vs criminal matters) report this to the appropriate authorities or to petition the court and they would have the right to order the ISP to disclose this information. The CJEU said that if this chain (you → authorities → ISP → user identity) is grounded in law, then the IP address would be identifiable. But whether there are suitable laws to compel the ISP to disclose this data would be up to national laws, and the CJEU doesn't concern itself with that. Spoiler: such laws are pretty common. To summarize typical objections: The IP address doesn't relate to a person: Can be a valid objection, but is not typically the case for user-facing web services. The Recital 30 argument is not valid because it's about profiling, not identification, and it only says that IP addresses may be used for profiling, not that they are always identifying: Technically correct, but I think that Recital 30 merely expresses the implied understanding that of course an IP address is an online identifier and permits identification by itself. “Singling out” does not apply because SOME_REASON: Indeed, this is an ill-defined term with no case law to guide us. However, regulators such as the EDPB and their predecessor WP29 routinely use “singling out” to mean being able to distinguish one person's data from other people's data. An IP address lets us do that. The Breyer judgement is not applicable because the defendant in that case was the German state, and the state has other legal means than ordinary website operators: Nothing in that case was specific to the website operator being a state or other authority. If the website operator can contact the appropriate authority and if they have the right to order the ISP to disclose the relevant data, then the IP address is identifiable. The CJEU didn't say “yes” in Breyer, it said “if”. So I'll take that as a “no”: The CJEU concerns itself with the interpretation of EU law, not with national laws. Specifically in the Breyer case, lower courts confirmed that German law has the necessary means. In other EU member states, further checks would be necessary but it would surprise me if there wouldn't be equivalent subpoena powers. If the ISP doesn't have the data, then the IP addresses are anonymous: Indeed, the CJEU scenario collapses if there is no additional data to be linked with the IP address. However: The CJEU used this scenario as an example to show that IP addresses can be identifiable. If that particular scenario fails, there could be other scenarios that still allow identification. The question of whether IP addresses are identifiable had of course been the subject of wider debate at the time. That the GDPR explicitly mentions IP addresses can be seen as a reaction to this debate. Thus, in a sense, the Breyer case is moot. It is still useful as an explanation of how broad “reasonably likely means” must be interpreted.
You are having difficulty understanding the GDPR because you have an improperly narrow idea of “identification”. In contrast, the GDPR uses an extremely broad definition. In Art 4(1), personal data is defined as 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 It is worth noting that your “auto-generated identifier” would quite clearly be “an identifier such as … an identification number” and/or “an online identifier”. It is also worth noting that indirect identification is still identification. Recital 26 explains the concept of identifiability in more detail: ³To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. ⁴To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. Key observations: Singling out a data subject already counts as identification, meaning that it isn't necessary to infer their real-world identity! The data subject is still identifiable if you can only identify them with additional data. The data subject is still identifiable if identification can be performed by others. The main limit to this concept is the “means reasonably likely to be used” criterion: as long as there is a reasonable scenario in which the data subject could be likely identified, they are identifiable. Identifiability does not depend on your current intentions or policies, only on objective factors. As an illustration of these points, consider the Breyer case (C-582/14). The pre-GDPR Data Protection Directive had an essentially equivalent concept of identification, except for the “singling out” factor. The CJEU was asked to decide whether this meant that IP addresses collected in a server log file of some website were personal data. Quite clearly, such IP addresses do not directly identify a person, unless you happen to be the data subject's ISP. But here the CJEU constructed a reasonably likely scenario that shows that IP addresses will typically be personal data even without the “singling out” criterion: in the event of cybercrime, the website operator would reasonably provide the IP addresses of visitors to the police for investigation, and they in turn would have the means to get a subpoena/court order to get the ISP to provide the information necessary for identification. What does this mean for your identifiers? These identifiers and any linked information relate to a particular user, the data subject. Thus, these identifiers and any linked information are personal data if the user is identifiable. Since these identifiers allow you to single out a particular data subject, i.e. allow you to distinguish one user from another, the users are identifiable within the meaning of Recital 26 GDPR. Additionally, identification is possible if it is performed by someone other than you – such as the user themselves. How does this mesh with data subject rights? You correctly point out the problem that when a user contacts you to exercise their data subject rights, you wouldn't be able to find their records. But Art 11 GDPR prepares for this: If your processing activities do not require identification, then you are not required to acquire or maintain additional information just for the purpose of complying with data subject requests (this encourages data minimization). If you can demonstrate that you are unable to fulfill a data subject request because you can't identify the data subject, then the data subject rights in Art 15 to 20 do not apply. These are the rights to access, rectification, erasure, restriction, and data portability. Unaffected are the right to information, the right to object, and rights related to profiling. However, you still have to comply if the data subject provides additional information enabling their identification. You have intuitively grasped the correct solution: you can provide a feature where the user can see their automatically generated user identifier. Then, they can provide this ID to you when invoking their data subject rights. A note on privacy-preserving analytics. When it comes to analytics, the GDPR and ePrivacy issues must be looked at separately. From a GDPR perspective, any client IDs or other identifiers are likely to be personal data, regardless of how they are stored or created. But the GDPR does not necessarily require that the user gives consent to such analytics – a legitimate interest (opt out) solution might also work. The ePrivacy Directive does not care about whether such IDs or fingerprints are personal data, only about how they are created and stored. Any access or storage to information on the end user's device is only permissible with consent, unless the access or storage is strictly necessary for a service explicitly requested by the user. Analytics are not strictly necessary from the user's perspective. Thus, while cookies or LocalStorage can be freely used to store user preferences on a site, accessing/storing cookies for analytics purposes, or accessing information for fingerprinting purposes through JavaScript APIs, is only permissible with consent. Compare also the WP29 opinion 9/2014 on fingerprinting (PDF). This leads me to conclude that many so-called GDPR-compliant or cookie-less analytics fail to meet ePrivacy obligations if they include a client-side component such as the typical JavaScript tag without asking for consent, but that they might be OK if they rely on purely server-side data collection. Regardless of how user IDs or fingerprints would be created, those IDs and any linked data would still be personal data though, so that GDPR would still apply. A hash of an identifier is still an identifier and therefore personal data, and at the very least still enables indirect identification. (WhatsApp attempted a “lossy hashing” argument while appealing its fine, but didn't convince many supervisory authorities.)