GDPR and deleting users from wiki changelogs According to the GDPR §17, users have a right to request the deletion of personal data. I am wondering how this applies to wikis. In my case, when users edit a page, that edit is associated with their username by writing it to a changelog of that page. Users can delete their account which will remove their profile data but it will not remove the name from the changelog. Is the their username alone, without any attached profile (like their email address or real Name) still considered personal data that has to be deleted?
Is the their username alone, without any attached profile (like their email address or real Name) still considered personal data that has to be deleted? For something to be ‘personal data’ it must information relating to an identified or identifiable natural person. An identifiable natural person is one who can be identified, directly or indirectly. In other words: If the natural person can be indirectly identified from the username, it is personal data. If he cannot, it is not personal data. This obviously depends on the circumstances. If the user used something very similar to his real name, or his email address or uses the same nickname on a lot of different systems, then it probably is personal data. If it is an unique pseudonym that is not used elsewhere, it is less likely. If you want to make sure you comply with the right to erasure, you may want to scrub your wiki database, replacing all the username of the deleted user with "anonymous" (or something like that). If you want to be able to treat these as separate users, your scrubbing process may use unique anonymous identifiers ("anon-1", "anon-2", and so on).
The "Contribution activity" is extracted from repositories hosted on Github. Looking at the privacy statement, Github considers itself as a hosting service for those repositories. See EU Directive 2000/31/EC Article 14 for the exact definition and conditions: Article 14 Hosting Where an information society service is provided that consists of the storage of information provided by a recipient of the service, Member States shall ensure that the service provider is not liable for the information stored at the request of a recipient of the service, on condition that: (a) the provider does not have actual knowledge of illegal activity or information and, as regards claims for damages, is not aware of facts or circumstances from which the illegal activity or information is apparent; or (b) the provider, upon obtaining such knowledge or awareness, acts expeditiously to remove or to disable access to the information. Paragraph 1 shall not apply when the recipient of the service is acting under the authority or the control of the provider. This Article shall not affect the possibility for a court or administrative authority, in accordance with Member States' legal systems, of requiring the service provider to terminate or prevent an infringement, nor does it affect the possibility for Member States of establishing procedures governing the removal or disabling of access to information. Article 2(4) GDPR defines that the GDPR does not apply (to Github) in this case This Regulation shall be without prejudice to the application of Directive 2000/31/EC, in particular of the liability rules of intermediary service providers in Articles 12 to 15 of that Directive. Extracting data from the repositories to create a nicely formatted contribution activity list, would still be considered hosting as defined at Directive 2000/31/EC, because Github does not (manually) redact or modify commits. So if you want to hide your contribution activity, you must delete the contributions. And you should not ask Github to do that, but ask the owners of the repositories. And they might have good reasons to deny your request. If an owner of a repository denies your request without a good reason, you can ask Github to do so. But Github would then probably deny that request, because they explain in their privacy statement that modifying the history is not possible: The email address you have supplied via your Git commit settings will always be associated with your commits in the Git system. If you chose to make your email address private, you should also update your Git commit settings. We are unable to change or delete data in the Git commit history — the Git software is designed to maintain a record — but we do enable you to control what information you put in that record. edit To further clarify why Article 14 of Directive 2000/31/EC applies, see case C-236/08 (Google v. Louis Vuitton) where the European Court of Justice clarifies the meaning of that article (ECLI:EU:C:2010:159): In that regard, it follows from recital 42 in the preamble to Directive 2000/31 that the exemptions from liability established in that directive cover only cases in which the activity of the information society service provider is ‘of a mere technical, automatic and passive nature’, which implies that that service provider ‘has neither knowledge of nor control over the information which is transmitted or stored’. Accordingly, in order to establish whether the liability of a referencing service provider may be limited under Article 14 of Directive 2000/31, it is necessary to examine whether the role played by that service provider is neutral, in the sense that its conduct is merely technical, automatic and passive, pointing to a lack of knowledge or control of the data which it stores. The way Github creates/shows the contribution activity is in my opinion technical, automatic and passive. That means it is not liable, and that implies that the GDPR does not directly apply, unless data is unlawful, and someone notifies Github of that: The restriction on liability set out in Article 14(1) of Directive 2000/31 applies to cases ‘[w]here an information society service is provided that consists of the storage of information provided by a recipient of the service’ and means that the provider of such a service cannot be held liable for the data which it has stored at the request of a recipient of that service unless that service provider, after having become aware, because of information supplied by an injured party or otherwise, of the unlawful nature of those data or of activities of that recipient, fails to act expeditiously to remove or to disable access to those data. Surely the GDPR might be the reason data is unlawful. But you need a reason, in particular based on Article 17 ("right to be forgotten"). For example if personal data of a 12 year old child is processed without permission of it's parent. Without such a reason the legitimate interest of the repository owner will probably prevail (who wants to keep the git history complete).
Is there any sources of information where extraction of data from a closed source application and provided to a data subject is further defined? No, the GDPR is based on &quot;general principles&quot; and does not concern itself with implementation details for such matters. It's possible there's EU case law on this, but I can't find any. Am I within my rights to insist on this, even if to comply they would have to do some software development? Yes you can demand it, but they don't have to comply with your demand. The information only has to be provided in a &quot;concise, intelligible and easily accessible form, using clear and plain language.&quot; and they only have to provide the information electronically where &quot;reasonably practical&quot; to do so, and they only have to take &quot;reasonable steps&quot; to do all this per Section 52 of the Data Protection Act 2018 which implements GDPR into UK law. You can complain to the Information Commissioner's Office, and they will decide if Section 52 has been complied with or not. 52 Form of provision of information etc (1) The controller must take reasonable steps to ensure that any information that is required by this Chapter to be provided to the data subject is provided in a concise, intelligible and easily accessible form, using clear and plain language. (2) Subject to subsection (3), the information may be provided in any form, including electronic form. (3) Where information is provided in response to a request by the data subject under [the Right of access by the data subject], the controller must provide the information in the same form as the request where it is practicable to do so.
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.
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 is absolutely not the case that Providers are not allowed to keep PII without consent. Article 6 of the GDPR identifies six possible lawful bases for processing personal information. These are: (a) the data subject has given consent ... (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. If a person requests services from an online service provider, basis (b) will apply, at least to some information. If there is evidence of criminal activity, basis (c) may well apply, as it also will for much routine record keeping. Any in many such cases, basis (e) or (f) will also apply. In short, article 6 does not create a &quot;haven for online criminals/hackers&quot;. In a comment on another answer the OP writes: The offender has the right to not be identifiable and he can't be denied this right That is simply not correct. Nothing in the GDPR says anything of the sort. It is true that consent may not be forced, but if a user requests a service that service may require the user to identify him- or herself. For example, one cannot order physical goods without giving a name and a shipping address. And the provider may retain PI and even PII when it has a &quot;legitimate interest&quot; in doing so, although if challenged it must justify that legitimate interest.
The GDPR doesn't generally distinguish public from non-public personal data. If you have a good reason to contact the professor, do send them an email. GDPR does not prevent this. If you're sending this email for “purely personal or household purposes”, then GDPR doesn't apply anyway. There are rules in the ePrivacy Directive against unsolicited emails, but these specifically relate to emails for direct marketing purposes. A company is not allowed to send out spam marketing, regardless of whether they obtained the email address from a public data source. Companies can send email marketing to their own existing customers, or to people who have given consent. Consent is defined in a fairly restrictive way (as a specific, informed, freely given, and unambiguous indication of the data subject's wishes), so that mere publication of an email address cannot be interpreted as consent to receive marketing from a particular company.
No. Art. 17(1) GDPR lists conditions when erasure can be requested. None of the listed grounds would apply in this case. However, you might have to explain why you process the data (for moderation purposes as you explained above), and why that is lawfully. In particular Art. 5 and Art. 6 need to be taken into account. In your case, processing will be based on Art. 6(1)(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. Even if the data subject would be a 9 year old child, the legitimate interests of you and other forum users outweigh the objection of the data subject. Based on Art. 5, there will be a moment when the data has to be deleted. For example 1 year after the last login attempt.