GDPR &amp; Blocking EU Visitors? I recently chatted with a colleague who is preparing to launch a social networking and forum website which targets a relatively narrow audience (for discussion, let's say it is a dating site that solicits personal information to help find potential matches.) He was primarily asking for my feedback on his technical design (which I provided), but I also noted he is planning to blacklist/block ALL connections from the EU due to GDPR regulation. His terms of service also prohibit users from connecting from any EU jurisdiction :( Anyways, this project is his personal venture. He's open to anyone in the world using the service, but is excluding EU because he just doesn't want to deal with any of the legal headaches/uncertainty from GDPR. (Apparently many US media outlets [and others] which presumably have large legal teams have taken the same mass-blocking approach...) Still, blocking a potentially useful free service from the entire EU just feels so regressive/anti-collaborative to me. If I lived in the EU, I would be pretty ticked to be blanket-excluded from services that I may otherwise choose to use. Does anyone know if there is a way for users in the EU to waive their GDPR rights in order to use a non-GDPR compliant website? (I suspect not, but just wanted to check whether there was a way to avoid a GeoIP &amp; TOS access block?) The service will be hosted in the US and replicated via CloudFlare's Content Distribution Network. Edit: Thanks for everyone's answers and comments. I posted another follow-up question: Why is the onus for adhering to privacy directives (e.g. GDPR, CCPA, etc.) on a host and not the user?
If GDPR applies, then no one can opt out. If it doesn't apply, then an IP block is superfluous. Whether GDPR applies is determined by Art 3 GDPR. For this, we must distinguish where the data controller is operating from. It is irrelevant where the site is hosted, but primarily relevant where the data controller (your colleague) has an “establishment”, e.g. where he resides or typically works from. Per Art 3(1), GDPR applies to all processing activities in the context of an European establishment, regardless of where the users are. So if your colleague were running this site from Europe, they wouldn't be able to circumvent GDPR by blocking European users. However, if your colleague is running this site from outside of Europe, then Art 3(1) doesn't trigger. Per Art 3(2), GDPR can apply to processing activities where there is no European establishment. There is the Art 3(2)(a) “targeting criterion”: if your colleague “offers” goods or services to people who are in Europe, regardless whether paid or gratis, then GDPR applies to all processing activities related to this offer. I'll discuss this more below. There is also the Art 3(2)(b) criterion: if your colleague monitors the behaviour of people that occurs in Europe, then GDPR applies. For example, an app collecting geolocation information or a website creating interest profiles for ad targeting might trigger this criterion. An IP block can help to establish that no offering/monitoring related to people who are in Europe is happening, but it might not be necessary. It may be worth talking a bit more about the targeting criterion. The GDPR explicitly says that mere availability of a website in Europe doesn't imply that GDPR would apply. Instead, it is necessary to establish the data controller's intention – are they soliciting users from Europe, or otherwise expecting that people from Europe might use those services? Recital 23 gives a couple of non-exhaustive factors that can be considered here, for example: the site uses a language or currency used in the EU but not used in the controller's own country the site mentions users or customers from Europe, e.g. in testimonials This means that a lot of US websites, written in English or Spanish, only mentioning payment in USD (if any), not mentioning any European countries, will not be subject to GDPR. Then, occasional European visitors are irrelevant. It wouldn't be necessary to IP-block potential European users. However, such an IP-based block would help establish that the data controller really doesn't intend for those services to be offered to people who are in Europe. My personal opinion is that it's wasted effort to block users from foreign countries in case their foreign laws claim to apply, but if such a block brings peace of mind that might be worth it. While geoblocking might not be necessary, is it sufficient? There is no clear guidance on this subject, but it seems to be generally accepted that IP-based geoblocking is fine, even though it is trivially circumvented using VPN services. Of course, if a website were to block European IP addresses but were to also advertise that people in Europe can use their services via VPNs, that would probably still be an “offer” and might defeat the point of doing any geoblocking. The Art 3(1)(a) targeting criterion is most easily applied to things like ecommerce where physical goods are shipped to the customer in return for payment – so essentially whenever the data controller participates in the EU Single Market. This is roughly similar to the concept of a Nexus in US tax law. But in principle the targeting criterion can also apply to other kinds of websites or apps such as blogs, even if they are gratis. GDPR does not just apply to for-profit commercial activity, and doesn't distinguish between controllers that are entities/LLCs and controllers who are natural persons. Things are slightly more complicated due to the Art 3(2)(b) monitoring criterion and the pervasive use of online trackers on websites, but this aspect of the GDPR is difficult to enforce and frequently ignored. In this answer, “Europe” means the European Union (EU), the European Economic Area (EEA), and the United Kingdom (UK). Note that countries like Norway are covered by GDPR, whereas Switzerland is not. Of course, the GDPR is not the only privacy law relevant internationally.
In my opinion, this should be enough. The GDPR regulation is general - it does not attempt to address these issues directly, precisely for the reasons we see here: You can never predict how the technology will develop. When interpreting the GDPR, we must keep the intended goal in mind. What is the purpose of the "right to erasure"? To prevent anyone from further processing the personal data. If you "crypto-shred" it, it can't be processed anymore, not even theoretically. The encryptec file cannot be used to identify the subject, therefore it is not even personal data anymore. In case it can be decrypted in the future... Well, that is just a speculation. The courts can go to great lengths in interpreting what personal data is (dynamic IP address is considered personal data, since it can be linked to a person by the police with a court order), but i am pretty sure that "it can be theoretically possible in some distant future" is beyond the limit. As for the second question, I am not aware of any applicable case-law, but I guess that current security and technological standards will be used to assess the delay. You have a right to protect your data, the subject has a right to erase them. Those rights must be balanced, neither fully overrules the other. The delay should be short enough so the right to erasure is effective, and it should not extremely long compared to other (economically viable) backup solutions available, in line with current industrial standards.
I understand that storing any hash or IP that can identify &quot;user uniquely&quot; is against GDPR. That is not correct. However any data which is identifiably associated with a an individual human, including any data which could be used to identify that human, is generally &quot;Personal data&quot;, and may not be processed (which includes storing it) without a lawful basis, if the GDPR applies. Any of the six lawful bases allowed by the GDPR may be used, including consent, and the legitimate interest of the data controller. The GDPR does not generally specify that particular technological solutions are permitted or forbidden. If this usage pattern could reasonably be used to identify a particular person, or to single out a person from among a group of people, it is probably personal data, and a lawful basis would be required. Otherwise, not. As for whether such a person is &quot;identifiable&quot; if use of this technique permits the Data Controller to identify two visits at separate times as having been made by the same person, when the later visit is still in progress or is recent, the IP for that visit will still be available, and thus could be associated with the first visit as well. And even if that is not done, such a technique could permit building a profile of such a person, including the actions taken on different visits. I think that would be enough to make this &quot;personal data&quot;.
The GDPR actually does require you to follow DNT in Article 21: In the context of the use of information society services, and notwithstanding Directive 2002/58/EC, the data subject may exercise his or her right to object by automated means using technical specifications. I think this is quite explicit.
I'd rather not, but this might be compliant if you make sure that the personal data under your responsibility remains secure and protected even if it is processed abroad. Since the UK has left the EU, it is sometimes necessary to distinguish between implications of the EU GDPR and the UK GDPR. These are functionally equivalent, but in the matter of international data transfers the practical details have diverged. In my answer that you cited, I argued that any website processes personal data, and is thus potentially in-scope for the GDPR. If you cause another organization to process this personal data outside of the UK, you are performing an international data transfer (called “restricted transfer” in UK guidance). For example, such non-UK processing occurs if you use cloud services that run outside of the UK. The UK ICO has guidance on international data transfers. As in an EU GDPR context, you can only perform the transfer if the data remains suitably protected, or one of the exceptions applies. The data remains suitably protected if the target country was attested and “adequate” level of data protection, or if you have implemented appropriate safeguards. As of 2022, the list of countries considered adequate is generally equivalent to the EU list of adequacy decisions. Notably, the US is no longer on that list after the Schrems II decision that invalidated the Privacy Shield Agreement. Since this decision was made before Exit Day, it also applies in the UK. This leaves “appropriate safeguards” for UK→US restricted transfers. In the linked ICO page, read the section Is the restricted transfer covered by appropriate safeguards?. In brief, you will need to perform a Transfer Impact Assessment, and sign Standard Contractual Clauses with the US data importer. In a Transfer Impact Assessment (TIA), you check that the data remains protected despite the transfer into a country without an adequate level of data protection. There is no official guidance on conducting a TIA, but the IAPP has a template and the EU EDPB has recommendations on supplemental measures to protect data transfers, which might reduce the risk and affect a TIA in your favor. It's worth noting that the EDPB recommendations were written in the wake of the Schrems II ruling, and can be summarized as “compliance is impossible when using US-based cloud services”. But this is your assessment, and TBH it seems the UK is a bit more relaxed than the EU in this regard. The Standard Contractual Clauses (SCCs) are a pre-formulated contract that binds the foreign data importer to handle the data properly. In essence, this translates relevant aspects of the UK GDPR into contract law. Many service providers already provide a Data Processing Agreement that includes SCCs by reference, but you'll have to make sure that these contracts have been entered in a legally binding manner. Sometimes these apply automatically as part of the terms of service, sometimes you need to explicitly sign these documents. But SCCs are one detail where UK GDPR compliance and EU GDPR compliance diverges a bit. The old EU SCC templates from 2004/2010 can no longer be used and have been replaced. For compliance with the EU GDPR, the new 2021 SCCs must be used. For compliance with the UK GDPR, you have two options. You can either use the 2022 International Data Transfer Agreement (IDTA), or you can use the 2021 EU SCCs along with the 2022 UK International Data Transfer Addendum which modifies the EU SCCs in some details. Don't want to deal with TIAs and SCCs? Switch to a hosting provider that only processes the personal data under your control in the UK, or in a country with an adequacy decision (e.g. EU, Canada, Israel).
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.
IANAL. (1) GDPR is certainly relevant. (2) This is certainly "personal data" under the definition in GDPR article 4. (3) Maintaining this data is probably lawful under article 6 sections 1(a) (consent) - provided that the Terms and Conditions of the site make clear that the user by signing up is consenting to this information being held (3) There is certainly an obligation under article 14 to disclose that the information exists, and to say how it used. (4) Article 15 says that data subjects are entitled to see the information and know what recipients or categories of recipient have access to the information (I don't know whether it's enough to just say "moderators", or whether the moderators need to be identified). (5) I can't see any reasons why the obligations under articles 16, 17, and 18 regarding rectification, erasure, and restriction of processing aren't relevant. This is exactly the kind of situation that GDPR is designed to address. If you're restricting the service available to particular users based on a record of their behaviour or on judgements made by moderators, then they absolutely have a right to know, and a right of redress.
You are responsible for what data is being processed by your website. When you embed third party components on your website (e.g. iframes, scripts), you are at least jointly responsible with the third party providing these components. You are only responsible for what happens on the website (i.e. what processing is under your control), not for what the third party provider does with collected data on their services. However, note that information will be transferred to Google's servers regardless of whether the visitor has a Google account! The Fashion ID case is relevant case law establishing and explaining these points. Since you are (jointly) responsible, you need a legal basis for collecting personal data through the tracking snippet and sharing it with the third party (here Google). For example, the legal basis could be a legitimate interest, or could be consent. A legitimate interest requires that you balance this interests against the interests, rights, and freedoms of the data subject (the site visitor). If the data subject wouldn't reasonably expect this tracking, you cannot rely on a legitimate interest. Consent can always work, except that it is a freely given, informed opt-in – likely unsuitable for conversion tracking. Which legal basis to use is primarily your responsibility. You argue that the tracking snippet does not collect personal data. However, this argument is not well supported. Under the GDPR, personal data does not only include directly identifying information such as an email address, but also any information “relating” to an identifiable person. Identification includes the ability to single out someone, e.g. by a browser fingerprint. For purposes of conversion tracking, Google will clearly try to collect data that allows the visitor to be singled out, thus collecting personal data. Furthermore, specific kinds of information are regulated by the ePrivacy directive. This includes “traffic data” and “information stored on a terminal device”, regardless of whether this information is personal data under the GDPR. Under ePrivacy, such information can only be used as strictly necessary to provide the service requested by the user (and conversion tracking is not strictly necessary), or when the user gives their consent. Depending on what information is collected by the tracking snippet and on whether you are subject to ePrivacy, you would have to collect consent anyway. There is also the issue that Google Ads is an US-based service, and transferring data to the US is largely illegal since the 2020 Schrems II ruling. The US do not provide an adequate level of data protection, so that transfers would require additional safeguards. Standard Contractual Clauses (SCCs) for Controller to Controller transfers are not sufficient by itself. Of course those extra safeguards are effectively impossible to implement and no one is doing this correctly, but it's worth considering that there is additional legal risk. Explicit consent can provide a legal basis for transfers even to a country with inadequate protections, but that mechanism is intended for occasional transfers. In conclusion: you have wrongly concluded that no personal data would be involved you are jointly responsible with Google for whatever data is processed by the conversion tracking snippet you need a legal basis for sharing this data with Google legitimate interest may be sufficient, depending on what data is involved (consider ePrivacy) and depending on the result of your legitimate interest balancing test alternatively, you may require every visitors consent to track their conversions – unlikely to result in good data additionally, such use of Google Ads may run into issues around international transfers due to the Schrems II ruling this kind of stuff is difficult, and no one is really doing this correctly :/