Why is the onus for adhering to privacy directives (e.g. GDPR, CCPA, etc.) on a host and not the user? (Apologies in advance for the lengthy epistle) Background: A colleague is planning to launch a social media and forum website which will appeal to a relatively narrow audience. For the sake of discussion, I've compared it to an online dating website. During a technical review, I noted he intends to block the entire EU due to GDPR regulation, as other major media outlets (presumably following legal advice) have taken the same approach. Personally, I've always detested blanket-bans as they inhibit the open and collaborative nature of the Internet. I sought for a solution that would allow EU users to knowingly waive their GDPR rights in order to use a site that was not necessarily GDPR compliant. See GDPR &amp; Blocking EU Visitors? In response to the question, @DavidSiegel pointed out a US State Privacy Legislation Tracker map which depicted five US states that also currently have active GDPR-like data privacy laws. Additionally, there are apparently a handful of other states that are working to introduce similar laws which are expected to possibly be active by 2023. @DavidMulder noted that other countries like Japan, Canada, Brazil, Israel, Kenya, Argentina [and probably many others] also have their own data privacy legislation. All this information was helpful, but it ultimately led my colleague to drastically expand his geoblock ranges to encompass these additional states and countries. Ugh! Changing gears, I myself am also an engineer who has several services and websites I would someday like to share with the world. Consequently, this discussion around GDPR/CCPA has piqued my interest to some degree. So now that you have an overview of the background...on to The question: Why is the onus for adhering to privacy directives (e.g. GDPR, CCPA, etc.) on a host and not the user? If I create a website and make it available to the Internet, anyone in the world can theoretically access it. From EU users, to Iran users, to California users. If my server resides in New York City, USA, I would expect that the laws of the USA, New York State, and New York City apply to that server. I'm not a lawyer by any stretch of the imagination, but many articles I've reviewed seem to suggest that my server (in NYC, USA) would be responsible for adhering to GDPR if someone in the EU connected to it and provided so called PII. Likewise, if someone in California connected to my server in (NYC, USA) and provided personal info, the server must adhere to California's CCPA law. The preceding paragraph is the crux of my concern. If my NYC server doesn't actually need to care about who is connecting from where or what data they provide, this entire question I posed is moot/there is no concern. However, if my server must be concerned about every single privacy law legislation in existence (GDPR, CCPA, California Prop24, Colorado SB 190, Connecticut SB 6, Virginia SB 1392, Utah SB 227, and surely more to come in the US) plus Japan, Canada, Brazil, Israel, Kenya, Argentina and forthcoming privacy laws legislation from other countries (and/or their states?)... Well hopefully, you see what I'm getting at. If it's required to support this plethora of ever increasing and changing legislation, it effectively prevents law abiding individuals or small businesses from providing interactive websites or services -- we simply just don't have the time, legal team, or financial resources that large corporations do. If this is the case, then the Internet's future does not look very bright to me. Assuming your answer is GDPR/CCPA/XYZ compliance is required for my NYC server, how does that mandate even bear any weight? The US is a sovereign nation, not a part of EU. Even though California is a part of the US, it's not part of New York so I would expect that only servers operating within California would be required to adhere to CCPA. If/when New York State creates privacy legislation, then my NYC server would be subject to it. And Iran, only servers in Iran would be expected to follow Iran's mandate. Etc., etc. This is the only approach I can fathom that makes any sense when dealing with multiple disparate legal jurisdictions. While I suspect (and would hope) there is a significant amount of overlap between the privacy legislation from all these legal jurisdictions, there doesn't have to be. Some jurisdictions may change their legislation more than others, add unique requirements, etc. I don't want anyone to think that I'm against data protection or privacy; I've always been a strong technical proponent for both. But we must ensure that individuals and small businesses can still operate in a global connected environment without having to blacklist the world for fear they don't comply with one of the ever fluctuating policies for country XYZ. Personally I think a site that is claiming GDPR/CCPA/XYZ compliance should clearly disclose it to users when they visit the site and then leave it up to the user to decide whether or not they will use the site. (I always assumed that was the entire point of the barrage of popups that routinely appear when visiting a website?) Instead of burdening every service with the requirement to support every piece of privacy legislation in existence from where it's users may visit (again, how is that even legal to enforce in sovereign nations like the US?), it would be much better to do things the usual way of requiring the user to take personal responsibility for the sites that they access. Reflect back on how things transitioned for web browser connections: In the old days, you visited a web server and it was always an unencrypted HTTP connection. Anyone between your computer and the server could read or change anything you sent or received. Later, SSL and then TLS encryption was added to scramble all data when in transit. Today, when you visit a site, popular browsers displays a padlock icon for sites that using a secure connection and a warning is first displayed if you try to access an older site that isn't setup to use encryption. Moreover, you can verify the site's certificate to ensure it matches the entity that you expect to be communicating with (e.g. your financial institution, business, etc.) The system isn't perfect, but it allows users to be much more confident that their sensitive information (e.g. a credit card number, passwords, government id numbers, PII/whatever you want to call it) won't be stolen in transit over the internet, while still allowing older non-encrypted sites to be usable. Something similar could be setup to support all these different privacy legislations. If the site doesn't support whatever privacy legislation you desire, then choose not to use the site. (Again, I believe this is what all the popups you see when first visiting a website are trying to do.) Large businesses will quickly adapt to support whatever legislation you want because they don't want to lose sales. Sites that aren't profit driven (or generate very low profits) likely won't care and they'll just accept that the user doesn't want to use their site and will use an alternative instead. In summary, I'm really tired of reading about privacy legislation. Attempting to foist privacy legislation on services external to the legal entity that created them is going to destroy individual and small business innovation, lead to more monopolies and ultimately be bad for everyone. While it is important to protect PII information, all it takes is a single data compromise for it to be exposed. Large corporations routinely experience data breaches. Being GDPR/CCPA/XYZ compliant does not mitigate the problem of protecting PII. Thanks in advance to all who share what they know about this. Looking forward to reading everyone's feedback.
For the same reason that states require doctors to be licensed Surely, if I want an unqualified, unlicensed surgeon (or a person that says they’re a surgeon) to crack open my cranium and poke my brain, that’s up to me? There is no doubt that requiring people to attend medical school for half a decade and then spending a similar period as an intern and a resident is a large barrier to entry compared to handing high school graduates a scalpel and a bone saw and telling them to learn on the job. The same applies to engineers, lawyers, plumbers, electricians, builders etc. I mean if a building falls down because the engineer or builder didn’t know what they were doing, it can’t kill that many people, can it? Even drivers for that matter - it’s a large cost to individuals and businesses to learn to drive, pass a test, maintain a license and a relatively clean record, register a car, keep it roadworthy etc. Surely it would be simpler to let anyone drive anything and if they cause someone harm, like dying, for that individual to seek redress through the courts? We’ll, there’s a reason why states mandate things and it’s economic rather than legal. When people don’t trust each other transaction costs go up. These costs are usually borne by the consumer as the suppliers engage in a “race to the bottom” - whoever provides the worst service at the lowest cost wins. Further, these costs are borne unevenly - most consumers are fine, some are very severely damaged; possibly with no real redress. By imposing minimum standards, the state places these costs in the hands of the people who are best positioned to manage them - the supplier. Once a user has given their data to the supplier they have no control over it. Therefore the economical optimal solution to maximize economy-wide output is to make the supplier legally responsible for managing the data in accordance with minimum standards. Extraterritoriality In an ideal world, there would be universal privacy standards. There would also be universal standards for training doctors and engineers. But there aren’t. Therefore, countries and states impose their own standards on organizations that operate within their jurisdiction. The threshold for the GDPR (and most other privacy laws) is whether you are targeting users within their jurisdiction. If so, they have the power under international law to assert sovereignty even if you are located elsewhere. A state has power where it says it has power. Otherwise, you could plan a terrorist attack on the USA from the UK and not have to fear prosecution. That’s what extradition treaties and honoring other nation’s civil judgements is all about. A website or similar platform operates in each and every jurisdiction it is accessible from. Like a surgeon with unlimited plane tickets. Therefore, it must comply with the law in each and every jurisdiction it’s operating in. Countries have adopted one of 2 solutions - China’s is to simply block all external sites, everyone else has said you can operate here but you have to follow our rules, just like every other business has to. Now, you may not like this but there is no doubt they have the legal power to do it.
Yes, GDPR applies: you are a data controller established/living in the UK or are offering services to people in the UK you fall under the material scope of the GDPR. The Art 2(2)(c) exemption for “purely personal or household activity” does not apply since you're offering the service to the public. You must consider GDPR compliance here. This is especially important as you are showing personal data to the public. Don't do that unless you have a very good reason, appropriate safeguards, and are clear to users how their information will be shown. On a high level, GDPR compliance involves working on the following questions: For what purpose are you processing personal data? Context: purpose limitation principle per GDPR Art 5(1)(b) What is the legal basis for processing? GDPR Art 6(1) lists the available legal bases. Here, consent, necessity for performance of a contract, or a legitimate interest could be a legal basis. They may have further obligations attached. A legitimate interest requires a balancing test that considers the data subject's rights and freedoms. Consent must fulfil the conditions per Art 7 in order to be valid. What is the minimal data necessary to achieve the purpose? Per the Art 5(1)(c) data minimisation principle, it is illegal to process personal data beyond what is necessary and adequate. You must provide data protection by design and by default per Art 25. Special categories of data per Art 9 such as health data are illegal to process outside of narrow exemptions. You must delete data once it is no longer necessary. What appropriate safeguards and security measures should you apply? Per Art 24 and 25, you are responsible for determining and implementing appropriate measures. This depends a lot on your specific context, so there's no checklist you can apply. Per Art 25(1) you must pseudonymize the processed information if that is compatible with the processing purpose. What further compliance measures do you have to consider? There are additional GDPR and non-GDPR compliance measures. From the GDPR side: Use the answers to these questions to write a privacy policy, including the information that you must provide to data subjects per Art 13. Consider whether you have to maintain a Records of Processing document per Art 30, or if you have to make a Data Protection Impact Assessment per Art 35. If you use third party services, figure out whether they are a joint controller or data processor and apply appropriate safeguards. If you have data processors, ensure that you have a contract in place that covers the items from Art 28(3). If you share data with other controllers (not processors) you need a legal basis for doing so. If you transfer data into a non-EU/EEA country (after 2020: non-UK country) you need a legal basis per Art 44 and have to cover additional items in your privacy policy. Ideally, the target country is covered by an EC adequacy decision per Art 45. For US-based companies, this is the case only when they have self-certified under the Privacy Shield framework. Non-GDPR compliance steps could include cookie consent banners, or showing a VAT ID. How can you prepare for data subject requests? Data subjects have various rights per Arts 15–23, subject to the modalities in Art 12. For example, a data subject could request that their information is erased from your website. The exact rights also depend on the legal basis you selected. You should figure out in advance how to deal with such requests.
Please note that Google Analytics do not anonymize the data you collect on its behalf unless you configure it to do IP-anonymization. If you use Google Analytics and do not use this feature, you need to have a DPA (Data Processing Addendum) in place with Google in order to comply with the GDPR. This is a real hassle, so unless you absolutely need fine-grained demographic data, it is strongly recommended that you use IP-anonymization. According to our data protection supervisory authority, this is sufficient to comply with the GDPR vis-a-vis Google Analytics. Does data that is anonymized need to be collect in the event of a GDPR Subject Access Request? No. But as the controller, you need to make sure that is is anonymized.
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.
Whether GDPR applies does not depend on the country of residence. Instead, GDPR applies to a non-EU site or service if the data controller offers products or services to people in the EU (see Art 3(2) GDPR). This depends solely on the behaviour and intent of the data controller / the provider of the website – compare also the discussion of the “targeting criterion” in EDPB guidelines 3/2018 on the territorial scope of the GDPR. While your proposed measures might not be entirely ineffective (in that they document an intent to not serve people in the EU), they are both unnecessarily restrictive and overly lax. For example, they would unnecessarily prevent EU tourists in the US from registering but would nevertheless allow US tourists in the EU. For the targeting criterion, it matters whether the data subject is in the EU at the time of the offer, not at all what their residency is. Even if a person who is currently in the EU registers with your service, that doesn't necessarily mean that you are targeting people in the EU. Instead of implementing signup restrictions, a better strategy might be to clarify in the copy on your website that you are only targeting the domestic US market, not the European market with your services. I have discussed this in more detail in an answer to “How can you block GDPR users from US based sites?” If you have a site where GDPR doesn't apply, and you receive a GDPR data subject request, you shouldn't deny it on the basis that the user must have lied – instead you can deny it on the basis that GDPR just doesn't apply to you.
Since you are from Europe, GDPR applies to all your processing activities per Art 3(1) GDPR, regardless of where the users are located. If you would like to avoid GDPR compliance, you would have to manage your business from abroad so that you no longer have an European establishment, and would have to avoid offering your services to people who are in Europe. So let's assume that you have no European establishment. Then, GDPR can only apply per Art 3(2) to those processing activities that relate to offering goods or services to people who are in Europe. For determining this, IP-based geolocation is indeed common. Very likely, you do not need consent for this. GDPR does not require consent for everything, just a legal basis. There are six potential legal bases in Art 6(1), though the relevant ones are consent, necessity for performing a contract, legal obligations, and necessity for a legitimate interest. For things like security checks, it would be common to claim a legitimate interest. Complying with GDPR can hurt revenue. However, data subjects have a right to data protection, but you do not have a right to a particular business model. Similarly, paying taxes can &quot;hurt revenue&quot;, but it's not really optional. If your business model can't deal with GDPR compliance (or with taxes), it might not be a sound business model. In Europe, many newspapers have since moved from advertising-only to a consent-or-pay model. That is, the user is given a choice: You can read articles without tracking if you buy a subscription. You can access articles for free if you consent to tracking. The legality of this is hotly debated. In principle, such an approach can be compliant, but the details are problematic, for example that you can only buy subscriptions rather than individual articles, and that these subscriptions are often orders of magnitude more expensive than what would be earned through ads. But this might actually be easier to solve for a mobile application than for a website, due to the availability of in-app payment and micropayment infrastructure. In any case, GDPR limits how much you can &quot;encourage&quot; consent – per Art 7(4), you cannot make access to your service conditional on consent. There must be a way to use your app without consenting to anything, unless that consent is actually necessary for the app to work. For example, consenting to camera access is necessary for a QR code reader app to work. It is extremely unlikely that ads would be necessary in this sense. Users also must not suffer detriment for declining or withdrawing consent. From this, the EDPB has developed the concept of &quot;permissible incentive&quot; in their guidelines on consent. In this post, &quot;Europe&quot; means EU/EEA/UK as appropriate.
The way you describe this UUID, it is pseudonymous data (see GDPR Art 4(5) and Recitals 28–29). That is, it is not directly identifying, but you have a mapping between pseudonyms and identifiers that can be used to re-identify this data. Effective pseudonymisation requires not only that the data is logically separate, but that there are effective organisational and technical measures preventing re-combination by unauthorized persons. Alongside with encryption, pseudonymisation is one of the safety measures that the GDPR explicitly requires whenever appropriate (see Art 25, Art 32). Pseudonymous data is still personal data, because you can easily re-identify the data. The PII concept is US-specific and is misleading in a GDPR context, where it is not the inherently identifying characteristics of the information that matters, but the realistic ability of the data controller to single out data subjects to whom this data relates (compare Art 4(1) and Recital 26). However, were you to irrevocably erase the UUID–email mapping, things are more tricky. There is no longer any connection with directly identifying data, so this data might be anonymous. On the other hand, such a persistent UUID still allows you to recognize/distinguish persons, so it might still be personal data. This might be the case especially when the UUID is used in long-lived cookies of website visitors, thus matching the GDPR's concept of an “online identifier”. This conclusion could be avoided by limiting reuse of UUIDs, e.g. creating a new UUID after some context-dependent appropriate duration. The GDPR does not require all data to be stored in the EU, but requires international transfers of personal data to have sufficient protections. If you're processing these data in countries without adequate legal protections (like the United States), additional safeguards have to be used. Pseudonymisation could be part of such safeguards, and has been suggested by some data protection authorities in the wake of the Schrems II ruling. However, pseudonymisation alone does not make the international transfer legal, it is more of a strategy to reduce remaining risks. I think that your systems has a good chance of being OK, but not neccessarily so. If in doubt, perform a DPIA and possibly consult your data protection authority under GDPR Art 36. If feasible, storing/processing data only in the EEA or in countries with an adequacy decision will simplify compliance. Safeguards such as pseudonymisation could be strengthened by rotating UUIDs, and by restricting access to the table with identifiers.
Your confusion might be caused by the fact that even with a contract, only the data necessary for that contract is covered under the GDPR. So yes, while there might be an &quot;execution of contract&quot; under the T&amp;C, this would only cover necessary data. That means you can't ask arbitrary signup data under the guise of a contract. If you need to deliver a physical product, you can store a physical address. If it's an online service, you can store an email address or similar handle. But you can't mix the two. A physical address is unnecessary for the execution of a contract that's not physical in nature. Now, you mention &quot;consent&quot;. Under GDPR, this is a distinct justification besides &quot;execution of contract&quot;. You might have consent to store a physical address in addition to an online address, e.g. if you offer a customer to physically mail a password request form. This consent is additional to the contract. Also note that the bit above only covers the lawful reasons for the processing of personal data (article 6). You also have to obey the other GDPR rules, e.g. fully inform the user, make sure that consent is freely given, etc.