A website is refusing or failing to remove personal data I&#39;ve requested removed: is this against GRPR? I have been a member of a website for 13 years and would like all of my old posts removed. I have contacted their support team however the experience has been dreadful: it look a lot of back and forth messaging until they understood what I need the support team is fairly disconnected from the tech team that can actually do it in 9 months of continuous messaging there has been little to no progress and I feel I'm running 'round in circles I had a quick at GDPR and these points don't apply: the personal data your company/organisation holds is needed to exercise the right of freedom of expression; there is a legal obligation to keep that data; for reasons of public interest (for example public health, scientific, statistical or historical research purposes). Is the website's refusal/failure to remove my personal data against GDPR ? What can I do about it ?
If the website's processing of your personal data is within the scope of the GDPR, then you have a qualified right to request the erasure of your personal data. It is relevant whether: the website operates within the EU; the website is operated by a company established in an EU country; the website aims to sell goods or services to people in the EU; or the website is routinely processing the personal data of people in the EU (including non-citizens). Furthermore, it is relevant whether your posts: contain one or more identifiers from which you could be personally identified, directly or indirectly, including by only the administrators or owners of the website; and by their content, directly reveal information relating to you. For example, let's say you posted on a forum saying that "I am a keen supporter of socialism", and your personal email address was used to sign up to the website, then you would have revealed information about your political beliefs, which by reference to a username, the website owners could use to uniquely identify you by your email address. You would not necessarily have to have used your name. If, for example, you posted something factual, like, "The Porsche 911 GT2 RS MR recorded the fastest lap time for a road-legal sports car on the Nürburgring," then it is only personal as long as it is associated with an identifier through which you could be identified. As such, the removal of the relationship could easily anonymise the post. A data controller has an obligation to provide means by which the data subject can exercise the rights guaranteed under Chapter 3 of the GDPR. Article 17 grants the right to "erasure of personal data concerning him or her without undue delay" where the grounds under Art. 17 lit. 1 (a) to (f) are met. It may be relevant what the lawful basis of processing personal data was in the first place, such as in determining whether you can withdraw consent (i.e. you cannot withdraw consent if consent was not given), or in determining whether there is a right to object under Article 21 lit. 1. Derogations permissible under local implementing laws may provide for other exemptions or requirements to the right to erasure, so it is also important to determine the country of jurisdiction.
The COVID restrictions are new enough that there are few court decisions on how to interpret them. There are frequent requests for court injunctions seeking temporary relief. Some pass, some are denied. The website might accuse locations listed there of breaking the restrictions. Making such an accusation in public sounds like a very bad idea, especially if there is no solid documentation. But the aggrieved party would be any location falsely listed. The site may or may not be hosted in Germany. If it is not, it becomes a really interesting question which law applies. You might inform the authorities, but beyond that, forget it.
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.
It seems clear that this is personal information under the GDPR. If you are subject to the GDPR, you need to have a "lawful basis" to store or process such information. (You are subject to the GDPR if you are locates in the EU, or if your users are. My understanding is that it is location at the time the app is accessed that matters, not a user's citizenship. I am not totally sure about that, however. Unless your app is limited to non-EU access, it it probably safest to comply with the GDPR) The degree of precision of your location data will not matter -- a specific city is quite enough to make it personal data if it can be tied to a specific person. There are various lawful bases that may be relied on for processing and storage, but explicit consent is probably the one with the widest applicability. To use consent as the lawful basis, you must present an OPT-IN decision to the user, and record the results. If the user does nothing, the result must record lack of consent. You may not use a pre-checked consent box or another mechanism that has the effect of an opt-out choice. You should be clear about what information will be stored, and how it will or might be used. You will also need to consider how your app will function for those who do not consent, and how to handle requests to withdraw consent. So if an app obtains user consent to store location data in a manner that complies with the GDPR, it may store user location data. The consent should make the possible uses of the data clear. If the data is to be shared, the consent should make the possible extent of sharing clear. Some previous questions and answers here on law.se dealing with GDPR consent that seem possibly relevant: User consent required under GDPR What provisions should I make regarding GDPR consent when users do not sign themselves up? GDPR - Withdrawn user consent Opt Out Consent under GDPR
At least as of 2011, when regulations under the Information Technology Act related to privacy and data security were issued (some of the relevant statute sections and regulations are linked in this answer at Law.SE), there was no non-contractual right to have your data destroyed, although a terms of service for a site could give you that right contractually. Instead, usually, a term of service agreement will do exactly the opposite and give a site owner an irrevocable right to keep your data forever. I am not aware of any subsequent statutory, regulatory or case law developments in India which have changed this situation, but that kind of tweak of IT Act regulations in India wouldn't necessary make headlines outside of the local IT industry press coverage in obscure trade journals. The EU is the only place of which I am aware that has any individual right to have data destroyed or suppressed even if it doesn't violated copyright, wasn't obtained illegally and isn't fraudulent or defamatory. Even then, as I understand it, in the EU this is not a unilateral right that applies in all circumstances and is instead a specific remedy for certain situations that have a particularly intense privacy aspect to them.
I spent a few years working in and around the Energy industry - including a stint working at a supplier, I'm no longer there so unfortunately I no longer have access to the email chains I had discussing this with legal. The consensus at the time was that a "traditional" i.e. non-half-hourly (NHH), non-smart meter reading itself was not considered personal data - they are conceptually tied to a metering point (which may or may not be a physical meter), not to an individual and don't represent an individual's energy consumption (the granularity of the reading is insufficient to tell anything about the usage profile) But this information, while all around the implementation of GDPR it was a couple of years back and to be honest it was bugging me that I might be out-of-date on the current practices so I reached out to a former colleague who was the Data Protection Officer at the supplier I worked at to try and get a more up-to-date take. He's since moved on but was there until recently so has more experience with the topic since GDPR actually went into effect. I asked him whether a) estimated opening reads were considered "personal data" and b) what would happen with a request to change one under article 16 and he had this to say, I've translated industry-speak in square brackets: a) for NHH ["Non Half Hourly" - meters that are read ad-hoc, essentially all non-smart domestic meters will be this] an estimated reading wasn't personal data automatically until the billing flag was set in CRM and those would be the only ones we'd include on an SAR [Subject Access Request], any others are internal data not personal. HH ["Half Hourly" - meters for higher consumption users, typically larger business premises are billed on increments for each half hour so have readings for each] and remote [smart meter] readings are always personal for domestic and microb [micro-businesses are a certain class of non-domestic energy customer see condition 7A] b) erm no! we'd only change it if the value in CRM didn't match the value in the D10 [industry Data Flow used to transmit meter reads] for some reason. if they match it's an accurate representation of what we estimate the reading to be so it's just a vanilla billing dispute not a data protection issue so i'd have punted it to [name of person who was head of metering] From that it would sound as though the estimated read would count as personal data - so long as it's being used for billing purposes, but that doesn't mean they have to accept your read in it's stead. It all comes down to accuracy - GDPR requires that personal data be "accurate" but provides no definition as to what "accurate" means (which makes sense since you can't give a one-size-fits-all answer that isn't an encyclopedia) and while The Electricity Directive 2019 confirms the need for accuracy in billing again it doesn't tell us what that means. The implementation is left to member state regulators. In the UK this is OFGEM and all opening meter readings are validated through third parties (so you don't end up with the foxes guarding the hen house!) and are calculated using the following formula: Last validated reading for the meter point &lt;= supplied reading &lt;= (expected daily usage x number of days since last validated reading x 2.5) where "expected daily usage" is obtained from a database maintained by the regulator - it's calculated off meter type, property type, property use, previous validated reads etc. So if the customer provides a reading that falls outside the above the supplier can (and in practice invariably will) reject it as being inaccurate. Now this is why the when a meter reading is provided matters - reads you provide are always assumed to be the read on the day you give them. With opening reads there's some leeway, I can't remember the official rule on how much but usually they give you up to the next estimated read is generated but more on that later. Now if the reading you're trying to submit is a "now" reading and it's failed the validation criteria and you aren't happy with the rejection you can force the issue by demanding the supplier come read the meter. You don't say how long has passed since the opening read - more than the week from what you've said so presumably at least a month (guessing you've had at least your first bill). Now if they are saying the opening read was X (based on the estimated usage) and you're it should have been X + Y and the current reading is X + Y + Z you want to pay your actual usage Z not Y + Z. What you need to do is dispute the opening read, which you're entitled to do, arguably GDPR of Article 16 gives you this right, but on it's own it's a weak argument. There's established means by which an estimated read's "accuracy" is determined and assuming they followed that they're going to just tell you that as far as they are concerned it is accurate. Any challenge to that accuracy is going to have to be done within the legal/regulatory frameworks for assessing accuracy, that's what they're there for, if they won't accept your reading escalate that to the regulator - and as soon as you can. OFGEM for example allow disputing of opening reads for 12 months - it doesn't have to be resolved within that 12 months it just has to be lodged with them within that time. If you try and use the GDPR angle to pursue this IMHO it's going to muddy the waters and not help you get what you need - pursue this on billing accuracy.
Names clearly are personal data and so a good question to ask for GDPR compliance is: Do you need to do what you want to do in order to offer your product or service? For your scenario a common answer seems to be that websites ask for the users first and last name during account creation. The reason is that they need this information to confirm the identity of the account creator. But the public profile only displays a user name that the user can pick freely. In general there is no good reason to publically show the legal names of users so websites don't do it. So for your website ask yourself, why do you want to publically show the names of your users? If you have a good reason to do that specify it in the user terms and go ahead. If you don't have a good reason don't do it.
Overview As described, only the last of these seems to be compliant ways of obtaining consent, and indeed even that is not fully compliant, although features not described might make it so. However, if there is a lawful basis for processing PI other than consent, under GDPR article 6, then there is no need to obtain consent at all, and doing so in an improper way is irrelevant. However storage of or access to local information (such as cookies) requires consent unless such storage or access is &quot;strictly necessary&quot; for providing a service which the user has requested. Relevant GDPR Provisions GDPR article 6 lists six possible lawful bases for processing personal data. These are, in summery: (a) consent; (b) processing is necessary for the performance of a contract or to takwe steps requested by the Data Subject; (c) necessary for compliance with a legal obligation; (d) to protect the vital interests of the data subject or another person (e) or the performance of a task carried out in the public interest (f) legitimate interests of the Controller The other provisions cited here apply only to PI for which the lawful basis is consent. GDPR article 7 reads: (2) If the data subject’s consent is given in the context of a written declaration which also concerns other matters, the request for consent shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language. Any part of such a declaration which constitutes an infringement of this Regulation shall not be binding. (3) The data subject shall have the right to withdraw his or her consent at any time. The withdrawal of consent shall not affect the lawfulness of processing based on consent before its withdrawal. Prior to giving consent, the data subject shall be informed thereof. It shall be as easy to withdraw as to give consent. 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. GDPR Recital 32 reads: Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement to the processing of personal data relating to him or her, such as by a written statement, including by electronic means, or an oral statement. This could include ticking a box when visiting an internet website, choosing technical settings for information society services or another statement or conduct which clearly indicates in this context the data subject’s acceptance of the proposed processing of his or her personal data. Silence, pre-ticked boxes or inactivity should not therefore constitute consent. Consent should cover all processing activities carried out for the same purpose or purposes. When the processing has multiple purposes, consent should be given for all of them. If the data subject’s consent is to be given following a request by electronic means, the request must be clear, concise and not unnecessarily disruptive to the use of the service for which it is provided. GDPR Recital 42 reads: ... in particular in the context of a written declaration on another matter, safeguards should ensure that the data subject is aware of the fact that and the extent to which consent is given. In accordance with Council Directive 93/13/EEC a declaration of consent pre-formulated by the controller should be provided in an intelligible and easily accessible form, using clear and plain language and it should not contain unfair terms. For consent to be informed, the data subject should be aware at least of the identity of the controller and the purposes of the processing for which the personal data are intended. Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment. GDPR Recital 43 reads: ... Consent is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, or if the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance. Analysis I will review each of the scenarios in the question in turn. Scenario 1: not allowing [a user] to use the site until the user clicks Accept. No options, just an &quot;Accept&quot; button. This does not constitute freely given consent, because: The giving of consent is not &quot;clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language&quot; (Art 7(2)). There appears to be no way to withdraw consent (Art 7(3)). It appears that the provision of a service (use of the site) is conditional on consent not needed for that service (Art 7(3)). Consent is not informed and unambiguous (Recital 32). The use has not been informed of the extent to which consent is given (Recital 42). The subject has not been made aware of purposes of the processing (Recital 42). the data subject has no genuine or free choice (Recital 42). There is no provision for separate consent to be given to different personal data processing operations. (Recital 43). Scenario 2: A banner stating that &quot;By browsing the site you accept the conditions&quot;. Just an &quot;x&quot; to close the banner. Using the site is allowed while the banner is displayed. This does not constitute freely given consent, because: Consent was not &quot;given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement to the processing of personal data&quot; (Art 7(2)). The giving of consent is not &quot;clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language&quot; (Art 7(2)). There appears to be no way to withdraw consent (Art 7(3)). Consent is not informed and unambiguous (Recital 32). The use has not been informed of the extent to which consent is given (Recital 42). The subject has not been made aware of purposes of the processing (Recital 42). the data subject has no genuine or free choice (Recital 42). There is no provision for separate consent to be given to different personal data processing operations. (Recital 43). Scenario 3: A banner with an &quot;Accept&quot; (and possibly &quot;Reject&quot;) button. No other options. Site navigation is allowed while the banner is displaying. This does not constitute freely given consent, because: The giving of consent is not &quot;clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language&quot; (Art 7(2)). There appears to be no way to withdraw consent (Art 7(3)). Consent is not informed and unambiguous (Recital 32). The use has not been informed of the extent to which consent is given (Recital 42). The subject has not been made aware of purposes of the processing (Recital 42). There is no provision for separate consent to be given to different personal data processing operations. (Recital 43). Scenario 4: A banner with an &quot;Accept&quot;, &quot;Reject&quot; and also a &quot;Settings&quot; options where the user can fine tune the way his data is being used by the site. This might constitute freely given consent, provided that: a document is displayed or linked to that describes the kinds of PI that will be processed, and the purposes of the processing; There is some easy and obvious manner to withdraw consent, and to change the individual choices on what to consent to, after the banner has closed, or on any subsequent visit to the site; The consent section of the settings dialog must be clearly distinguished from other sections that do not deal with consent; Just where the lines must be drawn between &quot;different personal data processing operations&quot; which each requires the possibility of separate consent is not yet fully clear. And again, if the site or service does not store or otherwise process PI, or has a lawful basis for doing so other than consent, and does not store or access local information, it need not obtain consent at all, and the question of what constitutes freely given consent becomes irrelevant. Of course many sites do depend on consent as the lawful basis for much of their activity.