GDPR + git history Is name, surname and email in the Git commit history a personal information according to the coming GDPR (General Data Protection Regulation) and is there any special treatment required? Git is a distributed system and therefore it is probably impossible to have a complete control of it - especially for opensource projects. EDIT: It is also probably impossible to delete any information from the Git history. If the Git history contains any personal information, is it OK not being able to erase the information on request?
I believe in this regard there is a legitimate interest to not delete this information. You would have to perform a legitimate interest assessment, but for us (with private repositories) the reason would be to ensure that if in the future any malicious or illegal code was found that was knowingly committed to a repository there is trail and a way of understanding who did it.
The "right to be forgotten" is not absolute. It is subject (Art. 17) to certain conditions, in particular the absence of "overriding legitimate grounds for the processing" (1(c)). 3(b) explicitly exempts data controllers from the erasure where needed "for compliance with a legal obligation which requires processing by Union or Member State law to which the controller is subject". I can even imagine a former employee first claiming his right to be forgotten, and then - a week after getting the confirmation - claiming his right to receive a resumee (a right in existense in Germany), which a company would not be able to fulfill as it hasnt got any data to base the resumee on. If the "right to receive a resumee" indeed exists in Germany and employers need to comply with it, that would be perfectly legitimate ground to only partially fulfil the request to be forgotten⁠ — forget everything but the resume. Is it against the law to document these cases? If you document "On 27 February 2020 John Smith requested to be forgotten so we deleted or anonymised all his records", you will effectively NOT forget him. If you actually had to forget him, it will therefore be against the law to document your forgetting that way.
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.
I think there are a couple of different ways to look at this. Deduplication is a technical detail that's irrelevant here While the data may be deduplicated on a technical level, the files remain logically distinct. If users 1 and 2 upload identical files, and then one user edits or deletes their file, this will not affect the other user's data. Users cannot tell whether their files are duplicates of someone else. From the user's perspective, it makes no difference whether or not the storage uses deduplication, except perhaps via the cost of the service. Because there is no user-perceptible difference, it would be difficult to interpret some GDPR significance into this scenario. Whose personal data is it anyway? Personal data is any information that relates to an identifiable data subject. The files here are likely to be their uploader's personal data. Thus, the uploaders would also have a right to have their uploaded files erased. In case of deduplicated storage, this would affect their logical copy. The contents of the uploaded files might also be personal data relating to a third party. Then that third party might have a right to get the file contents erased. But this right must be invoked with the data controller for that processing activity, which might be company A, company B, or the uploaders, depending on context. Which leads us to the next aspect: Company A is not responsible for handling erasures From your description, it sounds like company A is a data processor providing services on behalf of company B. In turn, B might be a processor acting on behalf of the uploaders. In any case, it seems that A would not be the data controller for these processing activities. Data subject rights like erasure must be invoked against the controller, as only the controller can understand whether such a request should be granted. The right to erasure is not absolute, and depends a lot on why that data is being processed. In particular: Personal data need not be erased if it is still necessary For example, a person might very well be the data subject of some of these files, and might then ask for erasure. But if the files are being stored because they are going to be needed as evidence in legal proceedings, the data subject can't use this GDPR right to destroy evidence. The data controller would be allowed to refuse a request in such cases. It could now happen that two different users of this deduplicated storage are storing the same file, but for entirely different purposes. Blanket deletion of all copies of a file could be quite problematic. Note that deletion is also a &quot;processing activity&quot; and needs a legal basis under the GDPR. Unexpected data loss could be a data breach. One user's erasure could be another user's reportable data breach incident. Thus, I would strongly expect such requests to be handled on a logical file level, not on the deduplicated storage level. Caveat: public access and cloned files If the (logical) file is made available to the public who can then clone or copy this file, and if the &quot;original&quot; is taken down due to an erasure request (or copyright takedown notice), it might be appropriate to remove logical clones as well. Again, this might not involve deleting the contents on the deduplicated storage level, but it might affect other users' copies. In a GDPR context, the grounds for this would be the Art 17(2) right to be forgotten: Where the controller has made the personal data public and is obliged pursuant to paragraph 1 to erase the personal data, the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data. But this depends crucially on who those other controllers are. If A is the sole controller, the logical files could probably be deleted directly. If B or the end users are controllers, it could be more appropriate to forward the erasure request to them.
As I understand it, the GDPR does not permit sending of personal information (which includes the IP address) without prior consent by the user. That's not exactly true, consent is merely one of six possible legal basis for processing (article 6). For example, processing of personal data can also be lawful if it necessary to perform a contract, legally mandatory, or in the public interest. The court decision acknowledges that but rules out another basis in this case because it considers that it is possible to serve fonts without relying on a third-party ([…] der Einsatz der Schriftarten auch möglich ist, ohne dass eine Verbindung von Besuchern zu externen Servern hergestellt werden muss). Confusingly, it only refers to article 6(1)(f) when it seems to me that (b) would also be plausible but maybe this wasn't raised during the proceedings? If the data controller cannot invoke any other basis for the lawfulness of the processing then yes, the only thing left is asking for consent, i.e. invoking article 6(1)(a). But that doesn't mean that you should expect to be asked for consent each and every time your personal information is being used. The consent form on the site also implicitly assumes consent, which I thought was also a violation. Yes, implying consent doesn't really make sense under the GDPR definition (article 4, see also article 7): ‘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 European data protection authorities have issued guidelines that detail what that means and clearly reject “bundling” different data processing. The regulation also makes it clear that data subjects should be able to withdraw consent at any time, which does not seem possible with the fonts on golem.de My reading of all this is that assuming consent because you are using a service (or even created an account or checked a box at some point) simply isn't valid consent. Either you don't need consent at all in the first place or what you need is freely given, specific consent and “implying” consent or bundling it with a registration process achieves exactly nothing. But this is still extremely common and it might take some time before enforcement and case law definitively settle this question. Smart data controllers trying to avoid collecting consent (like Meta) have abandoned any claim that signing up to the their services would constitute consent (because that's transparently not the case) and try to bypass the issue entirely using another basis like contractual necessity. This is also being litigated. I know that a EU regulation can be implemented and interpreted differently from country to country, and that a single court ruling in Germany doesn't even mean that the national law was correctly applied. From what I've read, I get the impression that this particular ruling was not unlikely to be overturned by a higher instance, if it came down to it. So my question probably both pertains to German law specifically and the EU regulation itself. That sounds more like the way EU directives work. Regulations are supposed to be immediately applicable (no implementation in national law necessary) with minimal differences between countries (except when they explicitely provide for that). Of course, enforcement would still mostly be in the hands of national court systems and (in Germany) provincial data protection authorities but there are mechanisms to ensure consistency (the European Data Protection Board, prejudicial questions to the CJEU, infringement proceedings from the European Commission…).
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.
First of all, in a GDPR contest, the process described is not strong anonymization. It may be hard for an outsider to go from the stored record to any PII, it is much easier for an outsider to &quot;single out&quot; an individual. This means that given a known individual, one can determine whether that person is among those listed in the records, or can determine this to a significant degree of probability. For this only the algorithm and the rotating salts are needed, one need not break the hash. Note also that the GDPR specifies that if a person can be singled out with the assistance of the site operator the data is not considered anonymized. Thus this data needs a lawful basis under the GDPR, and the various other GDPR requirement all apply. However, even if the data were totally anonymized, and say just added to a count of users with this or that User Agent, the process of reading local data (including but not limited to cookies) itself requires informed consent, and so a cookie banner or other interaction with similar info under the e-Privacy directive (EPD). The EPD, being a directive and not a regulation, must be implemented by national laws, and the exact provisions in those laws may differ somewhat from country to country. But I believe that all of them require consent before any local data is read.
It doesn’t make you exempt from the GDPR if that’s what you’re asking The hash you produce is linked to one (or a small number) of computers and it therefore serves as an ID number. Because that ID number is linked to the owner of the computer it is personal information and if you are collecting it, you must comply with the requirements of the GDPR - valid legal reason, deletion when no longer required, deletion on request, data security etc.