Under GDPR, does blurhash of a profile picture count as personal data Suppose I have a web service where users can have a profile page with name and picture. Blurhash is a technology that allows me to create a significantly blurred representation of an image, as a placeholder or thumbnail for the actual image. Suppose I store the blurhash for each profile picture in my web service's database. Then, if a user requests via GDPR full deletion of their data from my web service, would I be required to delete also their profile picture blurhash? This might overlap with copyright law, and I would like to know if a blurhash is a &quot;derivative work&quot; and thus is my (the company running the web service) creation, not the user's creation. Here is an example of a blurhash. The original image (a public domain picture from Unsplash): Here is the blurhash code: +GFO+E4n5S~p4n%MRjE101R+-URjt7xu%Laet7ofoeR+xuD*R*n%RQt6n%kCs.tQM{of And here is the blurhash image:
From the GDPR's definitions: ‘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; This blurred image would be &quot;information relating to an identified ... natural person (‘data subject’).&quot; It does not matter whether the person can be identified using the information in question. Therefore, the answer to your question Under GDPR, does blurhash of a profile picture count as personal data is yes.
The GDPR has a fairly broad concept of personal data: any information that relates to an identifiable person. This is far more than directly identifiable information! The concept of identifiability is further explained 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. So indirectly linkable information can still be personal data. In your example, that ID can be easily re-identified with a particular person if you know who the secretary was between 2012 and 2014. It is quite likely that there are members in the club with this knowledge, or that this information can be gained from public sources like newspaper reports. Thus, you should assume that your member IDs are at most pseudonyms, but not anonymous. They are likely still personal data. However, it doesn't necessarily follow that you would have to erase everything. Art 17 comes with lots of caveats and exceptions. For example, if you are processing this personal data under a legitimate interest, and someone requests erasure, you might have overriding grounds to continue processing anyway. E.g. such a legitimate interest could involve security or auditability purposes. There might also be such a legitimate interest for keeping some history for the club, but there would have to be a decision based on the individual circumstances. Furthermore, you can of course retain data e.g. due to a legal obligation, or when this information is necessary for the establishment of or defence against legal claims. I understand your desire to keep some data around. Instead of asking “do I have to delete this?” it might be more productive to consider “under which legal basis can I keep this?”. I think you might have a legitimate interest, but you'd have to carry out a balancing test between the various interests and rights. A really problematic approach would be to hold on to de-identified data in the belief that it no longer were personal data. Such a belief is usually mistaken. True anonymization that meets the GDPR's definition is really hard, in particular because you would also have to prevent indirect identification, also by other actors than yourself. There are theoretical models that can help with anonymization, e.g. with k-anonymization methods you'd ensure that there are no unique records in the DB. But this can be tricky to apply correctly, so I'd recommend to only treat aggregate statistics as truly anonymous. In 2012, the ICO has published an anonymization code of practice (PDF). It is no longer up to date with the current legal environment (in particular since the GDPR has expanded the concept of identifiability), but it provides a good overview of both the difficulties of preventing re-identification and an overview of potential solutions.
There are a number of misconceptions here. GDPR does not generally impose blanket bans, but things get dicey if you're using data in a way that is not strictly necessary. Consent (freely given opt-in) is a way to continue nevertheless. A website without ads, tracking, or potentially tracking embedded content can probably work without having to ask for consent. Under the GDPR, every processing of personal data needs a purpose. This purpose must be covered by a legal basis. Some processing might be legally mandated or required by a contract with the data subject. It's also possible to base processing on a legitimate interest, but this requires a balancing test that also considers the data subject's rights and interests. As a last resort, consent can be an appropriate legal basis, but this comes with additional restrictions. Once you have a clear purpose that is covered by a legal basis, you can process the minimum data necessary to achieve the purpose. Sometimes, laws prescribe a particular legal basis. This is the case for cookies. You can use cookies (and similar technologies that access information on the end user's device) as strictly necessary to provide a service explicitly requested by the user. If you go beyond that, the ePrivacy Directive says you must obtain consent first. So for example, session cookies, shopping carts, or cookies that remember a “dark mode” preference are all perfectly fine because they are strictly necessary for something the user is trying to do. Also, you can use cookies to remember if the user gave or declined consent. On the other hand, analytics or tracking cookies are not necessary and require consent. If a website embeds third party content, this discloses personal data such as IP addresses to the third party. This disclosure requires a legal basis, most likely consent. There is case law about this regarding Facebook Like buttons on a page (→ Fashion ID case) but the same principle can be generalized to embedded Tweets or Youtube videos, images, or JavaScript files. A common way to handle this is to replace the embedded content with a placeholder, and to only load the embed once the user gives consent. But not all other domains or services are “third party” in the sense of the GDPR. When you engage a company to act as a data processor on your behalf, they are contractually bound to only use the data as instructed by you, and not for their own purposes. The GDPR allows you to outsource processing activities such as serving web content, as long as you have a suitable contract in place. Such “data processing agreements” are common for hosting providers or CDNs. When consent is to be used as a legal basis, it's important to consider the various conditions that the GDPR imposes (see Art 7 GDPR). The core principle is that consent must be freely given. You cannot make access to a site conditional on consent, so a naïve cookie wall or captive portal will be non-compliant. It's fine to force a choice, but “no” MUST be valid and possible. That consent is freely given also means that you must provide enough context for the user to make an informed decision, that the user must give consent through an unambiguous, affirmative action (consent is never the default), and that consent must be specific for a particular purpose (you can't bundle unrelated purposes). That is why modern consent management tools have multiple layers of information and allow the user to give consent for individual purposes (e.g. yes to analytics but no to ad personalization). In your particular context, you could proceed as follows: Figure out what kind of external content you're currently including. Can you enter into a data processing agreement with the external providers? If so, sign that. Can you host the content locally? This can be an easy solution except for video streams. Careful: copyright concerns might make this impossible. Can you replace the content with placeholders that only load if and when the user gives consent? That way, the rest of your site remains accessible without annoying consent walls. If the third party content is an unavoidable and essential part of your page, use an interstitial to inform the user of the risks before they proceed.
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.
The conditions for lawfulness of processing are spelled out in Article 6 of the GDPR. As for it being legal for website operators to log the IP-addresses of visitors, this is covered by the following paragraph (also pointed out by phoog in a comment). The paragraph says it is legal to process personal data if 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. (my emphasis) You are not the only web site that logs IP addresses for the purpose of security. Every web site I've ever worked on - from those controlled by large corporations to tiny NGOs - do this. This security practice will not be impacted by the GDPR (if it were, I am sure we would have heard about it by now). there is the EU cookie law too If your website are going to be accessible to European citizens and not only accessible by your friends and familiy, you have to comply with the EU cookie directive of 2002 (a exemption for "personal websites" does not exist).
A public key is private data - the fact that its a public key is neither here nor there, its data owned by the user and not necessarily in the public domain (I have keypairs for which the public key is only known by myself, for example). For a subject access request, you must give the user all data you hold about them, subject to certain restrictions laid out in the GDPR - in your case, this would be the IP addresses, public keys, encrypted data and anything else involved in identifying their devices for transferring the files. You dont need to decrypt the encrypted data if that is something you cannot do or would not normally do in the course of holding it during a transfer - to you, the encrypted data is what you hold. If you hold the means to decrypt the data, that means (private key for example) would also be included in the subject access requests response, but in your case you say you dont hold that, so there you go. Remember to include information from things like logs etc in your response.
From Article 4 of the GDPR: ‘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 fact that you can use the ID in your database, along with the value returned by the cookie you set to identify the user makes it personal data. The favorite colour is information relating to an individual. The fact that it is connected to the cookie ID means that it is personal data.
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.