Is Pushshift.io compliant to GDPR if they refuse to delete collected content? Pushshift.io collects posts and comments using Reddit API, and saves that data into their database. This service is used by websites that allow you to see deleted contents in Reddit. For example, if you are viewing a Reddit post and want to see the deleted contents, you can tweak the &quot;reddit.com&quot; domain a little, to enter a website that will show you all the deleted contents, using the Pushshift.io website. However, several Reddit users from the EU are concerned about this, because Pushshift.io is not respecting the &quot;right to be forgotten&quot; from GDPR, when they're asked to remove contents that belong to the user. (besides that this data is being collected and stored without anyone's consent) In a Reddit post, they say: What happens when a removal request is made? A) Right now, we internally blacklist the account so that the data is not exposed via any public API. For full disclosure, we currently do not permanently delete any data unless there is a major issue involving PII, etc. While you have the right to request that people cannot search your comments and submissions via the public API, we reserve the right to keep data in our private archive so long as we never allow any data that you requested be removed get exposed through any public API endpoints. So they are still keeping our data against our wishes, and all it takes is their servers getting breached, for all this data to be exposed. Not only that, all the data apparently can be downloaded from this page, which contains compressed databases of their API. But while they remove (hide) the data from the API, that data is still available for anyone to publicly download. In this Reddit post, they replied with: safrax MOD · 10 hr. ago Pushshift is not subject to the GDPR. No useful discussion will come from this so I'm locking the thread. There's also an old comment here, saying: GDPR only applies to websites you give your data to, not third parties that scrape it. There's no violation here. Not to mention that pushshift is US based and GDPR doesn't even apply. Is it really correct that Pushshift is not subject to the GDPR? -- The Reddit user u/Stuck_In_the_Matrix is the creator of this API, and he said in a post: I am an American but I don't see that as an excuse to violate or circumvent EU law. My intention is to observe the laws governing the GDPR and make a good faith effort to follow the law to respect and protect the privacy of residents of the EU. But he clearly isn't respecting EU residents' privacy, with this.
Maybe, but probably not The geographic location of the organisation is immaterial: under Article 3.2: This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to: ... (b) the monitoring of their behaviour as far as their behaviour takes place within the Union. Posts anyone (not just EU citizens) make to Reddit (or anywhere else) while they are physically located in the EU or UK engage the GDPR. Pushift.io is therefore captured by the GDPR and any denial of that is just plain wrong. Given the denial, it is likely right out of the gate that they are non-complient. For example, they are unlikely to provided the required information under Article 14. More importantly, it seems that they have not determined the lawful basis for processing the data under Article 6 - they can possibly rely on the public interest basis (preserving deleted publication is arguably a public interest) or a legitimate interest but that requires a balancing of their interest against the data subject's. That said, the right to be forgotten is not absolute, the reasons that might be applicable here are: The data is being used to exercise the right of freedom of expression and information. The data is being used to perform a task that is being carried out in the public interest or when exercising an organization’s official authority. The data represents important information that serves the public interest, scientific research, historical research, or statistical purposes and where erasure of the data would likely to impair or halt progress towards the achievement that was the goal of the processing.
The status of any PII (Personally Identifiable Information) is the same in GDPR regardless of location, or who enters it. Its goals are (among others) to stop any actor (company / government or other) from hiding responsibility about their use and practices around people's data. GDPR does even apply to anything offline and on paper. Basically it means you have to validate any entry field is free of PII before processing it. Or make it clear in your privacy statement how you handle this use-case.
Your VPN scenario is why you have to show the banner to everyone. If you somehow knew beyond any doubt that someone was not in the EU, then you would not have to show a banner, but because you can't verify that, you should always show the banner. Doing so also protects against accidentally violating a similar law in another country; the GDPR is the best-known privacy law, but it is far from the only one. It's good practice to ask for people's permission before collecting their information anyway.
Great question - I work for a London based company who use a large amount of location data. The process for deletion of data is not as simple as it first sounds. We recently had a deep dive with our legal team and as a result actually created a product to process deletions. Personal data from users/customer is carried for lots of reasons, not just marketing. What if you're asked to delete data that is needed to bill customers, information that may be relevant to a legal case or information that needs by law to be retained for the purposes of audit? GDPR does not make it illegal to carry personal information, it simply needs you to justify why you are keeping the information - inform the named person about this and provide them with a timescale for deletion. For example if you are required by law to store a record of emails to document the work done, but the user asks you to delete that information. You would be entitled to keep that information but only for the purposes of maintaining that audit trail. You would delete all associated customer data that was unnecessary such as CRM info, payment details etc.. but could keep the audit trail. The proper way to respond to the user's deletion request would be "your data will be kept in a secure server for the purposes of maintaining an audit trail for x amount of time. Once this time has elapsed it will be deleted. If you are unhappy with our use of this data please contact our data officer". GDPR isn't designed to catch you out - if you have a legitimate reason to keep that information then you are entitled to. The law was designed to stop marketers and advertisers hoarding huge amounts of information, as well as undermine Google/Facebook's duopoly on our personal information.
Probably not. There are potential problems on the levels of copyright, data protection, and the Youtube terms of service. You should assume that comments are typically covered by copyright. You do not have a license to these comments, only YouTube does. Therefore, YouTube can show the comments but you can't copy them – just like YouTube can stream your videos but others can't download them and host them on their own websites. To cover the copyright angle, you'd either need to obtain a license from the commenters, or get a sub-license from YouTube, or identify a suitable copyright exception. The comments are personal data within the meaning of the GDPR, so that your processing of these comments (including mere storage) would be subject to GDPR as well. You need a legal basis for processing personal data. Which legal basis is suitable would depend on the purpose of processing, and on your relationship with the commenters. Potentially applicable legal bases in this context: you have a contract with the commenters that requires you to show the comments on your website. For example, I could see such a contract if there were a “featured comment” perk for a Patreon subscription. But this is not going to fly with random commenters. you have a legitimate interest (LI) that allows the processing. A LI requires that you conduct a balancing test where you weigh this interest against the commenter's rights. This is very specific to the purposes for which you want to show the comments. However, a LI will generally only apply if you have an existing relationship with the commenters, making it possible for them to expect that this processing will occur – unlikely if you'll be scraping comments from YouTube. you have obtained consent from the data subject. Consent must be specific, informed, freely given, and unambiguous – you can't obtain consent by writing “by commenting under this video you consent to XXX” in the video description. Regardless of legal basis, you would have to inform the commenters under Art 14 GDPR when you scrape their comments from the platform. Finally, consider the platform terms of service. I have not read the YouTube ToS recently, so I don't know what their specific conditions are. But in general, such ToS will not allow you to scrape content from their platform in order to host it somewhere else. The ToS might allow certain actions like embedding a link/iframe to such videos on other sites, without allowing other actions such as copying other user's content to your site.
The GDPR applies regardless of where and how data is processed. But it is necessary to look at what the processing activities in question are, and who is the controller for these activities by determining their purposes and means. This argument is supported: by the absence of relevant exemptions in the GDPR by the GDPR's broad definition of the data controller by the ECJ's analysis in the Fashion ID case GDPR Exemptions For certain constellations (e.g. controller = natural person, purposes = purely personal or household activities) that processing is exempt from GDPR compliance (see GDPR Art 2(2)). However per GDPR Recital 18, the GDPR would still apply “to controllers or processors which provide the means for processing data for such personal or household activities.” For example, this means that I am able to use WhatsApp to process my friends' contact information for purely personal purposes because I'm exempt from the GDPR with respect to that processing, but Facebook is still subject to the GDPR regarding how they process personal data collected via WhatsApp. Already on the basis of the GDPR providing no exception for processing on someone else's computer, I disagree strongly with the answer you cited (and have already written a competing answer). It seems entirely counterfactual. How to figure out who the controller is. Per GDPR Art 4(7), controller is whoever “alone or jointly with others, determines the purposes and means of the processing of personal data”, although other laws might provide more specific criteria for individual purposes or means. We will return to that definition in the next section. The ICO has provided a checklist to figure out if you're a data controller or perhaps a joint controller. Some of the questions are aligned with the above definition, like “We decided what the purpose or outcome of the processing was to be”. Other questions are there as a contrast to the data processor role, e.g. “We have complete autonomy as to how the personal data is processed”. Analysis of the Fashion ID case (ECJ C-40/17) This judgement provides a detailed analysis of who the data controller is, and is therefore relevant to the question. Fashion ID had embedded a Facebook “Like” button on their website, thus causing the visitor's browser to transmit personal data to Facebook. Fashion ID asserted that they were not the data controller, since they had no control over what data was collected by the Like button and how it was subsequently used by Facebook. Fashion ID relied in part of the argument that they weren't the controller because processing happened on the visitor's computer. This ruling was made on the basis of the Data Protection Directive 95/46 which was repealed by the GDPR. However, since the DPD and GDPR have effectively identical definitions of “controller” and “processing”, the court's analysis remains highly relevant. In the following I'll “translate” all DPD references to the GDPR, in analogy to GDPR Art 94(2). The court found that Fashion ID was a data controller for the processing by the Like button, and that it was a joint controller with Facebook for this processing. However, Fashion ID was only a controller for those processing activities in which they played a part, not for subsequent processing of the data that was controlled by Facebook alone. Relevant details from the Judgment (ECLI:EU:C:2019:629): Paragraphs 65–66: The GDPR tries to achieve a high level of data protection through a broad definition of “controller”. Thus, an overly narrow interpretation that counteracts this goal is incompatible with the law. Paragraph 68: An entity is a controller when it exerts influence over the processing for its own purposes, thereby participating in determining the purposes and means of processing. Compare the GDPR Art 4(7) definition of “controller”. case law: C-25/17 Jehovan todistajat, ECLI:EU:C:2018:551, paragraph 68: “However, a natural or legal person who exerts influence over the processing of personal data, for his own purposes, and who participates, as a result, in the determination of the purposes and means of that processing, may be regarded as a controller”. Paragraphs 67, 69–70, 82: It is not necessary to have a single controller, there can be multiple joint controllers. The joint controllers can be involved to different degrees. You can be a joint controller without having access to the personal data. case law: C-25/17 Jehovan todistajat, ECLI:EU:C:2018:551, paragraph 69: “Furthermore, the joint responsibility of several actors for the same processing, under that provision, does not require each of them to have access to the personal data concerned”. case law: C-210/16 Wirtschaftsakademie Schleswig-Holstein, ECLI:EU:C:2018:388, paragraph: 38: “In any event, [GDPR] does not, where several operators are jointly responsible for the same processing, require each of them to have access to the personal data concerned.” Paragraphs 71–74: Processing can consist of many different individual activities. A controller might only be involved in some of them, and can only be a controller for those activities for which they (jointly) determine purposes and means of processing. Paragraphs 76–79: Fashion ID was able to determine the purposes and means of processing regarding data collection and transmission by the Like button. The act of embedding the button showed that they had decisive influence over the processing: without the embedding, the data processing would not have occurred. To summarize the relevant conclusions: someone is a data controller when they participate in determining the purposes and means of processing for some processing activity for joint controllers, this holds regardless of whether they have access to the data or participate in the processing itself one cannot be a controller for a processing activity for which they cannot determine purposes and means. Conclusion and application to the question This analysis reaffirms my competing answer to the cited answer that it is important to determine who the data controller is. The Fashion ID case shows that is important to perform this analysis on a fairly granular manner, on the level of individual processing activities. For processing on a data subject's computer by a program written by another provider, this means: some processing activities might be solely under the user's control, then they are the sole data controller (or might be exempt from GDPR) for some processing activities, the software developer might decide alone for which purposes and through which means the processing is carried out for other activities, the user and data controller might be joint controllers. This does not require explicit agreement but can result implicitly. This does not require that the software developer has access to the personal data undergoing processing. For example, a spreadsheet application might be used by an end user to process personal data on their own computer (or via a cloud application, with the same conclusions). We can consider different processing activities performed by the software: sorting, transforming, and other processing of the data in the spreadsheet is solely under the end users control, so they are the data controller (if they aren't exempt) collecting usage analytics (where those analytics signals are personal data for which the end user is the data subject) is solely under the software developers control uploading crash reports (where those reports contain personal data from the end user and contain contents from the currently opened spreadsheet) is more complicated. The software developer is definitely a controller. The end user has a dual role here as a data subject and a joint controller (if they aren't exempt) because the crash report processes personal data for which they are the controller.
The 'right to be forgotten', as currently being applied throughout the European Union (EU), does not come from the General Data Protection Regulation (GDPR), which will come into force 25 May 2018. Rather, the current basis exists in the Data Protection Directive, 95/46/EC, article 12(b): Right of access Member States shall guarantee every data subject the right to obtain from the controller: [...] (b) as appropriate the rectification, erasure or blocking of data the processing of which does not comply with the provisions of this Directive, in particular because of the incomplete or inaccurate nature of the data; This was one of the main points upon which the Court of Justice of the European Union (CJEU) decided Google Spain v Agencia Española de Protección de Datos (AEPD) and Mario Costeja González, the judgement which allowed for individuals to ask for search engines to remove results containing personal data. The CJEU explained that the 'right to be forgotten' was not absolute and should take into account economic considerations as well as other rights (paragraphs 85 - 88). The GDPR, article 17, for purposes of contrast, has a more robust and explicit right of erasure than currently in force: Article 17 Right to erasure (‘right to be forgotten’) The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies: [...] Shortened for clarity GDPR, article 17 fleshes out much of the lack of specifics that the Directive's article 12(b). It should be noted that the UK's Data Protection Act 1998 is a transposition of the Data Protection Directive. This means that the full effect of the rights and obligations in the Directive are contained within the Data Protection Act 1998. Furthermore, the interpretation of the rights and obligations of the Data Protection Directive by the CJEU are highly influential on interpretation of the Data Protection Act 1998. This is due to the European Communities Act 1972, s 3(2) which states: Judicial notice shall be taken of the Treaties, of the Official Journal of the Communities and of any decision of, or expression of opinion by, the European Court on any such question as aforesaid; and the Official Journal shall be admissible as evidence of any instrument or other act thereby communicated of any of the Communities or of any Community institution Even without the above provision, it would be extremely likely that British courts would take into account Google Spain, given that the foundation of the Data Protection Act 1998 is the Data Protection Directive. The most likely outcome is for British courts to uphold the interpretation in Google Spain and allow for data subjects to request removal from search engines. Of course, it is not entirely possible to know without a test case, but it is doubtful any major search engine would attempt to deviate from the current situation as there is currently legal certainty. The Data Protection Act 1998 will still be in force after the future Brexit agreement and is certainly not contingent on continued EU membership. Update The current DPA will be repealed when Brexit comes in to play and will be replaced by a new one. Read more about the new data protection bill on the ICOs web site, which is based on the GDPR with certain derogations and additions.
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.