A salt hashed with user password is anonymous data for GDPR? I want to use a scheme to track the user in a anonymous way. My idea is to use the user password to hash a salt to create a identify hash and track the user through this. Theoretically, the only way that I can return from hash identify to user is if I know his password, but it is a thing that only he know, by premise. So, it's considered anonymous or pseudonymised for GDPR? \
The GDPR has a fairly broad concept of what it means for a data subject to be identifiable. The details are given in Recital 26: 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. The good news is that this mandates a risk-based approach to identifiability. You don't have to prevent re-identification with absolute certainty, but you must make sure that re-identification is not “reasonably likely”. The bad news is that “identify” does not just mean “figuring out the real-world identity of the data subject”, but also “being able to single out the data subject”. Hashes of personal data are still personal data. The hashed password still allows you to single out data subject, since the hash now serves as an identifier that links multiple records. Equivalently, a random ID would serve as an identifier. Depending on the information in the linked records, this could reasonably likely also allow linking to a real-world identity. I'll also point out that the GDPR explicitly notes that “online identifiers … such as internet protocol addresses, cookie identifiers or other identifiers” enable profiling and identification, and are thus a kind of personal data. Note that it seems you have a user database that includes a password hash. This database includes rich links between the password hash and other, more directly identifying, data. Alternatively, consider that the software that collects tracking information along with this tracking identifier would also receive other information about the data subject that could allow re-identification, such as the data subject's current IP address. It would be reasonably likely that such additional information could be used to identify or single out the data subject. For this analysis, it is irrelevant whether you have any intention of singling out users – it only matters whether, under an objective analysis, the relevant means to do so exist. Related: EDPB thinks hashed phone numbers are personal data. There has been recent debate by regulatory bodies on the question whether hashed phone numbers are personal data. This debate was published by the EDPB binding decision regarding the Irish DPC's fine against WhatsApp, which uses hashed telephone numbers to intersect user's address books. The question in the context of the fine was whether this represents processing of personal data of users who are not WhatsApp users themselves. Originally, the Irish DPC argued that such hashes were not personal data. However, the German, French, Portuguese, and Dutch supervisory authorities pointed out that the specific hashing approach used by WhatsApp does not provide anonymization, for example because there still is contextual information (such as the user's social graph) that would allow indirect identification (and because their hashing was pretty weak and reversible with reasonable effort). Such hashing would only be pseudonymization, not anonymization. The Hungarian supervisory authority makes the argument that WhatsApp could always re-create the hash from the original data, thus permitting re-identification of the hash. This is in line with my above argument that the hash allows singling out. Again, the hash should be considered pseudonymous, not anonymous. The EDPB upheld all these objections against the Irish interpretation as “relevant and reasoned”, and largely agreed with their merits. Some parts of the resulting analysis are specific to issues around phone numbers, in particular that there are comparatively few phone numbers. However, a recurring point is that the hashed data cannot be viewed in isolation. It must be viewed in the context of how it is created and used, and in the context of other data that the data controller has. Conclusion It is possible that in some cases the hash could serve as an anonymous token. But this would require careful analysis about how the hash is created and used, and about what other data you have available and could potentially link or correlate with this token. Unless you are extremely sure that there are no means that could be reasonably likely used to perform re-identification or singling out, you should consider such tokens to be pseudonymous data. Pseudonymization is a great security measure, but such data is still personal data. I suggest reading the WP29 opinion 05/2014 on Anonymization Techniques (WP216) (PDF link). It predates the GDPR and is slightly outdated in both legal and technical matters, but still contains highly relevant guidance on the matter of proper anonymization in the European data protection context. Aside from identifiability issues, I am concerned about using the password (or derived hashes) for anything other than authentication. Even in hashed form, this is fairly sensitive data. In most cases where you would use a password hash, you can likely use a random number instead.
Earlier this year, the Internet lawyer Arnoud Engelfriet wrote a blog post about exactly this topic. As it is written in Dutch, I will summarize it here: As you also said, deleting posts breaks the flow of the archived conversation and it makes your archive incomplete. This is a problem for the freedom of expression and information. But Art. 17(3) GDPR includes an exception to the right of erasure for this situation. So posts do not need to be deleted. However, profiles are not included in this exception. So they must be removed, but they can be pseudonymized. For example replace the username with user89432, and remove all details from the profile. If other posts contain the nick of the author of an anonymized post, that is considered an journalistic, academic artistic or literary expression, so Art. 85 GDPR would apply, so the right of erasure does not apply to that. Bottom line: you only have to pseudonymize the account, if that person wants to be removed from the forum.
Keeping logs of chats would not necessarily be against the GDPR as you have suggested. For the IRC service provider/operator: these chats/logs would be within scope if EU-based users are involved and this means the data controller/processors would have legal obligations to comply with GDPR. The IRC service provider/operator would be the data controller and would be held ultimately responsible for the data stored/processed through the IRC service, including backups and logs kept etc, and this would mean any sub-processors they select (such as hosting provider) would also have to be GDPR compliant. Due to the nature of IRC chats being entirely public in the same way forum board posts and comments are public, the contract terms between the IRC service provider and the IRC users would need to be very clear that this is the case, and the IRC users would need to give consent for this processing (this is more complicated for children, see Article 8 regarding consent from the holder of parental responsibility). For IRC users (personal use): If you wish to keep the chat records for personal use only (i.e. not in connection with a business or your employment at a business), then an exemption applies: 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, Article 2: Material Scope, Paragraph 2(c), p.32) For IRC users (commercial/business use): In this case I don't think you would have any legal basis to store/process these chats/logs if they contain personal data without a legal agreement with the data controller which would require you to put in place the same protections they have to under GDPR but then allow your business to access the data for specific purposes. While the information may be published or considered to be in the 'public domain', for you to take a copy of it without permission and use it for a purpose they haven't consented to would not be allowed under GDPR. Additionally, to go through the process of removing personal data from the chats/logs would in itself be considered 'processing' under GDPR and therefore would be unauthorised without a legal agreement with the data controller. Practically therefore, your best options under this circumstance would be if: The IRC service provider implemented a 'favourites' feature to save within their own system the chat conversations you wish to retain and refer back to in future. Since they hold the data and you already have a user agreement with them there is no further complications (this is probably the best option); The IRC service provider implemented a feature to download an anonymized copy of a chat conversation (not ideal as there are no guaruntees a user will not include personal data in their messages, though the user agreement could state that message content will be considered to exclude personal data, in a similar way to how StackExchange do for this website, see the paragraph titled "Information You Choose to Display Publicly on the Network" on the StackExchange Privacy Policy). Your business considered an alternative communications solution, such as hosting its own real-time chat system or forum boards system, in which case your business would be the data controller, and while subject to GDPR you could then define the purposes for which the data will be used in your own user agreement.
Is X considered personal data? Can you use X to directly or indirectly identify a natural person? In the data to which you have access can X be related to an identifiable natural person? If you answer yes to either of those questions then X is personal data. Article 4(1): ‘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; Scenario 1: you want to count each user agent that comes to your site, that's the only data you have, then the user agent is not personal data (it cannot be used to identify someone - unless it has a name and address etc, which seems highly unlikely - and you cannot relate it to anyone). Scenario 2: you have customer records with names, addresses etc (clearly personal data) and want to record each customer's user agent then the user agent is personal data (it relates to the identifiable natural person). Scenario 3: in one dataset you record that a user agent was associated with order ID 123456 and in another dataset you record that order ID 123456 was for John Smith (plus address etc), then the user agent is personal data (it relates to the identifiable natural person). Is this considered storing personal data? If X is personal data. Do I need user's consent to record X? If you want to record X and X is personal data, then you must have an Article 6 lawful basis for recording X. Consent is one of the six lawful bases. Processing shall be lawful only if and to the extent that at least one of the following applies: (a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes; (b) 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; (c) processing is necessary for compliance with a legal obligation to which the controller is subject; (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; (e) 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; (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. Point (f) of the first subparagraph shall not apply to processing carried out by public authorities in the performance of their tasks.
I'm pretty sure that under GDPR, you can indeed request them to send all data they have on you. If it's a complex request, they may charge you something like £10. If they have a lot of data on you, they may list the categories of data they have and ask you to pick one, rather than them having to collect and send everything. They should respond within one month, but iirc in the UK implementation, they can inform you (within that month) that they will respond within three months instead. For the rest, I only know current Dutch law. GDPR is not that different from what we already had (in general terms) and in many cases it even extends it. Under our law (WBP), you can also request a correction of the data in case it is incorrect, or deletion if they no longer need it for the purpose for which it was collected and stored. I don't really know how that works out in practice though, as Facebook can of course claim that "being able to connect you to your friends when you sign up for WhatsApp or Facebook with that number" is a legitimate purpose (in their eyes). They might also not have your full name and therefore not be able to connect your data to your request. Or, perhaps, they have only your full name (and there are probably more people with your name), so they'll have a hard time verifying that it's really your data which they would be handing over or deleting. The company is required to verify your identity before acting on your request. How they implement that is up to them. Under Dutch law, if I remember correctly, any data that can be connected to your person by any party is personally identifiable information (PII). While Facebook might not be able to find who's behind a phone number, your carrier most certainly can. Therefore, the data falls under PII protection laws and they will have to implement a way to verify you and get you your data. Finally, whether your local laws apply to Facebook, I don't know exactly. There's lots of information on this though, so you should be able to find it. Generally, countries say that if something happened within their territory (e.g. you signed up for WhatsApp while in the UK), their law applies. Companies, I've read, will instead try to claim that their main office is in SomeCountry and therefore SomeCountry's laws apply. But I'm pretty sure you'll be able to find a Facebook office somewhere where GDPR applies, so that's probably fine. While not an exact answer and while I am not sure about everything, I hope this gave you some pointers to go on!
GDPR &amp; EPD require user consent before storing a users personal information. Wrong. User consent is one of the ways that justify storing personal information, but there are others. You may check art.6 to see the several reasons that allow to store personal information. In this case, it seems reasonable to justify it under the paragraph f (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. Of course, that means that the data has to be used for this purpose. Avoiding spammers and other banned users would be such a purpose, but you should ensure that you do not send those e-mail address commercial information or even a Christmas greeting. In any case, be careful with anything you store. If along with the e-mail you stored more info, this could be interpreted as excessive and beyond the scope of paragraph f. For example, imagine storing &quot;User wrote nazi statements&quot; explaining why the e-mail is banned; EU laws are very restrictive about storing information about political or religious beliefs.
Your VPN scenario is why you have to show the banner to everyone. If you somehow knew beyond any doubt that someone was not in the EU, then you would not have to show a banner, but because you can't verify that, you should always show the banner. Doing so also protects against accidentally violating a similar law in another country; the GDPR is the best-known privacy law, but it is far from the only one. It's good practice to ask for people's permission before collecting their information anyway.
Yes If you are in the EU, or your players are in the EU and your service is targeted at some part of (or all of) the EU, then this pretty clearly falls within the scope of the GDPR. Such a service would be collecting data associated with natural persons. At least some of it would be made public along with an online identifier, and other parts would be processed and stored, even if disclosed only in anonymized form. (By the way it is a non-trivial task to anonymize data well enough that it is no longer persona data under the GDPR. But let's suppose yoru methods are good enough.) Under GDPR Article 6 the DC must have a lawful basis for such processing. If the basis is &quot;consent&quot; then the consent must be freely given, whch means giving consent may not be a condition of using the service. Under GDPR Article 13 a notice must be sent to the Data Subject (DS) when the data is collected from the subject, including some 11 items or categories of information about the collection process, the Data Controller (DC), the purposes of processing, the legal basis of processing (which the DC must define), who will receive the data, the data retention period, and various rights of the DS. Such a service must be prepared to respond to data access and data erasure requests, under articles 15-17, and data restriction requests under article 18. It must provide a method for a DS to easily make such requests. Other GDPR provisions may well apply in addition to these, but that is enough to show that such service is very likely to be within the scope of the GDPR, unless none of the DSs are present in the EU or the related market area.