Is hash of a username still personal data? I create a script, which asks a user who upload a GIF to a social media website, if it can reupload it to another website (to reduce other users' internet usage). Now I want to give users an option to save their consent for a longer time, so they don't need to click a link every time they upload a GIF. Users don't have a random ID, I only can use their usernames, which are surely personal data (many users use their Facebook account to create their account, and then their usernames are created from their first and last name). So my question is - if I store a hash of the usernames (irreversible form), is it still considered to be their personal data?
It depends on whether you can identify the person to whom a username hash belongs. If you store both username and its hash in the same database row then yes. If it is impracticable for you to identify the person by their hash only, then no. This comes from the definition of personal data — "any information relating to an identified or identifiable natural person", and Recital 26: Not applicable to anonymous data. The hash is essentially anonymous data when it does not on its own allow to identify the person (with reasonable efforts i.e. without spending $$$ on detectives or forensic science).
The GDPR's right to erasure just applies in some specific situations. While messages you wrote on Slack are personal data, they are generally also part of a larger discussion with others. If your messages are removed, the discussion becomes incomplete, so that will violate the freedom of expression of those others. Art. 17(3) GDPR provides an exception for the right of erasure in such cases. So basically, whoever is the controller, you probably don't have the right to have your messages to be deleted. However, you would have the right to have your account pseudonymized like Slack replied in the Reddit post you linked to. See also my answer in "Does a user have the right to request their forum posts deleted?". Basically, it is correct that Slack can be just the processor. Even if the controller cannot get access to more than 10000 messages unless they pay. However, Slack is not allowed to do anything with those messages, except when the controller says so. In its Privacy Policy, Slack distinguishes between customer data and other data. It states to be the processor for the customer data, but controller for the other data. Because those are tied together, I am not sure this distinction can be made. If not, Slack and the customer will be joint controllers, but it requires probably a court case to decide on that. For example, the Court of Justice of the European Union has ruled (in the Fashion ID case) that putting a Facebook "like" button on your website, makes you a joint controller together with Facebook. And (in the Wirtschaftsakademie case) that also creating a Facebook "fan" page makes you a joint controller. But neither of those are very similar to the situation with Slack.
It may be legal or it may not For example, if any of the users are in the European Union, then the GDPR applies and the person storing the information is a data controller and has legal obligations. These include, having a legitimate reason for storing them, storing them only for as long as necessary for that reason, notifying the individuals that the data is being stored and why, deleting it upon a users request etc.
I'd say it's definitely illegal. Here's what the cookie notice says on Facebook at the time of writing this answer: By clicking on or navigating the site, you agree to allow us to collect information on and off Facebook through cookies. And here's what the GDPR define consent: ‘consent’ of the data subject means any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her; Also consider this, by the way: When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract. Facebook's notice is a small blue bar at the top of its blue header, and you might not even notice it (at least on a desktop computer where I'm seeing it). I see no way to easily deny consent, for example there is no button saying "I don't accept". All you can do is click on the link to their cookie policy, and still that policy does not present a clear and easy way to deny consent in all different cases, it looks pretty complicated (among other things, it depends on whether you have a Facebook account or not). So denying consent looks pretty difficult, if at all possible. On the other hand, to give consent, you'd only have to click on any link. I tried this. I opened my browser in private/incognito mode, so it should not use any previous cookies. On Google, I searched for "facebook John Doe". Clicked on a result bringing me to a Facebook page with a list of profiles of people named John Doe. The cookie bar appears at the top, but let's pretend I did not notice it. Then I click on a profile, supposing I'm interested in a certain John Doe, and... I land on John Doe's profile on Facebook, now without the cookie notice! What happened is I gave consent by clicking on any link, that is, clicking on John Doe. I can't see any way this "consent" could ever be considered "freely given, specific, informed and unambiguous indication of the data subject's wishes". Why is Facebook not compliant? Well, they probably couldn't be compliant even if they wanted to, unless they wanted to go out of business. Lately I've been wondering what the purpose of Google Analytics would be if users were always given the option to freely refuse consent. Virtually every user would always be clicking on "I don't accept", every time everywhere, so lots of business models would be totally disrupted. By the way, as of now, the cookie bar of this community (stackexchange) does not comply with GDPR either. To tell you the truth, I'm afraid very few websites have a GDPR compliant cookie notice.
If you publish a website, you are the data controller for this website. Serving a website necessarily implies processing (but not collection) of personal data. You have chosen to host your website on GitHub Pages. Is GitHub then a joint controller with you, or is GitHub your processor with which you sign a DPA? In 2019, I asked GH customer support about this. Their response: Our Privacy Statement, combined with our Terms of Service, is intended to serve as a data protection agreement for individual accounts — we specifically wrote our Privacy Statement to provide the information required by Article 28 of the GDPR, including a list of our subprocessors. Our Privacy Statement and our Terms of Service serve as our agreements with you, as the controller, instructing us as the processor, and you can always contact us to provide additional instruction. Should we receive a data subject request that relates to data we process on your behalf, we'll always let you know promptly and work with you to comply. — Github, 2019-04-10, private communication At the time, their Privacy Policy described GH Pages as follows: If you create a GitHub Pages website, it is your responsibility to post a privacy statement that accurately describes how you collect, use, and share personal information and other visitor information, and how you comply with applicable data privacy laws, rules, and regulations. Please note that GitHub may collect Technical Information from visitors to your GitHub Pages website, including logs of visitor IP addresses, to maintain the security and integrity of the website and service. (Update 2022: the privacy notice has since changed, and the quoted part is no longer part of the privacy notice.) Under this theory: you are the controller, and GH is your processor the terms of service incl. GH privacy policy form an effective Data Processing Agreement you have instructed GH to collect Technical Information in the sense of the privacy policy, for the purpose of maintaining security and integrity of the website, which can be covered by legitimate interest you have not instructed/allowed GH to process any other data from your site It is your call whether you subscribe to that theory. Note that GH organizations can opt-in to their corporate terms and sign an explicit DPA which will mostly contain the same provisions. Does it matter that you don't have access to the Technical Information? No. Being a controller means that you decide the purposes and means of processing, not that you store data. You as a controller can always decide to point your domain name to a different server if you no longer want to use GH as a processor.
Simply use a cookie to store consent. First consider the opposite. If a user does not agree to store cookies, a cookie is the only way to remember this, as you want to avoid a new pop-up on every page-load. Because this use of a cookie is functional, you don't need permission to store that cookie. You seem have the impression that you have to prove towards the ICO if someone has provided consent. However I think it would be sufficient if you can demonstrate how your website works technically. In particular whether consent is handled properly. You might need to create screenshots or a screencast to do so. Add new proof after each major update of your website. Storing consent server-side would violate the data minimization principle of the GDPR I think. In particular because you would need to do something to be able to identify users. That would violate Art. 11(1) GDPR: If the purposes for which a controller processes personal data do not or do no longer require the identification of a data subject by the controller, the controller shall not be obliged to maintain, acquire or process additional information in order to identify the data subject for the sole purpose of complying with this Regulation. Notice it is possible to configure google analytics in a way so you don't need any consent. See my answer to this question. Just IP anonymization is not sufficient.
Certainly. A phone number is personal information (and on top of that, WhatsApp may provide some &quot;profile info&quot; from the people you contact). It is not difficult to identify a person by its phone number. So, sharing the phone number of the people affected should take into account the restrictions of GDPR. For instance, the Spanish Data Protection Agency (Agencia Española de Protección de Datos, AEPD) established in its Resolution R/03041/2017 that the Town Hall of Boecillo had violated the GDPR because it had created a WhatsApp group of citizens. Those citizens had provided their phone numbers to be informed about town hall activities, but they had not agreed to share their numbers with the other members of the group. And that was a very generic group. Doing a &quot;patients recovering from cancer&quot; or &quot;drug abusers under treatment&quot; or &quot;people who need food assistence&quot; group would involve sharing personal information that gets the maximum protection (in some specific instancies it could be that your information sharing that information is illegal even if the users gave you full consents). So yes, creating a WhatsApp group could very easily lead to a GDPR violation, and in fact it has been ruled at least once that it has. The fact that people cannot send messages is irrelevant. It would not make the issue any better or worse. After all, if I send a message through WhatsApp I am implicitly giving permission to everyone in the group to read it.
You ask the wrong question first What do you save in the database? Let's take an example of a door: Do you have a legitimate interest to know/save who passed this door? Do you have a legitimate interest to know/save when the door was opened? Do you have a legitimate interest to know/save both? Only now, once you have established that you have any interest in the door passing at all, you have to start to figure out if it is personal data - if you have no interest in saving it in the first place, there's little reason to figure that out. Let's say you have a legitimate interest to save both, because behind the door is the server room, and physical access is limited to authorized personnel and you want to know when who was in there for figuring out if or who was responsible for changes. Now, which of the data is Personal Identifiable Data for you? You know where the door is. That's in itself Location Data, but if you don't know who or when the door was opened, then it is not PII. It becomes PII if you connect it with a person. A pin-code used by the whole department is not always PII, but can become PII in a very small to medium-sized department. e.g. one of all the 20 000 employees in a facility is just saying &quot;an employee&quot; and is not identifiable, but one of 20 is much more likely is, as you can correlate that with other data to possibly identify a smaller group. The Employee ID or Card would be most definitely PII if saved. Similar, if the login date is saved to the account list on some server. The timestamp on itself is not a PII, if only the timestamp is recorded and no other information exists. Like, if the front door only logs &quot;The door was opened/closed&quot; but not who did it, to count customers or schedule maintenance. However, together with other information - such as the door being access restricted and the paystubs from timekeeping when all those access carriers were in the building and having a tight access restriction to a decently small group (see above) - that can quickly become PII. It is enough that the information from different information sources compiled can become enough to say &quot;it was one of these few people&quot;, as that is enough to make it identifiable under GDPR Art.4. Once you know it is PII, you need to handle it as PII. As such, you need consent or a legitimate interest. That's why I pulled the other test before figuring out if it is indeed PII: Ic you have already figured out that this data is required for some legitimate reason, such as that you need to know the door operation log to ensure some other compliance, then you can proceed through the other parts of the GDPR compliance. Now, OP asked about a login timestamp. That is by necessity bound to an identifier, such as a login name. As such, it is the Keycard or Employee ID example and automatically PII because it is tied to a PII. Definitions The GDPR defines PII in Article 4 ‘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 US Department of labor defines quite similar PII is defined as information: (i) that directly identifies an individual (e.g., name, address, social security number or other identifying number or code, telephone number, email address, etc.) or (ii) by which an agency intends to identify specific individuals in conjunction with other data elements, i.e., indirect identification.