GDPR: Can I collect non-personally identifiable information? I'm creating a game that collects data in two ways: Unity Analytics for usage stats, and bug reports that sends me a report of an issue along with several files to help me diagnose the issue. However, GDPR is becoming a rather confusing problem for me. The data collected with my bug reporter is: A hashed unique device ID A game save file System specs Settings configuration A short in game video recording (only shows the game window - not the users desktop) None of this is personally identifiable (I'm pretty sure) - I don't collect IPs, names, emails, gamer tags etc. As such, do I need permission from the user to collect this data? Would I still be GDPR compliant?
There are two relevant bodies of EU law to consider here. The GDPR covers processing of personal data. Personal data is any data where the data subject can be identified directly or indirectly. The ePrivacy directive is also relevant, and covers how you may access and store information on the user's device. Directives are not directly applicable law. Instead every member state translates the directive into national law. In the UK, ePrivacy is implemented by PECR. Is the data you collect personal data in the sense of the GDPR? Yes: that hashed unique device ID or a system-provided advertising ID likely is personal data, and any linked data would then be personal data as well. This is going to be the case in particular if you store user accounts on your server and can connect these bug reports to a user. Consider also whether the game save could include personal data, and whether the video clip could be analyzed to identify the data subject. Does this mean collecting this information in bug reports is forbidden? No, the GDPR doesn't forbid or allow anything outright. Instead, you should go through the compliance process. In a nutshell: determine the purpose of this processing, e.g. “fixing bugs” find an Art 6 legal basis for this purpose, e.g. “Art 6(1)(f) legitimate interest” or “Art 6(1)(a) consent” if the legal basis is legitimate interest, you must balance that interest against the data subject's interests determine whether your compliance requirements include creating/updating your Records of Processing, or whether you have to write a Data Protection Impact Assessment implement the processing in a manner that respects GDPR principles such as Transparency and Data Minimization if the legal basis is legitimate interest you must implement an opt-out solution if the legal basis is consent, you must request consent first in a manner that satisfies the Art 7 conditions for consent – and allow consent to be revoked easily prepare to satisfy data subject rights: information requirements per Art 13, usually done in the privacy policy right to access, rectification, erasure, and data portability right to object (opt-out) and to restrict processing be aware of your general requirements a data controller to process this data securely, e.g. use HTTPS connections to transmit bug reports, take steps to protect your own accounts (e.g. 2FA), and ensure you have a suitable contract with any data processors that act on your behalf, e.g. cloud providers or contractors I would question whether your bug reports really need to include a device ID. That isn't forbidden, it just complicates compliance a bit. And what about ePrivacy? The ePrivacy directive is known for its cookie consent requirements. But these consent requirements apply when accessing any information on the user's device, or when applying equivalent fingerprinting techniques. Your game save is not an issue because it is necessary for the game. But that device ID and other system information is more difficult. So what to do? Compliance isn't trivial, but certainly possible. You will likely process the bug reports under your legitimate interest, but might still have to collect consent for accessing a system ID due to ePrivacy. Such a screen might look like this: Oh no, the game crashed! Do you want to send a bug report to the developers? Your bug report will be protected as per our privacy policy (link). Your bug report will contain the following information: … Yes, collect system information and send bug report No, do not send bug report You could make an argument that a bug report can be sent in any case, and that you just need ePrivacy consent to collect useful system information. For example: Oh no, the game crashed! When sending a bug report to developers, do you want to include extra system information (link to details) that helps fixing the problem? In any case, your bug report will be protected as per our privacy policy (link). Your bug report will contain the following information: … Yes, send bug report with extra system information No, send anonymous report
First of all, a password is not personal data. ‘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; From GDPR Article 4 (https://gdpr-info.eu) As for password hashes, what do you mean by requesting a copy of yours? You can produce it if you knew the hashing algorithm of the website. By the way, websites should be using good hashing algorithms, such as bcrypt or scrypt, not MD5 or SHA1.
First of all, in a GDPR contest, the process described is not strong anonymization. It may be hard for an outsider to go from the stored record to any PII, it is much easier for an outsider to &quot;single out&quot; an individual. This means that given a known individual, one can determine whether that person is among those listed in the records, or can determine this to a significant degree of probability. For this only the algorithm and the rotating salts are needed, one need not break the hash. Note also that the GDPR specifies that if a person can be singled out with the assistance of the site operator the data is not considered anonymized. Thus this data needs a lawful basis under the GDPR, and the various other GDPR requirement all apply. However, even if the data were totally anonymized, and say just added to a count of users with this or that User Agent, the process of reading local data (including but not limited to cookies) itself requires informed consent, and so a cookie banner or other interaction with similar info under the e-Privacy directive (EPD). The EPD, being a directive and not a regulation, must be implemented by national laws, and the exact provisions in those laws may differ somewhat from country to country. But I believe that all of them require consent before any local data is read.
Generating a list of all possible numbers doesn't sound like it would constitute personal data any more than listing all dates for the last hundred years as a "possible date of birth" would. However, the moment anyone linked even one of the numbers with any other personal data - for example a name - they would be bound by GDPR and would need to show a Lawful Basis for processing the data. [If you linked your own name you could presumably argue Consent, but anyone else's would need to have an associated Lawful Basis.]
I recently came to the shocking realization that the GDPR does not apply to natural persons who are not EU citizens. This conclusion is mistaken. Where is it stated in the GDPR that the GDPR only applies to EU citizens? It is not stated anywhere because nationality is irrelevant to the GDPR. The GDPR protects &quot;natural persons&quot; based on their location &quot;in the union,&quot; not on their nationality, and it applies to data processors and data controllers that undertake &quot;activities [through] an establishment ... in the union.&quot; In addition to the recital quoted in the question, this is specified in article 3, which establishes the regulation's &quot;territorial scope.&quot; For a complete discussion of this matter, consider the EDPB's guidelines 3/2018 on the territorial scope of the GDPR which also provides examples of GDPR protections for people who are not EU citizens. Who does the GDPR refer to as legal persons? &quot;Legal person&quot; generally denotes natural persons, corporations, partnerships, government entities, and so on.
Personal data is any information relating to an identifiable person, even if that person is only identifiable with the help of additional data and/or third parties. Making inferences about a particular person, for example whether that person might have performed unauthorized construction, sounds very much like processing of personal data to me. In this scenario, the information is used to verify the tax assessment for a particular person, so the information clearly relates to a data subject. The owner for a piece of land is certainly identifiable with the help of the land registry, if one exists in the country. Similar registries might also exist with tax authorities or a postal service. Here, it is the tax authority itself doing the processing, so they probably already have tax records about the owners at the address. But just because it's processing of personal data doesn't mean that it is illegal. Satellite data and aerial photography providers can probably rely on a legitimate interest to collect, sell, or otherwise publish their data. Homeowners can reasonably expect that their property will be included in low-res aerial photography. It might not be necessary to notify the data subjects if an exception in Art 14(5) applies. A public authority using aerial photography to find building code violations or to levy correct taxes may be able to base this processing activity on authorization via some law. If the public authority would have the right to inspect the buildings, then it might be possible to argue that the public authority can use aerial photography to decide which inspections/audits to prioritize. Of course, decisions producing significant legal effects must not be based on “AI” alone, due to the Art 22 GDPR right to not be subject to unchecked automated decision making (unless specifically authorized by a suitable law).
The answer is right there in the quote: any information relating to an identified or identifiable natural person So if the data can in any way be tied to a specific individual then it is personal data. Note that you have to consider the data collection as a whole - even if there are no names in your data, if there is enough info in it that you can work out who the individual is (or probably is) its personal data. Obvious things include names, dates of birth, physical addresses, electronic addresses, social media profiles etc. Less obvious things include job or profession, memberships of organisations, friends and associates, town/suburb etc. i.e. things that in combination can reduce the set of people it could be to a small number of individuals. Basically, if you collect and store information about individuals in any way you are caught by this regulation. Even an email address used for login is personal data in that it identifies an individual and tells a hacker that they use your software. Examples of what is not personal data includes information about judicial persons (companies and other organisations that are sufficiently large that individual information cannot be inferred) or properly anonomized data where the data set is sufficiently large that identifying any particular individual is highly improbable (several dozen people at least depending on how revealing the data is).
Your confusion might be caused by the fact that even with a contract, only the data necessary for that contract is covered under the GDPR. So yes, while there might be an &quot;execution of contract&quot; under the T&amp;C, this would only cover necessary data. That means you can't ask arbitrary signup data under the guise of a contract. If you need to deliver a physical product, you can store a physical address. If it's an online service, you can store an email address or similar handle. But you can't mix the two. A physical address is unnecessary for the execution of a contract that's not physical in nature. Now, you mention &quot;consent&quot;. Under GDPR, this is a distinct justification besides &quot;execution of contract&quot;. You might have consent to store a physical address in addition to an online address, e.g. if you offer a customer to physically mail a password request form. This consent is additional to the contract. Also note that the bit above only covers the lawful reasons for the processing of personal data (article 6). You also have to obey the other GDPR rules, e.g. fully inform the user, make sure that consent is freely given, etc.