Can I use Facebook Chat Plugin without asking GDPR consent? My webpage has no analytics because I don't want to show the GDPR consent popup to users. Would I violate GDPR if I integrate the Facebook Chat Plugin without adding the GDPR consent popup?
When integrating third party plugins, it is important to determine whether that third party is your data processor or another controller. When they are your processor, you need a legal basis for the processing purpose and need to have a suitable contract with your processor. When they are a data controller, you need a legal basis for the processing purposes AND a legal basis for sharing this data with the third party. When using Facebook tools, you have to read the fine print in their Business Terms. I will assume that when integrating the Chat Plugin, you and Facebook would act as joint controllers. Facebook would not be your data processor. So you need a legal basis for sending data to Facebook. Some information will already be sent merely by loading the plugin in the visitor's browser – and this will happen whether or not the visitor is a Facebook member. Two legal bases seem especially interesting: you might have a legitimate interest for loading this plugin, or you might ask for consent. A legitimate interest requires a balancing test between your interests, and the rights and freedoms of the data subjects. The reasonable expectations of the data subject will likely be a factor as well. Here, I would suggest thinking about the reasonable expectations of a visitor who is not a Facebook member. In most cases, when you rely on a legitimate interest you must also give the opportunity to object to further processing, i.e. to opt-out. You can base almost any processing activity on consent. This gives you a lot of flexibility at least initially, but you can't use the data for any other purpose, and must make it easy to withdraw consent. Here, I think that your legitimate interest balancing test would lead you to the conclusion that consent would be the more appropriate legal basis. But this doesn't mean that you need to show a consent banner to every user. Instead, I would suggest the following procedure before loading any third party plugin or embed (whether a Facebook chat, a Tweet, or a Youtube video). The point is that users are given an informed choice: do not load the content by default as a placeholder for the content, or in a popup when the user interacts with the placeholder, show the following information: what the purpose of this content/plugin/embed is that a third party provides the content who the third party is what personal data will be disclosed to the third party, e.g. IP addresses if personal data will be transferred into a non-EU country: information about possible risks, e.g. the US does not provide an adequate level of data protection where visitors can find further information about the resulting processing by the third party (e.g. the FB privacy policy) a link to more information in your privacy notice how visitors can revoke consent later if the visitor clicks a button such as “start chat” or “load content”, treat this as consent store the consent for later visits, e.g. in a cookie make it easy to withdraw consent, e.g. with an easy to reach button that opens a consent management tool So instead of asking for consent when your page loads, ask for consent just in time before they're accessing something for which you need consent. Background: In the Fashion ID case, the ECJ has found that the provider of a website that loads Facebook social plugins such as the Like Button is a joint controller with Facebook. So the website provider is responsible for collecting and sending personal data to Facebook through this button, but they are not responsible for what Facebook later does with this data. At least in Germany, it has long been standard that social plugins are only loaded upon consent, e.g. with a toggle next to the network's logo (news report from 2011). The list of information to be shown in a popup was modelled after section 3.3.1 “Minimum content requirements for consent to be ‘informed’” in the EDPB guidelines on consent 05/2020. Providing information just-in-time (just before the user takes a relevant action) and in a layered manner (key information directly, details in a privacy notice) are best practices suggested in the WP29 guidelines on transparency which were later endorsed by the EDPB.
The basic requirements for the effectiveness of valid legal consent are defined in Article 7 of the GDPR and specified further in Recital 32. There is no form requirement for the consent, so using a button is not a problem. However, I do not think the MailChimp-button you reproduce as an example is good enough. It asks for a blanket consent to stuff that is buried in MailChimp's “Anti-spam Policy &amp; Terms of Use”. But according to the GDPR, what the data subject consent to can’t be buried in the ToU – it must spelled out in clear, plain language. Requests must be granular, asking for separate consent for separate types of processing. “When the processing has multiple purposes, consent should be given for all of them” (Recital 32). Blanket consent, as used by MailChimp, is not allowed. The other clear requirement from the GDPR is that opt-in is mandatory. Pre-ticked and opt-out buttons are explicitly banned: “Silence, pre-ticked boxes or inactivity should not therefore constitute consent” (Recital 32). ‘No’ must become your data default, but if the user chooses to opt-in by clicking a button, this is valid consent. The MailChimp-button complies witrh this. The GDPR also requires you to keep a records of the consents given (so make that part of the user profile), and to withdraw consent at any time &ndash; so you make make provisions for that as well in your implementation of consent.
I think that one cannot answer a question such as "Will the personal use exception in the GDPR apply to personal blogs?", because it is unclear if you refer to: personal information published on the blog pages personal information collected from the Website, by way of forms, cookies, server logs, strictly collected and processed for the purpose of operating the Website for your own personal purposes as a blogger (by yourself of through a subcontractor in the sense of GDPR) and not personal information collected from the Website's operation, transferred or provided to third parties for their own purposes (this would include cookies used to identify and track users across multiple domains) Regarding 1., a personal blog wanting to benefit from the exemption should not publish third party's personal information without their consent or another legal basis, and C-101/01 certainly applies here. About 2., if the information is strictly collected and used for the own personal purpose of the operation of the blog, I would tend to agree that it should benefit from the exemption. I feel that C-212/13 would not necessarily be an indication that because the blog is publicly accessible it is then "directed outwards from the private setting" in the sense of this ruling, and should not be considered as "purely ‘personal or household’ activity". C-212/13 case was relating to a camera installed by an individual on his family home for its own security purposes which was also monitoring a public space. The persons filmed on this public space had absolutely no direct connexion with the person collecting their images. In case of a blog, the visitors of the blog interact with the blog for fulfilling the own personal purpose of the operation of the blog of the publisher of the blog. Another argument is given by the Recital 18 which you quote: a personal blog can be viewed as a type of social networking or related online activity. Finally, about 3., there is no doubt for me that, in this case, the publisher of the blog is engaged in an activity which is not personal, since it willingly provides personal information to third parties which they use for their own purposes (and not as subcontractors in the sense of GDPR). There may be other approaches apart from these 3, but that's a start for your considerations.
What Big Tech is doing is spending a lot of money on lawyers and appeals – doesn't matter if it costs millions if you can make money in the meanwhile. Facebook stores a lot of user data in the US. Initially, this was allowed because the US was recognized as offering an adequate level of data protection under the Safe Harbor and later the Privacy Shield Framework. Then Schrems I and Schrems II happened and the adequacy recognition was ruled to be invalid. Does Facebook pull back their user data? No. The GDPR offers alternative reasons why you might process data in foreign countries, such as “standard contractual clauses” (SCCs) or “binding corporate rules” (BCRs). Now, Facebook claims that they are using SCCs. Is this valid? Almost certainly not due to the issues of US law analyzed in the Schrems II case, but it can take years for the next round of court cases to work its way through the system. And when Facebook's use of SCCs is ruled invalid they will probably try BCRs next, and once that is over a decade will have passed and the US might actually have achieved an adequate privacy level by then. You do not have Facebook-style money to spend on lawyers and endless rounds of appeals, so you should avoid legally risky things such as outsourcing data processing activities to companies in the US (this doesn't mean you can't be compliant if you are a US entity). I mentioned adequacy decision previously. There is a list of countries that the EU considers to be sufficiently safe. Currently, the more notable countries involve Canada, Israel, Japan, New Zealand, Republic of Korea, Switzerland, and the United Kingdom, in addition to EU/EEA countries of course. If you want to process data in a location that is OK for both the UK and the US, then looking at companies in one of these countries is a good idea. For example, if most of your users are in the US but you would like your servers to be in a country with an EU adequacy decision, then looking at Canada could make sense. Even outside of this list, you can process data if you implement additional safeguards via SCCs. However, this requires a case by case analysis of the legal environment in that country. One problem with the US is that it has national security laws that impose requirements on companies in a manner that is incompatible with SCCs. A company bound by these US laws cannot enter into such a contract where it guarantees the privacy of your user's data. Countries other than the EU have much more tedious data residency laws. The GDPR does not impose any data residency requirements in the sense that data must not leave a particular country – you just have to ensure that the data is properly protected. In contrast, Russia and China have real data residency requirements that are fundamentally incompatible with the GDPR.
GDPR compliance is a matter between every customer and the business, not between different customers. How did you get the other customer's contact details? If they were provided or leaked by the business, that might be a failure of the business's obligation as a data controller to protect the personal data they are processing, possibly even a data breach in the sense of the GDPR. When you contacted the other person this was presumably a purely private or household activity, just like contacting any other personal acquaintance. In that case, the GDPR simply does not apply to any “processing” you may have done (compare Art 2(2)(c)). Things would be very different if you were promoting your own business, but that doesn't seem to have been the case. If the matter really is as plain as you described, then you can effectively ignore their references to the GDPR until you are contacted by your data protection authority, by their lawyer, or are served with court papers. None of these should happen: even if you were a “data controller” and your processing were subject to the GDPR – only the other customer and not the business would be the data subject, and only a data subject has a right for remedies like making complaints to the data protection agency and only the data subject would have standing to sue you in court for GDPR violations.
The point of privacy laws is to set basic standards that apply to everyone, whether or not they have a privacy policy. A privacy policy that is inconsistent with privacy laws cannot be enforced. Breaches of privacy law can be punished even if the conduct is permitted by a privacy policy. Article 7 of the GDPR illustrates this by making special provision for the nature of &quot;consent&quot; to the processing of personal data. Consent must be freely given, and a &quot;written declaration&quot; as to consent, like the acceptance of a privacy policy, &quot;shall not be binding&quot; to the extent that it infringes the GDPR. The $5 billion penalty obtained by the FTC in United States v. Facebook, Inc (19-cv-2184) demonstrates that privacy laws can have a practical impact when a service provider &quot;subvert[s] users’ privacy choices to serve its own business interests.&quot; Facebook was penalised even though its users agreed to Facebook sharing &quot;information about the App User and the App User’s Facebook Friends&quot; with third-party developers. Whether a service provider has breached privacy law is a complex, fact-specific question, but if the service is &quot;pretty much part of people's lives,&quot; that will generally affect both the application of privacy law and the likelihood of an investigation by the regulators.
The GDPR's right to erasure just applies in some specific situations. While messages you wrote on Slack are personal data, they are generally also part of a larger discussion with others. If your messages are removed, the discussion becomes incomplete, so that will violate the freedom of expression of those others. Art. 17(3) GDPR provides an exception for the right of erasure in such cases. So basically, whoever is the controller, you probably don't have the right to have your messages to be deleted. However, you would have the right to have your account pseudonymized like Slack replied in the Reddit post you linked to. See also my answer in "Does a user have the right to request their forum posts deleted?". Basically, it is correct that Slack can be just the processor. Even if the controller cannot get access to more than 10000 messages unless they pay. However, Slack is not allowed to do anything with those messages, except when the controller says so. In its Privacy Policy, Slack distinguishes between customer data and other data. It states to be the processor for the customer data, but controller for the other data. Because those are tied together, I am not sure this distinction can be made. If not, Slack and the customer will be joint controllers, but it requires probably a court case to decide on that. For example, the Court of Justice of the European Union has ruled (in the Fashion ID case) that putting a Facebook "like" button on your website, makes you a joint controller together with Facebook. And (in the Wirtschaftsakademie case) that also creating a Facebook "fan" page makes you a joint controller. But neither of those are very similar to the situation with Slack.
No, it is not legal. Regardless of their location, the only legal options for companies serving to EU residents are to either deny access altogether or to make consent truly optional1 Recital 42 states (emphasis mine): Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement[...] Recital 43 states: Consent is presumed not to be freely given [...] 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. 1 Of course, remember that consent is only one of several means that allow them to process data. For example, if you were getting a trial account for a limited time, it would be considered a legitimate business need to ensure that you are not just opening new trial accounts when the old ones expire. So, if they wanted some data from you to ensure that you are not a previous user and you refused to provide it, then they could deny giving you that trial account without breaking the GDPR.