Are GDPR-Walls legal? Quite a few websites started showing european visitors "You cannot use this site because of GDPR", probably based on GeoIP information. I see two possible legal problems: GDPR forbids coupling of acceptance and the possibility to use. I am not sure if the GDPR wall is illegal or not as there is neither acceptance required on the page nor a possiblity to use the site. The GDPR walls themself often miss a privacy policy (but most seem not to use tracking) European citizens accessing the site when they are visiting non-european countries or via a (possibly anonymous) proxy probably have the same rights, but can access the site and will be tracked (or whatever the site does what does not comply with GDPR) Are these walls a legal solution for these sites? Here is an example from the Washington Post. You need to agree to tracking to continue to the site or you need to pay to avoid tracking. Washington Post Step 1: Step 2 (after clicking Free): Slate Slate's implementation only offers an "agree" button, which leads you to their site, which probably uses tracking. From their privacy policy: Slate tracks when EU readers grant consent for Slate to collect and process data through the use of an identifying cookie on your browser.
If the website containing the GDPR-wall processes any personal data of users who hit the GDPR-wall, the GDPR applies to that website. This can be as simple as writing a logfile of all visits to the website. In this case it will be illegal if the website owner does not comply with the GDPR. However a supervisory authority would probably not spent any time on such a minor violation. As long as the the website with the GDPR-wall does not process any personal data, the GDPR does not apply, so nothing in the GDPR can forbid the GDPR-wall. Some related remarks: The GDPR does not require a "privacy policy" on the website if the website does not process any personal data. If personal data is processed based on consent, that consent must be freely given. Also it may not be disruptive. So a cookie wall asking for consent would be illegal. But the GDPR does not care about any other disruptive popups, as long as they are not related to asking for consent. Using GeoIP is a perfect way to implement such a GDPR-Wall, because it would block everyone from within the EU, but nobody else. So it blocks exactly those for who the GDPR would apply. In such a case it would not be reasonable to expect anything more from a website owner. A user which uses a proxy, can not expect to be protected by the GDPR, because it bypasses a restriction set by the owner of the website. A webserver does use the IP-address of all incoming requests, to send the reply back. That could be considered a processing of personal data, but everybody seems to agree it is not. I am not sure why. But I do agree that it would be very impractical if that is considered processing of personal data. I added an example from the Washington Post So you have to pay $9/month for a GDPR compliant subscription. Because the price you have to pay is not unacceptable high, I think it would be valid to offer the premium version this way. This does not force you to choose one of the other subscriptions. In december 2018, the Austrian DPA (DSB) has confirmed that a similar offer is lawful. On derstandard.at you get a choice between free access with tracking and advertising, or pay 6 Euro/Month for tracking free access. Because 6 Euro/Month is cheaper than subscribing to the printed edition, the DSB accepted that as a valid choice. More information can be found on noyb.eu or, (with more details but in German), on wbs-law.de.
No, it's not legal. The General Data Protection Regulations (GDPR) apply given that you are in the UK (regardless of where the Data Processor is based). The UK GDPR is slightly modified due to Brexit, but the same principles apply. The only plausible legal basis for this actions would be that you consent to it, and you're entitled to withdraw that consent at any time. Some may claim that Article 6.1(b) applies, i.e. that it's necessary to send marketing email in order to fulfil the contract, but GDPR is clear that bundling such consent into a contract for service simply to permit the data processor additional actions isn't allowed, as I'll demonstrate. UK GDPR requires that consent to use your personal information (in this case, your email address) for the stated purpose be freely given. Consent to use your information for direct marketing is not freely given if it's inseparable from the consent to use it for some other service, as per para 43: Consent is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, 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. And Article 7.4 backs this up with When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract. The intent of Article 6.1(b) is that only the processing required for the service you have bought is allowed (e.g. if you supply your address for delivery of stuff you've bought, the data processor can use that address to send you the stuff, but is not allowed to add a contract term that allows them to send you unwanted stuff). Examples of emails that Article 6.1(b) would allow (in my assessment) include things such as notification of upcoming downtime, or a reminder that subscriptions are due, but not unsolicited advertisements for other products. There's a grey area that's open to interpretation, where adverts are piggybacked onto actual service messages.
GDPR Article 4 paragraph 1 says: ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person; Recital 26 says Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person. ... The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. Recital 30 says: Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them. An IP address hashed through a cryptographically secure one-way hash cannot reasonably be used to establish the original IP address, nor to geolocate, nor to directly identify the data subject. However if such addresses are stored in a database with a link to the subject's individual record, or to other data which identify the data subject, then they would clearly be personal information. The ICO's page on &quot;What is personal data&quot; says: ‘Online identifiers’ includes IP addresses and cookie identifiers which may be personal data. The page from GDPR.EU on &quot;Personal Data&quot; says: Any information that can lead to either the direct or indirect identification of an individual will likely be considered personal data under the GDPR. ... Any data that relate to an identifiable individual is personal data. The page on &quot;Personal Data&quot; from gdpr-info.eu says: Personal data are any information which are related to an identified or identifiable natural person. The data subjects are identifiable if they can be directly or indirectly identified, especially by reference to an identifier such as a name, an identification number, location data, an online identifier or one of several special characteristics, which expresses the physical, physiological, genetic, mental, commercial, cultural or social identity of these natural persons. In practice, these also include all data which are or can be assigned to a person in any kind of way. For example, the telephone, credit card or personnel number of a person, account data, number plate, appearance, customer number or address are all personal data. Since the definition includes “any information,” one must assume that the term “personal data” should be as broadly interpreted as possible. This is also suggested in case law of the European Court of Justice ... See also &quot;Can a dynamic IP address constitute personal data?&quot; If a hashed IP address is stored so that it can be related to a specific individual, it is personal data. as such, it would be subject to the GDPR. To store it one would need to identify a lawful basis under GDPR Article 6 This could be the Data subject's consent, or the Controller's legitimate interest. In either case the information should be included in the list of personal information collected (often in a privacy policy document), disclosed to the subject on request, adn deleted on request if possible. If that is done, such a use of a hashed IP, although personal information, would seem to be compliant. If a hashed IP is stored in such a way that it cannot be related to any particular user, then it would not constitute personal information, and no compliance issue would seem to exist. Limiting the retention time of a hashed IP is a good practice which would reduce any possible impact it might have.
Any processing of personal data needs a legal basis, for example necessity for some contract or legitimate interest. If no other legal basis allows the processing, you need to acquire consent. Consent must be freely given. If something is gated behind consent without that consent being really necessary, this might coerce users and they would not be able to consent freely. The GDPR does not have a hard ban on this, but it explicitly calls out that this case must be considered when determining whether consent is valid. So what your company is trying to do is in a dark grey area. Not necessarily wrong, but likely so. Consent could be made free if users have an actual choice. For example, some online newspaper sites had success with a “pay or consent” wall. (Success in the sense that some data protection authorities allowed this). In your case, this could mean that users either consent to extra data collection, or that they buy some reasonably priced premium mode. But none of this is for you to decide. You can voice your doubts that the software would be compliant. You could also ask if the Data Protection Impact Assessment document for this proposed processing is available (creating such an assessment is likely mandatory in this case). But in the end, it is the company's obligation to be compliant, and this responsibility is largely shouldered by the company's data protection officer (to whom you can turn with further questions).
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.
Yes, this violates the GDPR if the user is in Europe. Data which is tied to a personal device can be tied to the person who owns it. From "What Is Personal Data" by the UK Information Commissioner's Office (ICO) (emphasis added): Personal data is information that relates to an identified or identifiable individual. What identifies an individual could be as simple as a name or a number or could include other identifiers such as an IP address or a cookie identifier, or other factors. If it is possible to identify an individual directly from the information you are processing, then that information may be personal data. If you cannot directly identify an individual from that information, then you need to consider whether the individual is still identifiable. You should take into account the information you are processing together with all the means reasonably likely to be used by either you or any other person to identify that individual. The bit about "all means reasonably likely" in the last bullet includes the kind of de-anonymisation tactics described in the NYT article. There are 6 lawful bases for data processing in the GDPR, and all processing must fall under at least one of them. (a) Consent: the individual has given clear consent for you to process their personal data for a specific purpose. (b) Contract: the processing is necessary for a contract you have with the individual, or because they have asked you to take specific steps before entering into a contract. (c) Legal obligation: the processing is necessary for you to comply with the law (not including contractual obligations). (d) Vital interests: the processing is necessary to protect someone’s life. (e) Public task: the processing is necessary for you to perform a task in the public interest or for your official functions, and the task or function has a clear basis in law. (f) Legitimate interests: the processing is necessary for your legitimate interests or the legitimate interests of a third party, unless there is a good reason to protect the individual’s personal data which overrides those legitimate interests. (This cannot apply if you are a public authority processing data to perform your official tasks.) Selling data isn't covered by any of the others, so consent must be obtained. Permission must be clear and positive, and you cannot predicate delivery of a service on the processing of data that isn't necessary for that service. So for instance you cannot say "You can use this service as long as we are allowed to collect and sell your data" because selling the data isn't necessary to the provision of the service. From "Consent" by the ICO: Consent requires a positive opt-in. Don’t use pre-ticked boxes or any other method of default consent. Explicit consent requires a very clear and specific statement of consent. Keep your consent requests separate from other terms and conditions. Be specific and ‘granular’ so that you get separate consent for separate things. Vague or blanket consent is not enough. [...] Avoid making consent to processing a precondition of a service. This applies to any processing of data about individuals within the EU, so just being an American company doesn't get you a free pass to ignore the GDPR if your app gets used by Europeans. The "Legitimate interests" basis is more problematic, in that the company collecting the data has to conduct a vague "balancing test" to determine if this basis applies. For direct marketing the ICO has written this, which says that direct marketing may be a legitimate interest, especially if you can show that the user has expressed interest in such adverts. For instance a location service which promises to tell you about nearby special offers would fall into this category. Against this, the impact on the user's privacy has to be considered, and location data is "special category data" because it can reveal medical information (e.g. hospital attendance) or religious affiliation (e.g. which church you go to). So unless the relationship between the recorded location data and the service is very direct its not going to pass the balancing test. The company would also need to distinguish between knowing the current location and keeping a record of historical locations; the two need separate justification. And of course nothing about this covers the sale of the data; this is considering a company which sells advertising space in it's app, not one that sells the data itself.
Cookies are information stored on the end users device and require consent¹ per the ePrivacy directive, even if the cookies or similar technologies don't contain personal data. Conditions for consent are defined by the GDPR. This was also confirmed by the &quot;Planet49&quot; case. 1. consent is required unless the storage of or access to information on the end users device is either strictly necessary for a service explicitly requested by the user, or necessary for technical reasons. E.g. functional cookies like a shopping cart feature in a web shop are fine, as are cookies used solely for security purposes or technical features like TLS session resumption. It is however likely that this cookie does qualify as personal data in the sense of the GDPR. The cookie contains an ID that lets you single out/distinguish this user from all other users, even though that ID doesn't link the user to a real-world identity. It is also possible to argue that the cookie is entirely anonymous, but the safer approach is to treat it as personal data. Similarly, other features of the website necessarily involve the processing of personal data, such as processing the user's IP address, if only for the purpose of responding to their HTTP requests. The GDPR's criteria for valid consent are mainly about ensuring that the consent is a freely given unambiguous indication of the data subject's wishes. For example, consent can never be the default, it needs to be an opt-in. However, Art 7(1) GDPR says that the data controller has the burden of proof of showing that valid consent was given. The GDPR itself does not provide further guidance on what this means specifically. I would argue that it can be decomposed into two aspects: Showing that valid consent was given. The manner in which you ask for consent must enable a free choice, and must respect that &quot;no consent&quot; is the default. For example, you could archive screenshots of the cookie management flow to show that there is a free choice. You could archive the frontend software so that it can be demonstrated that the cookie is not set until consent is given. Showing that this user gave consent. There is a wide variety of opinions on how to do that. My personal opinion is that the existence of a cookie paired with a valid consent flow to set that cookie demonstrates that the cookie can only have been set in a valid manner. However, there are consent management solutions that provide additional insight, such as the user's entire history of giving and revoking consent. For example, the user's browser might generate a pseudonymous ID enabling that user's consent history to be stored on some server. Indeed, that would be personal data, and this would have to be disclosed transparently. It would not be valid to use the consent management information for other purposes, for example by using the consent management ID for analytics purposes. Storing the user's consent history is definitely appropriate if you have a concept of identity, such as for signed-in users. I have doubts whether this is also helpful on websites that don't have user accounts, and I have not heard of a case where the existence of such records made a difference. After all, such records can only be relevant if the user gave consent but later disputes this in a complaint with a DPA or in a lawsuit. Which approach to choose will depend on more specific guidance provided by your country's data protection authority, and on the risk balance appropriate for your business. After all, the purpose of such compliance work is not to be 100% safe from lawsuits, but to reduce risks from enforcement/litigation to acceptable levels. What is acceptable is ultimately a business decision. E.g. the only 100% safe way to do web analytics is to have no analytics at all, but that is not acceptable for most businesses.
The ePrivacy Directive Cookies are governed in the EU by the ePrivacy Directive which was first passed in 2002, and revised in 2009. However, if a site places a cookie, and later reads the cookie and stores an indication of the cookie content, this may be personal information and thus also subject to GDPR rules. (Other privacy laws, such as the CCPA, may also impose requirements on cookie use, when they apply.) Note that the so-called &quot;EU cookie law&quot; is a directive and not a regulation. This means that it is up to the various EU countries to implement it in their national legislation, and different countries may implement it in different ways. It would be the actual laws in individual EU countries that would be binding on website operators, and I am not going to try to find and analyze all the various laws on the topic. Paragraph 25 of the directive (linked above) reads: However, such devices, for instance so-called &quot;cookies&quot;, can be a legitimate and useful tool, for example, in analysing the effectiveness of website design and advertising, and in verifying the identity of users engaged in on-line transactions. Where such devices, for instance cookies, are intended for a legitimate purpose, such as to facilitate the provision of information society services, their use should be allowed on condition that users are provided with clear and precise information in accordance with Directive 95/46/EC about the purposes of cookies or similar devices so as to ensure that users are made aware of information being placed on the terminal equipment they are using. Users should have the opportunity to refuse to have a cookie or similar device stored on their terminal equipment. This is particularly important where users other than the original user have access to the terminal equipment and thereby to any data containing privacy-sensitive information stored on such equipment. Information and the right to refuse may be offered once for the use of various devices to be installed on the user's terminal equipment during the same connection and also covering any further use that may be made of those devices during subsequent connections. The methods for giving information, offering a right to refuse or requesting consent should be made as user-friendly as possible. Access to specific website content may still be made conditional on the well-informed acceptance of a cookie or similar device, if it is used for a legitimate purpose. This should mean, if implemented straightforwardly, that cookies, beyond those absolutely essential to the operation of a site, can only be placed if a user is notified of the intention to place them, and freely consents. This can be done once per user, on an initial session. Users are supposed to be provided with provided with &quot;clear and precise information&quot;. I do not think a simple statement that the site uses cookies fulfills this. At the very least the purposes for which cookies will be used should be provided. The directive does not make clear what level of detail about individual cookies such a notice must provide. The notice described in the question neither describes the purpose of cookie placement, nor does it offer any meaningful choice to accept or reject them. As such, I do not think it would be compliant with the directive. If cookies are read back (which is after all pretty much the point of having them) and can be potentially identified with an individual, then under the GDPR (article 6) there must be a lawful basis for processing them, and the interaction above would not be enough to establish consent as a lawful basis. There might be some other basis that does not require consent, however. Interpretations from others This page from cookiebot explains some of the history of the directive, and how it contrasts with the GDPR (which is a regulation, and so is directly applicable without the action of national legislatures). This page from The Verge discusses recent changes in the directive and the guidelines for applying it, and criticizes how it has been complied with, and ignored, by many sites. Cookies and the GDPR This page, &quot;GDPR, and the ePrivacy Directive&quot;, from GDPR.EU says: ... cookies, insofar as they are used to identify users, qualify as personal data and are therefore subject to the GDPR. Companies do have a right to process their users’ data as long as they receive consent or if they have a legitimate interest. Passed in the 2002 and amended in 2009, the ePrivacy Directive (EPD) has become known as the “cookie law” since its most notable effect was the proliferation of cookie consent pop-ups after it was passed. It supplements (and in some cases, overrides) the GDPR, addressing crucial aspects about the confidentiality of electronic communications and the tracking of Internet users more broadly. To comply with the regulations governing cookies under the GDPR and the ePrivacy Directive you must: Receive users’ consent before you use any cookies except strictly necessary cookies. Provide accurate and specific information about the data each cookie tracks and its purpose in plain language before consent is received. Document and store consent received from users. Allow users to access your service even if they refuse to allow the use of certain cookies Make it as easy for users to withdraw their consent as it was for them to give their consent in the first place. That page also describes the proposed ePrivacy Regulation which, if passed, will replace the current directive, and links to drafts of it. Conclusion The site described in the question probably does not comply with legislation implementing the ePrivacy directive. Depending on where it is hosted and targeted, and what it does with cookies that it sets, it may fail to comply with the GDPR as well. There has been very little enforcement of the directive so far. This may change in the future, particularly if it is replaced by a regulation, as has been proposed.